logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[ATmega168][USBasp] Zablokowany mikrokontroler, dziwne zachowanie

regn0l 01 Mar 2012 23:25 1920 6
REKLAMA
  • #1 10621730
    regn0l
    Poziom 11  
    Witam,

    oczywiscie na wstepie zaznacze, ze szukalem informacji na ten konkretny temat, jednak nic czego bym nie wiedzial juz wczesniej nie znalazlem.

    Sytuacja jest nastepujaca: mam zaprojektowany i wykonany uklad sterujacy, posiada przekazniki, wejscia logiczne etc. Nic szczegolnego. Mikrokontrolerem jest atmega168 smd zasilany z lm1117 5V. Do tego konwerter rs232<->USB MCP2200 zasilany osobno z portu USB (i tylko on jest zasilany z tego portu).

    Do programowania uzywam USBasp samorobki (dziala z innymi uC bez problemow), avrdude z konsoli. Fuse bity ze stronki engebedded fuse bit calculator, czyli na pewno dobre.

    Problem jest taki, ze programowanie flasha przebiega bez problemow, natomiast co ktoras zmiane fuse'ow zaczynaja sie cuda. Na poczatku kilka razy zaprogramowalem uklad na standardowych fuse bitach, potem wylaczylem we fusach dzielenie clocka przez 8 CKDIV8, wszystko dzialalo. Nastepnie po jakims czasie dolozylem wylaczenie watchdoga i zdaje sie EESAVE, w kazdym razie nieszkodliwe zmiany. Odlaczylem uklad od programatora i kiedy po kilku dniach chcialem wrocic do pracy zonk - uC nie odpowiada. Sprawdzilem po raz n-ty polaczenia - byly ok. Desperackim rzutem na tasme wlutowalem kabelki z zewnetrznym kwarcem - viola, ruszylo -_-. Wniosek - fuse bity przestawily sie bez mojej wiedzy.

    Ok, wrocilem do poprzednich ustawien i wesolo kodzilem sobie dalej starajac sie zapomniec o calej sytuacji. Nie na dlugo jednak pozwolono mi cieszyc sie tymi chwilami. Otoz w pewnym momencie potrzebowalem w kodzie miec watchdoga, no wiec zaprogramowalem odpowiedni fuse bit i co? Wynik taki, ze uklad zaczal sie stale restartowac co kilkanascie ms (w kodzie bylo wyslanie stringa na uart i potem while(1){} - string lecial bez przerwy zalewajac terminal). Niemozliwe, pomyslalem, poniewaz watchdog byl wylaczony programowo na czas testow. No ale nic - wylacze go sprzetowo znowu, jak pomyslalem, tak uczynilem. Wynik? Totalny brak komunikacji w ogole po tej operacji. Standardowy 'target doesn't answer' w avrdude. Nawet podpiecie generatora zrobionego z innej atmegi nic nie daje.

    Zaobserwowalem jednak dziwna rzecz. Na samym poczatku, kiedy slonce swiecilo i wszystko gralo, po podlaczeniu kabla usb i NIE podlaczeniu zasilacza, dioda sygnalizujaca zasilanie swiecila sie (napiecie ok. 3V na lini Tx MCP2200, ktora wchodzila do Rx atmegi i stamtad wychodzila gdzies na nogi VCC). Teraz po takim zabiegu dioda wyraznie pulsuje. Nie mam pojecia co to moze powodowac, moge sie tylko domyslac.

    I jak koledzy? Ktos ma pomysl? Juz pewnikiem robie druga plytke, ale po prostu ciekawi mnie coz to moze byc.
  • REKLAMA
  • #2 10621855
    dondu
    Moderator na urlopie...
    regn0l napisał:
    Wniosek - fuse bity przestawily sie bez mojej wiedzy.

    Mój komentarz do całego Twojego posta w zakresie fusów: :lol:

    regn0l napisał:
    Do programowania uzywam USBasp samorobki (dziala z innymi uC bez problemow), avrdude z konsoli.

    I tutaj pewnie leży problem, więc proponuję byś korzystał z jakiejś nakładki.
  • REKLAMA
  • #3 10621864
    regn0l
    Poziom 11  
    dondu napisał:
    I tutaj pewnie leży problem, więc proponuję byś korzystał z jakiejś nakładki.


    Nie, tu nie lezy problem. Potrafie czytac dokumentacje i obslugiwac avrdude z konsoli :)
  • REKLAMA
  • #5 10621887
    regn0l
    Poziom 11  
    O blad latwo jak sie nie uwaza przy tym. Od zawsze obsluguje wszystkie uklady za pomoca konsolowego avrdude'a. Poza tym nakladka nie robi nic ponad wklepanie standardowych komend. Przyczyna na pewno nie lezy tutaj.

    Objawy sa zakrecone, bo ja bardzo chaotycznie tlumacze wszelkie rzeczy. W skrocie chodzi o to, ze po zmianie fuse bitow ktore chcialem zmienic, zmienily sie najwyrazniej tez pozostale, w sposob losowy. Raz to bylo przestawienie na zewnetrzny kwarc. Ok, wlutowalem taki i dzialalo. Ale teraz zupelnie cos innego. I nic nie pomaga. Oczywiscie za kazdym razem weryfikacja fuse bitow przechodzila poprawnie.

    Programator uzywam drugi raz, wczesniej byla to mega128, bez problemow. Na stk200 uklad tez nie rusza, tak btw.
  • REKLAMA
  • #7 10621981
    regn0l
    Poziom 11  
    dondu napisał:
    OK, ale nadal uważam, że same się nie przestawią.

    Ja tez tak uwazam. Ale znalazlem kilka wypowiedzi, gdzie ludzie skarzyli sie, ze z tym programatorem czasem dzieja sie takie cuda. Inna sprawa, ze tam mogla byc odmienna przyczyna. Teraz w kazdym razie juz zglupialem.

    O weryfikacji w czasie programowania nie ma mowy, bo uklad nie odpowiada na zapytanie o sygnature nawet. Ale tak, kiedy dzialal jeszcze, weryfikacja byla poprawna, zarowno podczas programowania flasha jak i fuse bitow. Ciekawa rzecz to to, ze extended fuse nie chcial sie zaprogramowac ani razu, za kazdym razem byl blad weryfikacji. Kilka razy sprobowalem z ciekawosci ustawic mu defaultowe wartosci, ale nie chcial. Zreszta on i tak odpowiada tylko za reset vector, co nie ma absolutnie zadnego zwiazku z mozliwoscia programowania.

    Nie umiem wyjasnic co sie dzieje. Czy moga sie tu generowac jakies szpilki, cuda na kiju? Jakies odlaczenie linii programatora przed odlaczeniem zasilania. Nic nie powinno miec wplywu, to proste wszystko jak konstrukcja cepa. A jednak cos niewyjasnionego sie dzieje.

    Dla swietego spokoju dodaje schemat.

    [ATmega168][USBasp] Zablokowany mikrokontroler, dziwne zachowanie
REKLAMA