Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

atmega8a - Nie działa atmega8a - zepsułem?

wszak 24 Cze 2014 14:27 2325 4
  • #1 24 Cze 2014 14:27
    wszak
    Poziom 8  

    Witam,

    W skrócie - mam 2x atmega8a-pu kupione na allegro. Chce na tym uruchomić najprostsza migającą diodę.
    Drobne utrudnienie, że działam spod linuxa, ale to chyba nie powinno mieć wpływu. Programator mam usbAsp.

    I teraz cała historia moich zmagań:
    Podłączyłem sobie wszystko wg. schematów dostępnych w sieci, z uwzgl. pinów mojego procka. W Arduino IDE załadowałem projekt/schemat Blink - tj migająca dioda. Pierwsza próba wysłania na procek - "udana". Tj były jakieś warningi, ale nic poza tym. Niestety dioda nie zaczęła migać. To sobie pomyślałem, że skoro to program korzystający z bibl. Arduino, to pewnie trzeba najpierw wgrać bootloader Arduino. To i wgrałem ten bootloader. Z tym, że w ArduinoIDE nie ma Atmega8a, więc wybrałem "Arduino NG or older w/ atmega8" sugerując się opinią z internetu, że 8 i 8a są właściwie takie same. Niestety dostałem wtedy komunikat błedu:

    Code:
    avrdude: warning: cannot set sck period. please check for usbasp firmware update.
    
    avrdude: error: programm enable: target doesn't answer. 1
    avrdude: initialization failed, rc=-1


    Od tego czasu już dostawałem ww komunikat - czy chciałem wysłac program czy bootloader na procka.
    Zastanawiałem się w czym rzecz i wymyśliłem, że w schemacie Blink, domyślnie led miał mrugać na pinie 13. Ja podłączyłem diodę do pinu 13 ale fizycznego (tj. 13. nóżki uC) i być może dlatego nie mrugała dioda. A pin 13 to pin SCK czyli ten o którym mówi powyższy komunikat błedu. Więc sobie wymyśliłem, że może przeprogramowałem uC (znaczy ten pin) tak, że teraz już się go nie da więcej przeprogramować, bo zamiast funkcji "sck" teraz ten pin będzie zawsze mrugał diodą ;) (tak na chłopski rozum) Ale i tak nie mruga.

    Więc... wziąłem drugi uC i tym razem pomyślałem, że najpierw wgram bootloader a potem schemat Blink ze zmienionym pinem led na 2 (jakiś "bezpieczny" pin). No ale sytuacja powtórzyła się tj. po wgraniu BL (BootLoadera) dostaję ten sam komunikat.

    Odpalając avrdude z linii poleceń, z param. -F dostaję:

    Code:
    avrdude -p atmega8 -c usbasp -F
    
    avrdude: warning: cannot set sck period. please check for usbasp firmware update.
    avrdude: error: programm enable: target doesn't answer. 1
    avrdude: initialization failed, rc=-1
    avrdude: AVR device initialized and ready to accept instructions
    avrdude: Device signature = 0xc8f761
    avrdude: Expected signature for ATmega8 is 1E 93 07

    Ten 0xc8f761 jest zmienny - trochę inny za każdym wywołaniem.


    Teraz wypadałoby spróbowac wgrać sam zmodyfikowany Blink bez BL, ale nie mam już 3-ciego uC...

    Żeby nie było że to może wina linuxa, podmapowałem ten programator USB do Windowsa XP działającego w wirtualnej maszynie. Odpaliłem tam też mkAvrKalkulator odpowiednio skonf. ale dalej jest ten sam błąd - z tą różnicą, że jego wersja avrdude powiada, że Device signature = 0x000000.





    Więc pomyślałem, że może zbrikowałem moje uC wgrywając ten bootloader. Sprawdzam konfig Arduino IDE (dla "Arduino NG or older w/ atmega8") i tam widzę, że jako fusebity on ma wpisane

    Code:
    atmega8.bootloader.low_fuses=0xdf
    
    atmega8.bootloader.high_fuses=0xca
    atmega8.bootloader.unlock_bits=0x3F
    atmega8.bootloader.lock_bits=0x0F


    Wpisałem te wartości (df ca) do mkAvrKalkulator żeby zobaczyć co one znaczą. I ten pokazuje, że przy tych fusebitach nie jest ustawiona żadna częstotliwość zegara - ani wewn. ani zewn. Nie wiem w ogóle jak to możliwe, że się tak da, no ale możecie sobie sami sprawdzić.

    Potem znalazłem na stronach forum konfig dla atmegi8a do ArduinoIDE, no ale to już trochę za późno.


    Co dalej... znalazłem informacje że czasami pomoże podłączenie zewnetrznego zegara na takie czesciowo "zablokowane" uC. Nie mialem kondensatorow do kwarcu, ale czytam, ze moze to byc dowolny prostokatny sygnal - poskladalem wiec generator na ne555 zgodnie z tym schematem:
    http://www.talkingelectronics.com/projects/555/Page2-555.html
    Dalem R1=1k, R2=10k i C=22nF co daje czestotliwosc ok 3kHz. Sygnal wyjsciowy dalem na nozke xtal1 uC, ale nic sie nie zmienilo.
    (probowalem tez uruchamiac avrdude z parametrem -B 1000 itp, ale nie nie mialo to wplywu)

    Poskladalem to samo na innej plytce stykowej - to samo.

    Podlaczylem tez na innym komputerze z windowsem - jw.


    Czy możliwe, że faktycznie wina leży po stronie tych fusebitów? Że to te ustawienia powodują takie właśnie zachowanie uC? Czyli wgranie bootloadera z najnowszego ArduinoIDE powoduje zablokowanie uC?
    Może ma ktoś niepotrzbny uC i chce to sprawdzić? :->

    Na chwile obecna skonczyly mi sie pomysly co z tym zrobic. Pomozecie?

    A ponizej fotka tego cudeńka:
    atmega8a - Nie działa atmega8a - zepsułem?

    Z góry dziękuję za pomoc!

    0 4
  • #2 24 Cze 2014 21:56
    emarcus
    Poziom 35  

    wszak napisał:
    Witam,

    W skrócie - mam 2x atmega8a-pu kupione na allegro. Chce na tym uruchomić najprostsza migającą diodę.
    Drobne utrudnienie, że działam spod linuxa, ale to chyba nie powinno mieć wpływu. Programator mam usbAsp.

    I teraz cała historia moich zmagań:
    Podłączyłem sobie wszystko wg. schematów dostępnych w sieci, z uwzgl. pinów mojego procka. W Arduino IDE załadowałem projekt/schemat Blink - tj migająca dioda. Pierwsza próba wysłania na procek - "udana". Tj były jakieś warningi, ale nic poza tym. Niestety dioda nie zaczęła migać. To sobie pomyślałem, że skoro to program korzystający z bibl. Arduino, to pewnie trzeba najpierw wgrać bootloader Arduino. To i wgrałem ten bootloader. Z tym, że w ArduinoIDE nie ma Atmega8a, więc wybrałem "Arduino NG or older w/ atmega8" sugerując się opinią z internetu, że 8 i 8a są właściwie takie same. Niestety dostałem wtedy komunikat błedu:

    Code:
    avrdude: warning: cannot set sck period. please check for usbasp firmware update.
    
    avrdude: error: programm enable: target doesn't answer. 1
    avrdude: initialization failed, rc=-1


    Od tego czasu już dostawałem ww komunikat - czy chciałem wysłac program czy bootloader na procka.
    Zastanawiałem się w czym rzecz i wymyśliłem, że w schemacie Blink, domyślnie led miał mrugać na pinie 13. Ja podłączyłem diodę do pinu 13 ale fizycznego (tj. 13. nóżki uC) i być może dlatego nie mrugała dioda. A pin 13 to pin SCK czyli ten o którym mówi powyższy komunikat błedu. Więc sobie wymyśliłem, że może przeprogramowałem uC (znaczy ten pin) tak, że teraz już się go nie da więcej przeprogramować, bo zamiast funkcji "sck" teraz ten pin będzie zawsze mrugał diodą ;) (tak na chłopski rozum) Ale i tak nie mruga.

    Więc... wziąłem drugi uC i tym razem pomyślałem, że najpierw wgram bootloader a potem schemat Blink ze zmienionym pinem led na 2 (jakiś "bezpieczny" pin). No ale sytuacja powtórzyła się tj. po wgraniu BL (BootLoadera) dostaję ten sam komunikat.

    Odpalając avrdude z linii poleceń, z param. -F dostaję:

    Code:
    avrdude -p atmega8 -c usbasp -F
    
    avrdude: warning: cannot set sck period. please check for usbasp firmware update.
    avrdude: error: programm enable: target doesn't answer. 1
    avrdude: initialization failed, rc=-1
    avrdude: AVR device initialized and ready to accept instructions
    avrdude: Device signature = 0xc8f761
    avrdude: Expected signature for ATmega8 is 1E 93 07

    Ten 0xc8f761 jest zmienny - trochę inny za każdym wywołaniem.


    Teraz wypadałoby spróbowac wgrać sam zmodyfikowany Blink bez BL, ale nie mam już 3-ciego uC...

    Żeby nie było że to może wina linuxa, podmapowałem ten programator USB do Windowsa XP działającego w wirtualnej maszynie. Odpaliłem tam też mkAvrKalkulator odpowiednio skonf. ale dalej jest ten sam błąd - z tą różnicą, że jego wersja avrdude powiada, że Device signature = 0x000000.

    Więc pomyślałem, że może zbrikowałem moje uC wgrywając ten bootloader. Sprawdzam konfig Arduino IDE (dla "Arduino NG or older w/ atmega8") i tam widzę, że jako fusebity on ma wpisane

    Code:
    atmega8.bootloader.low_fuses=0xdf
    
    atmega8.bootloader.high_fuses=0xca
    atmega8.bootloader.unlock_bits=0x3F
    atmega8.bootloader.lock_bits=0x0F


    Wpisałem te wartości (df ca) do mkAvrKalkulator żeby zobaczyć co one znaczą. I ten pokazuje, że przy tych fusebitach nie jest ustawiona żadna częstotliwość zegara - ani wewn. ani zewn. Nie wiem w ogóle jak to możliwe, że się tak da, no ale możecie sobie sami sprawdzić.(???)
    ..............
    Potem znalazłem na stronach forum konfig dla atmegi8a do ArduinoIDE, no ale to już trochę za późno.

    Co dalej...



    Na początek należy wyjaśnic kilka występujących tu aspektów:
    Na 'surowym' processorze chcesz tworzyc/pracowac w srodowisku kompatybilnym z Arduino.
    Czym różni się Arduino od standardowego/dowolnego układu tworzonego na płytce stykowej, lub trawionej we własnym zakresie.
    Odp.- w zasadzie niczym, poza częstotliwościa taktowania processora, która oryginalnie dla Arduino oraz w większości przykładów wynosi 16 MHz.
    Fusebity które zmieniłeś odpowiadaja tym kryteriom, zatem układ wymaga podłączenia takiego rezonatora kwarcowego; nie tylko dla funkcjonalności wpisanego programu , ale także do kolejnej komunikacji z processorem, ale przez bootloader. Ma zmieniony adres startowy po resert (bit# 0 w Low Fuse Byte).

    Drugie pytanie: Do czego Arduino potrzebuje bootloader i jak go wykorzystuje?
    Odp:...itd. Tu można ciągnąc pytania bez końca...

    Ty programujesz processor programatorem USB-ASP przez ISP port (MISO, MOSI, SCK), zatem wpisany bootloader jest bezużyteczny i zajmuje tylko miejsce w pamięci flash oraz dodatkowo wprowadza 'bałagan' w komunikacji.

    Korzystając z programów tworzonych w Arduino, należy pamiętac że Arduino nie stosuje rzeczywistych numeracji portów spotykanych w notach katalogowych processorów, lecz odnoszą się one do oznakowań na oryginalnych płytkach; zatem potrzebny jest pewien "klucz" - 'Pin Mapping'.
    http://arduino.cc/en/Hacking/PinMapping
    http://arduino.cc/en/Hacking/PinMapping168

    e marcus

    0
  • #3 24 Cze 2014 22:56
    wszak
    Poziom 8  

    emarcus napisał:

    Wpisałem te wartości (df ca) do mkAvrKalkulator żeby zobaczyć co one znaczą. I ten pokazuje, że przy tych fusebitach nie jest ustawiona żadna częstotliwość zegara - ani wewn. ani zewn. Nie wiem w ogóle jak to możliwe, że się tak da, no ale możecie sobie sami sprawdzić.(???)


    Odpowiadam na "???" - możecie sprawdzić tj wpisać w mkAvrCalculator te wartosci "df ca" i wtedy program w swoich zakładkach pokaże co te wartości oznaczają. W zakładce dot. zegara pokazuje, że żaden zegar (wewn. ani zewn.) nie jest ustawiony.

    emarcus napisał:

    Odp.- w zasadzie niczym, poza częstotliwościa taktowania processora, która oryginalnie dla Arduino oraz w większości przykładów wynosi 16 MHz.


    Ok - ale ja właśnie myślałem, że to powinien pokazać mkAvrCalculator - że te fusebity oznaczają że uC spodziewa się zegara np. 16MHz. A nie pokazuje nic, stąd moje zdziwko.

    emarcus napisał:

    Fusebity które zmieniłeś odpowiadaja tym kryteriom, zatem układ wymaga podłączenia takiego rezonatora kwarcowego; nie tylko dla funkcjonalności wpisanego programu , ale także do kolejnej komunikacji z processorem, ale przez bootloader. Ma zmieniony adres startowy po resert (bit# 0 w Low Fuse Byte).


    Czyli chcesz powiedzieć, że podłączenie kwarcu 16MHz "ożywi" uC?
    W sumie właśnie oczekuję kwarcu 16MHz i kondensatorów z pewnego portalu aukcyjnego, więc wkrótce zweryfikuję tę hipotezę...

    Nie rozumiem niestety co chciałeś powiedzieć pisząc "z processorem, ale przez bootloader". Że teraz avrdude ma się komunikować z uC za pośrednictwem bootloadera? Czy on aby o tym wie i umie to robić? ;-)

    emarcus napisał:

    Drugie pytanie: Do czego Arduino potrzebuje bootloader i jak go wykorzystuje?
    Odp:...itd. Tu można ciągnąc pytania bez końca...


    No właśnie - w sumie dobre pytanie. Wgrałem ten bootloader, bo w którymś z wielu tutoriali też go wgrywali. Teraz czytam, że właściwie nie jest on konieczny.
    To po kiego jest ta opcja? Do czego to się przydaje?

    emarcus napisał:

    Ty programujesz processor programatorem USB-ASP przez ISP port (MISO, MOSI, SCK), zatem wpisany bootloader jest bezużyteczny i zajmuje tylko miejsce w pamięci flash oraz dodatkowo wprowadza 'bałagan' w komunikacji.


    To jak się z tego wycofać? Tj jak usunąć ten bootloader, żeby było jak na początku?

    emarcus napisał:

    Korzystając z programów tworzonych w Arduino, należy pamiętac że Arduino nie stosuje rzeczywistych numeracji portów spotykanych w notach katalogowych processorów, lecz odnoszą się one do oznakowań na oryginalnych płytkach; zatem potrzebny jest pewien "klucz" - 'Pin Mapping'.
    http://arduino.cc/en/Hacking/PinMapping
    http://arduino.cc/en/Hacking/PinMapping168


    Tak, tak, to już "odkryłem", pisałem o tym.

    0
  • Pomocny post
    #4 25 Cze 2014 07:15
    emarcus
    Poziom 35  

    wszak napisał:


    Ok - ale ja właśnie myślałem, że to powinien pokazać mkAvrCalculator - że te fusebity oznaczają że uC spodziewa się zegara np. 16MHz. A nie pokazuje nic, stąd moje zdziwko.



    Dla twojego większego zdziwienia: żaden FuseBit Calculator nie wskazuje na konkretną częstotliweśc powyżej 8 MHz.
    Porównaj z :
    http://www.engbedded.com/fusecalc/
    Masz tam tylko ustawienie dla
    "Ext. Crystal/Resonator High Freq.;Start-up time: 16K CK +64ms [CKSEL=1111 SUT=11]"
    Znaczy to że dla częstotliwości taktowania powyżej 8 MHz ( 10, 12....16..20MHz etc.) z zewnętrznym kwarcem stosujesz takie ustawienia fusebitów. Te 16 MHz jest narzucone przez Arduino.

    Cytat:


    Czyli chcesz powiedzieć, że podłączenie kwarcu 16MHz "ożywi" uC?

    Powinien,.... jeżeli bootloder nie jest 'sknocony'.- o tym będzie niżej...

    Cytat:

    Nie rozumiem niestety co chciałeś powiedzieć pisząc "z processorem, ale przez bootloader". Że teraz avrdude ma się komunikować z uC za pośrednictwem bootloadera? Czy on aby o tym wie i umie to robić? ;-)


    Jeżeli masz w processorze bootloader i jest on 'enabled' fusebitem BOOTRST (bit 0 w Table 87. Fuse High Byte - datasheet), to po włączeniu lub Reset, processor nie zaczyna exekwowac wpisanego tam programu, lecz ten fusebit kieruje do startu programu bootloadera, który odczekuje pewien czas, podczas którego spodziewana jest łącznośc poprzez port szeregowy TXD, RXD na wypadek gdybyś zechciał zmieni lub wpisac nowy program. Jezeli w tym czasie brak jest aktywności na tym porcie to wtedy dopiero zaczyna sie start zasadniczego programu.

    Jeżeli bootloader był przeznaczony dla Arduino NG, to był pisany pod kątem komunikacji z USB computera poprzez FTDI (FT232RL).
    Ty tej "ścieżki" nie używasz, więc nie potrzebujesz zwłoki w starcie programu.

    Cytat:

    To jak się z tego wycofać? Tj jak usunąć ten bootloader, żeby było jak na początku?



    Zwyczajnie, mając podpięty rezonator kwarcowy (w tym momencie nie musi byc 16 MHz), kasujesz całą zawartośc pamięci flash (program razem z bootloaderem); wymaga ponownego wpisania programu, oraz zmienasz wyżej wspomniany fusebit BOOTRST na 'niezaprogramowany' wartośc 1 co spowoduje że po Reset, start programu będzie od adresu poczatku applikacji (0x0000) a nie od adresu sekcji bootloadera. Jeżeli program wpisywałeś przez programator do processora, już po załadowaniu do jego pamięci bootloadera, to prawdopobnie został on juz automatycznie wykasowany. Tylko programowanie przez bootloader zabezpiecza go przed wykasowaniem.

    e marcus

    0
  • #5 25 Cze 2014 12:09
    wszak
    Poziom 8  

    emarcus napisał:
    Zwyczajnie, mając podpięty rezonator kwarcowy (w tym momencie nie musi byc 16 MHz), kasujesz całą zawartośc pamięci flash (program razem z bootloaderem); wymaga ponownego wpisania programu, oraz zmienasz wyżej wspomniany fusebit BOOTRST na 'niezaprogramowany' wartośc 1 co spowoduje że po Reset, start programu będzie od adresu poczatku applikacji (0x0000) a nie od adresu sekcji bootloadera. Jeżeli program wpisywałeś przez programator do processora, już po załadowaniu do jego pamięci bootloadera, to prawdopobnie został on juz automatycznie wykasowany. Tylko programowanie przez bootloader zabezpiecza go przed wykasowaniem.


    Działa! Wylutowałem kondensatory z jakiegoś starego TV, dałem kryształ ~15MHz i zaraz komunikacja "wstała". Udało się wgrać program i dioda piknie mryga ;)

    Ciekawe czemu nie działało jak dawałem zegar z ne555 - 3kHz - za wolny?

    Tak sobie teraz myśle, że właściwie to mi się nigdy nie udało tego BL wgrać - bo najpierw wgrywałem program i on od razu zmienił fusebity na takie, że wymagany był zewn. kryształ. Potem próbowałem wgrać BL, ale już komunikacji z uC nie było, bo nie było kryształu, więc się BL nie wgrał. Możliwe że tak było?

    Się zastanawiam jeszcze - czy mogę teraz tak zmienić te fusebity, żeby uC używał wewn. zegara np. 8MHz i żeby na tym działał Arduino (bo piszesz, że te 16MHz jest "narzucone" przez Arduino). Tak samo - czy się da na wewn. zegar 1MHz.

    A z tym bootloaderem rozumiem to tak, że nie trzeba go wgrywać, jeżeli programuję przez usbAsp - dobrze to rozumiem?

    EDIT - ok chyba już wszystko wiem...
    Jednak wgrałem wtedy ten bootloader. Samo wgrywanie programu nie zmienia fusebitów - dopiero opcja wgrania BL zmienia fusebity.

    Udało też mi się odpalić Arduino na wewn. oscylatorze 1MHz - tu jest napisane co trzeba dodać do pliku boards.txt w ArduinoIDE.

    0