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

[Atmega8] [avrdude] - czemu zmieniaja sie fusy?

Belialek 20 Lip 2009 15:06 4265 7
  • #1 6801201
    Belialek
    Poziom 22  
    Witam,

    Od pewnego czasu walczę z Atmega8 podłączoną pod zewnętrzny kwarc 4MHz. Podczas próby programowania, avrdude zwraca coś takiego:

    
    M:\avr\avrdude-gui>avrdude -p atmega8 -c usbasp -V -U flash:w:"C:\LCD.HEX":i
    found 5 busses
    
    avrdude: AVR device initialized and ready to accept instructions
    
    Reading | ################################################## | 100% 0.02s
    
    avrdude: Device signature = 0x1e9307
    avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
    
             To disable this feature, specify the -D option.
    avrdude: erasing chip
    avrdude: reading input file "C:\LCD.HEX"
    avrdude: writing flash (402 bytes):
    
    Writing | ################################################## | 100% 0.16s
    
    
    
    avrdude: 402 bytes of flash written
    
    [b]avrdude: safemode: lfuse changed! Was fd, and is now ff
    Would you like this fuse to be changed back? [y/n] N
    avrdude: safemode: hfuse changed! Was d9, and is now ff
    Would you like this fuse to be changed back? [y/n] N
    avrdude: safemode: Fuses OK[/b]
    
    avrdude done.  Thank you.


    Chodzi mi o te zmiany fuse bitów na samym końcu. Występuje to w formie pytania, jeżeli wybiorę N, to efekt jest taki jak w kodzie, jeżeli wybieram Y to avrdude się zawiesza (dioda pracy programatora się świeci, a avrdude nie daje oznak życia - chyba ze 20min czekania to dalej za krótko).

    EDIT:

    Kod z próby zmiany fuse bitów:

    
    avrdude -p atmega8 -c usbasp -V -U lfuse:w:0xE1:m -U hfuse:w:
    0xD9:m -U lock:w:0x3F:m
    found 5 busses
    
    avrdude: AVR device initialized and ready to accept instructions
    
    Reading | ################################################## | 100% 0.02s
    
    avrdude: Device signature = 0x1e9307
    avrdude: reading input file "0xE1"
    avrdude: writing lfuse (1 bytes):
    
    Writing |                                                    | 0% 0.00s ***faile
    d;
    Writing | ################################################## | 100% 0.11s
    
    avrdude: 1 bytes of lfuse written
    avrdude: reading input file "0xD9"
    avrdude: writing hfuse (1 bytes):
    
    Writing |                                                    | 0% 0.00s ***faile
    d;
    Writing | ################################################## | 100% 0.11s
    
    avrdude: 1 bytes of hfuse written
    avrdude: reading input file "0x3F"
    avrdude: writing lock (1 bytes):
    
    Writing | ################################################## | 100% 0.00s
    
    avrdude: 1 bytes of lock written
    
    [b]avrdude: safemode: lfuse changed! Was e1, and is now ff
    Would you like this fuse to be changed back? [y/n] y[/b]
    


    Jak widać, po drodze są jakies failed... :(

    Czemu się dzieją takie rzeczy, i od czego są te fuse bity które mi się same przestawiają? Czy to ma jakis negatywny wplyw na sam procesor? Mój programator to USBasp, i z powodzeniem nim progromowalem juz Attiny13 i Attiny2313.

    Z góry dziękuję za odpowiedź i pozdrawiam!
  • #2 6838387
    janbernat
    Poziom 38  
    Sprawdź program.
    Skoro nawet w Bascomie jest dyrektywa $prog pozwalająca na automatyczną zmianę fusebitów przy programowaniu procesora to w innych językach pewnie też jest coś podobnego.
    A jak avrdude podaje że pracuje w trybie bezpiecznym (safemode) to widocznie ostrzega że program chce zmieniać fusebity.
  • #3 6838458
    Konto nie istnieje
    Konto nie istnieje  
  • #4 6839090
    mirekk36
    Poziom 42  
    teraz poczytałem na spokojnie o twoim problemie i widzę ta pytania na końcu, które zadaje avrdude - to zwróciło moją uwagę ponieważ - przedwczoraj miałem dokładnie TEN SAM PROBLEM - tyle że w nieco innych okolicznościach i doszedłem co było przyczyną u mnie. U ciebie może być niestety coś innego ale....

    ja akurat programowałem procki ATTiny13 - i przestawianie fusów działało w każdą stronę dobrze do momentu gdy ! .... włączyłem w FUSE HIGH - BODLEVEL na 4,3V

    od tego momentu - już nie mogłem za chiny zmienić ustawień HFUSE !!!! a potrzebowałem koniecznie przeprogramować RSTDISBL

    oczywiście procki działają ale właśnie: ........

    gdy próbowałem zapisać nową wartość HFUSE - to avrdude zaczęło mi zadawać takie pytania dokładnie jak tobie ;) i jeśli dawałem 'n' to nic się nie działo - a gdy dawałem 'y' to też się biedne avrdude zawieszało :(

    miałem na szczęście 8 szt tych procków - więc po 3 nieudanych próbach - wziąłem kolejne i jako piwerwsze w HIGH FUSE przestawiłem nie Bodlevel tylko RSTDISBL - i EUREKA! ;) - wtedy się udało - ale bez włączania uprzednio kociego BODLEVEL'a!

    nie wiem dlaczego się tak dzieje w przypadku Tiny13 ale już wiem, że jak chcę poprzestawiać inne fuski poza BODLEVEL to lepiej najpierw poustawiać te inne a później na końcu dopiero BODLEVEL ;)

    myślałem ze miałem za niskie napięcie zasilające - ale skąd! - prosto z zasilacza kompa (przez USB) 4,92V - i dałem jeszcze duuuży kondensator elektrolityczny przy zasilaniu proca - ale to nic nie zmienia - i tych trzech procków już nie mogę odprogramować z tego BODLEVEL'a

    .... może ty też przestawiłeś BODLEVEL?
  • #5 6841238
    Belialek
    Poziom 22  
    BODLEVEL nie ruszany (nawet nie wiem co to:))

    Próba zmiany lfuse (bo to jest winowajca):



    
    M:\avr\avrdude-gui>avrdude.exe -p m8 -c usbasp -U lfuse:w:0xE4:m
    found 5 busses
    
    avrdude.exe: AVR device initialized and ready to accept instructions
    
    Reading | ################################################## | 100% 0.00s
    
    avrdude.exe: Device signature = 0x1e9307
    avrdude.exe: reading input file "0xE4"
    avrdude.exe: writing lfuse (1 bytes):
    
    Writing |                                                    | 0% 0.00s ***faile
    d;
    Writing | ################################################## | 100% 0.11s
    
    avrdude.exe: 1 bytes of lfuse written
    avrdude.exe: verifying lfuse memory against 0xE4:
    avrdude.exe: load data lfuse data from input file 0xE4:
    avrdude.exe: input file 0xE4 contains 1 bytes
    avrdude.exe: reading on-chip lfuse data:
    
    Reading | ################################################## | 100% 0.02s
    
    avrdude.exe: verifying ...
    avrdude.exe: verification error, first mismatch at byte 0x0000
                 0xe4 != 0xff
    avrdude.exe: verification error; content mismatch
    
    avrdude.exe: safemode: lfuse changed! Was e4, and is now ff
    Would you like this fuse to be changed back? [y/n] n
    avrdude.exe: safemode: hfuse changed! Was d9, and is now ff
    Would you like this fuse to be changed back? [y/n] n
    avrdude.exe: safemode: Fuses OK
    
    avrdude.exe done.  Thank you.
    


    W programie nie było na pewno żadnej dyrektywy do zmiany fuse bitów - to było proste "Hello World" na LCD. Połączenia sprawdzone kilkukrotnie, sam odczyt odbywa się bez żadnych problemów:

    lfuse:
    :01000000FD02
    :00000001FF
    


    hfuse:
    :01000000D926
    :00000001FF
    


    Podstawka do programatora jest wyposażona w kwarc 4MHz - czyli dokładnie taki na jaki przestawiłem Atmege (od tej pory się dzieją te straszliwe rzeczy...). Odlutować kwarc? Coś to zmieni?

    Do najbliższego sklepu z uC mam jakieś 100km, a akurat w weekend znajdę trochę czasu żeby siąść do pisania programu, a tu takie coś... Dlatego w dalszym ciągu będę wdzięczny za każdą sugestię :)

    Pozdrawiam!
  • #6 6844062
    aut18
    Poziom 12  
    Piszesz o 4MHz na podstawce, a na początku Dude programował domyślnie 1MHz wewnetrznym RC.
    Następnie lfuse E4 dalej nie wskazuje na zewnetrzny kwarc.
    Sprawdź datashet nr: doc8159atmega8a.pdf str.25 u Atmela
    Zobacz niezły kalkulator fusebitów pod adresem http://www.engbedded.com/fusecalc/
    Jak masz daleko do sklepu (no i nie ma takich 24h/24h) to pozwól sobie na domyślny zegar wewnętrzny 1Mhz.
    Mam nadzieję, że masz w zanadrzu 2 czysty procek.
    Ja używam odpowiednika STK500 na USB pod AVR Studio i nie mam już tych problemów z Dude - przy częstym testowaniu i modyfikacji programu doceniam komfort: 1 program IDE z programatorem, minimum kombinacji prowadzących do tzw. czeskich błędów.
    Krzysztof
  • #7 6844217
    Nagus
    Poziom 27  
    LFUSE = 0xFD czyli CKSEL masz ustawione na kwarc o częstotliwości 0.9 - 3.0 MHz, zatem po podpięciu rezonatora 4 MHz ma prawo nie działać...
  • #8 6844357
    mirekk36
    Poziom 42  
    Nagus napisał:
    LFUSE = 0xFD czyli CKSEL masz ustawione na kwarc o częstotliwości 0.9 - 3.0 MHz, zatem po podpięciu rezonatora 4 MHz ma prawo nie działać...


    kolega ma jakieś problemy z przeliczaniem fusków ???? 0xFB ustawia na 0.9 - 3.0 MHz natomiast 0xFD na 3.0 - 8.0MHz i nie inaczej
REKLAMA