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.

[Bascom AVR] Bootloader (ATmega 644P, wykorzystane 60% flash)

MES Mariusz 14 Lis 2014 10:34 1641 10
  • #1 14 Lis 2014 10:34
    MES Mariusz
    Poziom 36  

    Witam.

    Zrobione jest urządzenie na uP AVR ATmega 644P.
    Komunikuję się z nim po UART za pomocą instrukcji znakowych.

    Nigdy nie bawiłem się wcześniej z bootloaderem, ale teraz (skoro pozostało mi 40% wolnego z 64 kB flash-u) zastanawiam się czy go nie wdrożyć.

    Myślę o wysłaniu po UART komendy "upgrade" która spowoduje odesłanie odpowiedzi "waiting for firmware.hex" i zainicjuje oczekowanie na plik hex po UART.

    Jak to zrobić? Co z obsługą błędów / jak zagwarantować, że błędy transmisji nie uszkodzą firmware podczas programowania?

    Pytanie do osób, które miały okazję przerobić temat.

    0 10
  • #2 14 Lis 2014 13:38
    MArSTER_1
    Poziom 18  

    Używam BootLoadera zarówno ładującego oprogramowanie przez RS jak i przez TCP/IP do ATmegi 644P. Kontrola błędów to sprawdzanie sumy kontrolnej. Działa bezawaryjnie od lat nawet z drugiego końca Polski (przez TCP/IP).

    0
  • Pomocny post
    #3 14 Lis 2014 14:41
    tmf
    Moderator Mikrokontrolery Projektowanie

    MES Mariusz - w żaden sposób nie zagwarantujesz, że firmware się nie uszkodzi. W końcu zawsze można przerwać transmisję lub programowanie w dowolnej chwili, prawda? Jedyne co możesz zrobić to uodpornić się na takie sytuacje. Czyli przed startem firmware startuje bootloader i sprawdza jego integralność. Jeśli ok, to startuje firmware, jeśli nie to robi jedyną rozsądną rzecz - czeka na nowy firmware.

    0
  • #4 15 Lis 2014 00:10
    MES Mariusz
    Poziom 36  

    Ile pamięci zżera wam obsługa bootloadera (o ile są tu użytkownicy Bascom AVR) ? Mi zostało jakieś 40% z 64 kB. Wygląda na w miarę przyzwoicie?

    Jakieś materiały (godne polecenia) dla kogoś, kto nie uruchamiał jeszcze nigdy bootloadera, a chciałby to zrobić w Bascom AVR, włącznie z obsługą crc, bo przyznać muszę, że obecna komunikacja - sterowanie urządzeniem za pomocą komend (stringów) realizowana jest u mnie bez crc... Używam prędkości 4800, 8N1, bez bitów parzystości. Wszystko śmiga po RS485 (na MAX485) do sieci podłączonych jest 9 urządzeń. Idealne byłoby programowanie wszystkich urządzeń jednocześnie (aplikowanie nowego firmware), ale o tym, póki co nie marzę. Jeśli uda mi się zrobić bootloader dla pojedynczego urządzenia po sieci RS485, będę wniebowzięty...

    0
  • #6 15 Lis 2014 11:30
    tmf
    Moderator Mikrokontrolery Projektowanie

    Nie wiem jak zrobić obsługę bootloadera w BASCOMie, ale jeśli nie ma gotowych funkcji/bibliotek to bez asemblera się nie obejdzie. Przede wszystkim bootloader musi siedzieć w odpowiednim obszarze pamięci, nie musi być w całości w obszarze bootloadera, chociaż to wygodne, ze względu na odrębne lockbity dla tego obszaru pamięci. Trzeba zagwarantować, aby instrukcja programująca FLASH znalazła się w obszarze bootloadera, a konkretnie NRWW. Nie wiem jak BASCOM sobie radzi ze zmianami adresów sekcji itd. Jeśli korzystasz z przerwań to trzeba też przenieść tabelę wektorów przerwań, a właściwie zrobić jej kopię, żeby programowanie FLASH jej nie zepsuło. Jak widzisz wymaga to wszystko dobrej kontroli nad rozlokowaniem kodu i generowaniem kodu startowego, na ile BASCOM to umożliwia to nie wiem.

    0
  • #7 15 Lis 2014 14:33
    MArSTER_1
    Poziom 18  

    Wszystko to co napisał tmf jest w Bascomie możliwe. Moje BootLoadery są napisane w Bascomie.

    0
  • #8 19 Lis 2014 12:05
    MES Mariusz
    Poziom 36  

    No dobra. Pierwsze kroki.

    Teoria:
    http://ep.com.pl/files/3561.pdf

    Aplikacja do testów:
    http://www.mcselec.com/index.php?option=com_content&task=view&id=159&Itemid=57

    Kod bootloadera:
    http://avrhelp.mcselec.com/index.html?loader.htm


    1. W urządzeniu na ATmega644p stosuję wewnętrzny oscylator 8MHz i prędkość transmisji po UART 4800 baud (8N1, no parity). Podobno zalecany jest rezonator kwarcowy. Ciekawe jak to się będzie sprawdzać na oscylatorze wewnętrznym. Jeśli komunikacja po UART (RS485) mi działa, to może i bootloader również będzie.

    2. Programowe inicjowanie bootloadera wygląda na proste (instrukcja goto &HC00).

    3. Kod źródłowy bootloadera jest (http://avrhelp.mcselec.com/index.html?loader.htm).


    Cytat:
    Jeśli korzystasz z przerwań to trzeba też przenieść tabelę wektorów przerwań


    Owszem, w programie używam przerwań:

    TIMER1 (16 bit) - odliczanie 0,0001s odcinków czasu
    TIMER2 (8 bit) - obsługa odbiornika RC5

    Również UART obsługiwany z przerwania:
    Enable Urxc
    On Urxc Odbierz

    Mam nadzieję, że kompilator zajmie się wszystkim, co trzeba.

    Dodano po 10 [minuty]:

    Domyślam się, że po wykonaniu skoku mam jakiś czas na przesłanie firmware. Do komunikacji PC <-RS485-> ATmega644P wykorzystuję uruchomioną na PC (linux) aplikację minicom.

    Wysłanie instrukcji "fw upgrade" spowoduje na ATmega644P skok do obszaru bootloader-a. Rozumiem, że wówczas (zaraz po ręcznym wysłaniu polecenia fw upgrade") mogę za pomocą minicoma wysłać jakiś plik .hex

    Zastanawiam się, skąd uP będzie wiedział, że nastąpił koniec przesyłania pliku (koniec wgrywania pliku hex). Czy nastąpi reset uP?

    0
  • Pomocny post
    #9 19 Lis 2014 16:11
    tmf
    Moderator Mikrokontrolery Projektowanie

    ad 1. Oscylator zasadniczo musi być - na RC może to działać, ale nie musi, w dodatku działanie/niedziałanie będzie zależało od pogody nad biegunem.
    ad 3. Chodziło mi o wykorzystanie przerwań w kodzie bootloadera, w aplikacji nie ma to znaczenia.
    Tak jak piszą w artykule bootloader oczekuje dwóch znaków w określonym czasie co jest sygnałem do rozpoczęcia działania. Nie chce mi się zagłębiać w artykuł, ale chyba mi przemknęło, że ten BL używa plików bin. Warto też sprawdzić, czy przed odpaleniem aplikacji jakoś sprawdza jej integralność - w wielu systemach raczej nie można sobie pozwolić, aby procesor wykonywał losowy kod.

    0
  • #10 20 Lis 2014 16:16
    MES Mariusz
    Poziom 36  

    Ok. (doczytałem (str 99.), że po inicjacji bootloader (zdaje się, że chodzi o ten, konkretny bootloader) oczekuje na wartość 123 (programowanie flash) lub 124 (programowanie EEPROM).

    Oczekuje na wartość 123, czyli zapewne na przesłanie po sobie kolejno znaków "1", "2", "3" oraz kodu entera i powrotu karetki, tak przynajmniej zakładam. Chyba, że powinienem to zinterpretować inaczej?

    --- edit ---
    Chyba źle zakładałem, zdaje się, że mowa o przesłaniu wartości ASCII 123 lub 124 (co odpowiada przesłaniu znaku odpowiednio "{" lub "|").

    Zastanawia mnie jeszcze skąd bootloader "wie", że zakończono przesyłanie pliku bin, i kiedy można będzie wykonać reset / reboot.


    Dalej:

    Cytat:
    W tym przypadku ustawiono maksymalny obszar 1024 słów. Z tego sposobu wywołania korzysta program obsługujący bootloader (Bootloader.exe) oraz pakiet bascom AVR


    No dobra, nie bardzo zaskoczyłem (albo kwestia wyrwania z kontekstu?). Docelowo nie będę chciał używać ani wspomnianej aplikacji ani pakietu Bascom AVR. Po prostu mam zamiast przesłać po UART instrukcję "upgrade sw" i natychmiast zacząć przesyłać (tą samą drogą) plik bin.

    Pytanie czy powyższe ma jakiś związek z "obszarem 1024 słów", czy może ów enigmatyczny obszar, to po prostu obszar pamięci, i akurat taki (maksymalny) obszar zajmie skompilowany bootloader autorstwa MCS.

    Dodatkowo zastanawia mnie programowanie bootloadera. Czy jest to odrębny wsad bin / hex (w jaki sposób wybiera się to czy programowany jest akurat firmware czy bootloader) czy po prostu bootloader to integralna część firmware-u i programuje się to wszystko za jednym razem (pojedynczy plik bin / hex) ?

    Idąc za ciosem: czy dokonując upgrade firmwareu nadpisuje się również bootloader, czy też pozostaje on nietykalny?

    0
  • Pomocny post
    #11 20 Lis 2014 17:15
    tmf
    Moderator Mikrokontrolery Projektowanie

    Odpowiem ci na pytania dotyczące BL, bo jeśli chodzi o działanie przykładowego programu, to trzebaby go przeanalizować, a jak wiesz mam pewną awersję do BASCOMa :)
    Bootloader jest odrębną aplikacją i zazwyczaj przyjmuje się, że jest on "nietykalny" - to znaczy jest ładowany raz i zostaje na zawsze. Ponieważ sekcja bootloadera ma własne lockbity, po jego zaprogramowaniu zmienia się je tak, aby skasowanie bootloadera było niemożliwe (oczywiście zawsze możesz skasować cały procek programatorem). Także później wgrywasz wyłącznie kod aplikacji. Zwykle też bootloader pisze się samemu pod konkretne potrzeby. Przejrzyj też bootloader oferowany przez firmę Atmel - to bardzo porządny kawałek softu, obsługuje pliki hex, w tym szyfrowane pliki szyfrem AES. Oczywiście dla bootloadera nie ma znaczenia co wgrywasz, stąd też za jego pomocą możesz także wgrać kod wygenerowany przez BASCOM. Przykłądy zawarłem w swojej książce "Język C..." - same kody możesz pobrać za free - tam też jest kod aplikacji na PC, która szyfruje pliki. Dokładne info na temat bootloadera znajdziesz w nocie Atmela "AES bootloader", czy jakoś tak.

    0