Boberov Unbelievable Boot Loader V0.1 2013
Na wstępie skrócone informacje na temat projektu którego szerszy opis znajduje się w dalszej części tekstu.
Program bootloadera przeznaczony jest dla ATMEGA8 (po minimalnych zmianach każdy AVR z wystarczającą ilością pamięci), umożliwia programowanie procesora oraz zainstalowanych w systemie pamięci szeregowych I2C oraz SPI typu 25X16, 32, 64
Możliwość przeglądania zawartości pamięci.
Możliwość edycji zawartości RAM oraz EEPROM avr.
Komunikacja przez konsole szeregową.
Transfer danych do pamięci przez xmodem (crc).
Rozmiar kodu wynikowego 2kB (3kB w przypadku transferu odczytanej pamięci).
Opis właściwy
Do napisania bootloadera dla avr przymierzałem się już od pewnego czasu, ale jak zwykle nie chciałem żeby był to kolejny twór podobny do całej reszty swoich nudnych kolegów
W związku z tym zadbałem aby miał do zaoferowania w sobie nieco więcej niż tylko możliwość przetransferowania kilku bajtów danych z PC do pamięci procesora.
Zaczęło się od napisanego 10 lat temu „programatora elementów i2c”. Ponieważ do dzisiaj używam go do pamięci szeregowych współpracujących z avrkami, pomyślałem że czemu by nie zrobić podobnego programatora na AVR w końcu to tylko parę linijek kodu.
Pierwszym założeniem przy pisaniu loadera była więc możliwość programowania pamięci szeregowych I2C podłączonych do sprzętowej magistrali TWI.
Drugą równie potrzebną funkcjonalnością było programowanie pamięci ISP FLASH 25X32
z możliwością zmiany rejestru statusu co umożliwia zablokowanie lub odblokowanie jej fragmentów.
Na koniec pozostaje standardowa możliwość programowania FLASH ROM procesora, oraz jego EEPROMu oraz w ograniczonym zakresie możliwość zapisu lock bitów (tylko opcje związane z „boot code”).
Na deser postanowiłem dodać jeszcze możliwość zapisu pamięci RAM AVRa. Można więc zapisać prawie całą pamięć z wyłączeniem ostatnich 256B.
Transfer danych odbywa się za pomocą standardowego protokołu Xmodem wspieranego przez wiele programów terminalowych. Za pomocą terminala w standardzie VT100 loader będzie się z nami komunikował umożliwiając programowanie oraz podgląd pamięci. Niestety z powodu ograniczonego rozmiaru kodu w 2kB udało się „jedynie” zmieścić monitor wszystkich 5 pamięci, prymitywną edycję ram i eeprom AVRa oraz jak wspomniałem zapis z użyciem xmodemu.
Pod klawiszem 'e' na ten moment znajduje się dodatkowy kod umożliwiający odesłanie zawartości wybranej pamięci przez xmodem (najpierw trzeba nacisnąć e, później s).
Skoro mamy możliwość przeglądania pamięci, warto wspomnieć o funkcji związanej z prostym debuggingiem. W związku z tym BUBL na samym początku wykonuje zrzut rejestrów 0-96dec RAM. Umieszczając je na początku ostatnich 256B ram (tych niedostępnych do zapisu przez xmodem). Na tej ostatniej stronie znajduje się również bufor xmodemu oraz 16B zarezerwowane na stos loadera. Jeżeli boot loader zostanie wywołany bezpośrednio skokiem z programu głównego, może przejść automatycznie do wyświetlania wartości skopiowanych rejestrów (wartość R0-R31 będzie identyczne jak w miejscu wykonania skoku, pozostałe rejestry zależnie od typu) . W przypadku wywołania „ramdbg:” stos nie jest reinicjowany, co umożliwia powrót przez ret (klawisz „r”). Jeżeli boot loader zostanie uruchomiony przez sprzętowy reset lub power up, to oczekuje przez około 1 sekundę na „esc” z terminala po czym wykonuje skok do standardowego wektora resetu czyli 0. W przypadku rozpoznania ustawionej flagi resetu przez watchdoga następuje automatyczne wyświetlenie strony z „dumpem” rejestrów (niestety po jakimkolwiek zresetowaniu procesora rejestry z zakresu 32-96dec zostają ustawione na wartości domyślne). Oczywiście w każdym przypadku wywołania BUBLa cały ram poza ostatnią stroną pozostaje nietknięty i można sobie podejrzeć co się działo w programie przed przerwaniem. Jako ciekawostkę należy zauważyć, że wybranie adresu 7x256B (oczywiście mowa o ATMEGA8) powoduje wyświetlenie zarówno skopiowanych rejestrów, jak i rejestrów 'live', co może być przydatne w celach porównawczych. Dodatkowe wskazówki używania loadera do podglądu danych w trakcie pracy programu głównego znajdują się w źródle programu.
Nawigacja po programie odbywa się za pomocą przycisku Tab przełączając kolejno od „Strony startowej” przez każdą obsługiwaną pamięć. Poniżej krótki opis poszczególnych trybów / pamięci.
BUBL V0.1 2013
MCU: ATMEGA8 FF
SPI: EF3016 EF15 00
I2C: A0 A2 A4 A6 A8 AA AC AE
Opis danych strony startowej (informacje o systemie):
BUBL V0.1 2013: Tytul, Wersja loadera.
MCU: Typ procesora pod który skompilowany loader, bajt lock bitów (można szybko się zorientować czy procesor jest zabezpieczony przed odczytem, zapisem itp. Odblokowany procesor zwraca FF)
SPI: rozpoznane automatycznie 3Bajty w standardzie JEDEC- ID producenta, typ pamięci, pojemność, dodatkowo 2 bajty ID Producenta, typ pamięci, na końcu odczytany bajt rejestru statusu (można sprawdzić czy pamięć jest zablokowana)
I2C: Wszystkie adresy slave-ów które odpowiedziały poprzez ACK na standardowe wywołanie (loader przy każdym wywołaniu strony startowej skanuje 128 adresów I2C).
Opis obsługiwanych klawiszy:
„TAB” -Przełączanie menu, wybór pamięci
„1” -Adres MSB -
„2” -Adres MSB +
„3' -Adres LSB -
„4” -Adres LSB +
„5” -Wskaźnik bajtu (LSB)-
„6” -Wskaźnik bajtu (LSB)+
„0” -Zmiana ilości bajtów strony dla I2C, oraz dla SPI ilość bajtów kasowanych równocześnie podczas zapisu 4kB / 65kB (parametr przekłada się na szybkość programowania)
„Spacja” -Zerowanie Adresu
„`”- ustawienie MSB adresu 0XA0 160dec (ułatwienie w trybie i2c)
„j” -jump skok pod adres zwykłego wektora resetu
„e” – extended – wywołanie programu spod adresu końca romu -3kB (znajdą się tam dodatkowe programy bootloadera, nie pomieszczone w standardowych 2kB)
„r” - return – w przypadku wywołania bootladera przez call, można powrócić do programu wywołującego
„/” - przełącza widok z wartości szesnastkowych na ASCII
„-” - wartość komórki pamięci +1 (w obecnym momencie tylko ram+avreeprom)
„=” - wartość komórki pamięci -1 (jw.)
„|” - funkcja zależna od wybranej pamięci:
AVR_RAM: wypełnienie całej pamięci wartością wskaźnika bajtu (również ostatnie 256B jest kasowane)
AVR_ROM: załadowanie wartości wskaźnika bajtu do rejestru lockbitów (nie można z poziomu bootloadera zaprogramować lockbitów LB1 LB2)
SPI_FLASH: załadowanie do rejestru statusowego wskaźnika bajtu (blokowanie odblokowanie wybranych bloków pamięci flash – patrz manual do 25X opis rejestru statusowego)
Na każdej stronie pod etykietą pamięci znajdują się 2 bajty liczników wskazujących aktualnie przeglądany adres pamięci. 3ci licznik jest wykorzystywany do przesuwania kursora wskazującego bajt, oraz jako wartość w programach ustawiania lockbitów lub rejestru statusu w SPI. Ostatni licznik z literką P zmienia wartości na kolejne potęgi 2, wskazuje ilość bajtów strony jednocześnie transferowanej prze i2c (min 1, 8 dla małych pamięci, max 128 obsługiwane przez 24C512), bit.0 wybiera dla SPI_FLASH wielkość kasowanej strony, pamięć ta kasowana jest 4kB lub 64kB blokami przy każdym rozpoczętym 4/64kB bloku/sektorze.
Istotne jest, że w każdym trybie (wyjątek rom avr), ustawiony w edytorze adres wskazuje równocześnie początek zapisu dla transferu przez xmodem. Wartość wskaźnika adresu (pojedyncze bajty 0-255) jest w tym przypadku pomijana. Przesyłane dane są zawsze wyrównane do 256B strony. We wszystkich trybach przesłanie ilości bajtów nie wyrównane ze 128B spowoduje uzupełnienie przez wpisanie w brakujące miejsce przypadkowych wartości, tym samym minimalny rozmiar przesyłanych danych wynosi 128B i jest równy rozmiarem polu danych ramki xmodemu.
Programowanie Pamieci I2C
Dostępne są dwa tryby adresowania, zarówno dla małych eepromów <24C16 jak i większych z jedno bajtowym lub dwu bajtowym adresem.
W jednym i drugim przypadku najstarsza część adresu monitora wskazuje adres I2c.
Młodsza część adresu wskazuje MSB adresu bajtowego pamięci eeprom.
Wybierając Adres I2C z bitem.0 = 1 informujemy, że używamy pamięci z jednobajtowym adresem. Podczas adresowania jest wtedy odpowiednio ustawiany adres, a po załadowaniu 256B jest inkrementowany adres I2C, a nie jak w przypadku Adresu 2 bajtowego MSB adresu.
Loader i2c zwraca informację 'OVF ERROR' w przypadku odebrania zbyt wielu danych lub adresowania nie istniejącego slavea i2c ewentualnie w przypadku trybu dwu bajtowego po przewinięciu 16bit adresu.
W obu trybach początkowy adres wczytywania jest wyznaczony przez aktualnie ustawiony w monitorze adres (można wczytywać pod dowolny adres z wyrównaniem do strony).
Jak wcześniej wspomniano możliwy jest wybór wielkości strony dla programowania.
Większy rozmiar strony owocuje szybszym programowaniem, najmniejsze pamięci obsługują maksymalnie 8B stronę.
Szybkość programowania dla różnej wielkości strony programowanego układu 24C512
8B= 1.3kB/s, 16B= 2.7kB/s, 128B= 4.1kB/s
Programowanie Pamieci AVR_ROM
Pamięć ROM kontrolera zawsze jest programowana od komórki 0, do początku pamięci bootloadera (w kodzie można to zmienić, boot loader może mieć 3kB lub więcej, przy czym sprzętowo chronione lock bitami są oczywiście tylko ostatnie 2kB w których znajdują się kluczowe procedury). Po przekroczeniu ilości przesłanych bajtów loader zwraca 'OVF ERROR' i wysyła żądanie zatrzymania transferu (CAN). Pamięć w AVR jest kasowana stronami po 64B, tak więc możliwe jest ładowanie nowego programu przy zachowaniu części starego romu.
Współpraca z programami terminalowymi
Do testowania poprawności transmisji Xmodemu był używany Hyper Terminal, ponieważ jego działanie można uznać za wzorcowe. Obsługuje on zarówno tryb sumy kontrolnej, jak i CRC. Rozpoznaje też CAN-celację transferu po stronie odbiorcy. Drugim terminalem jakiego najczęściej używam to Tiny Terminal. Niestety nie rozpoznaje on CAN, a na dodatek wymaga wprowadzenia dodatkowego opóźnienia przed odesłaniem bajtu ACK / NAK, w innym razie przeprowadzenie poprawnego transferu jest niemożliwe (w kodzie można zmodyfikować to opóźnienie w celu maksymalizacji wydajności 'ACK_DELAY').
Zawieszające się TWI
Podczas testowania bubla rozwiązany został przy okazji „problem” okazjonalnej możliwości zawieszania się magistrali TWI atmegi (oczywiście żeby ją zawiesić, trzeba się nieco postarać np. wkładając i wyjmując eeprom podczas przesyłania danych. W normalnych warunkach nigdy nie napotkałem żadnych problemów z TWI mimo braku dodatkowych zabezpieczeń. Mimo to postanowiłem przyjrzeć się bliżej problemowi, co zaowocowało znalezieniem sposobu na „bezawaryjną pracę” TWI w warunkach „burzy magnetycznej”
. Fragment kodu automatycznie sprawdza poprawność wartości z 'twcr' i resetuje TWI w programie obsługi transferu TWI_B.inc (tryb MASTER).
Pouczenie
Podczas kompilacji BUBLa należy pamiętać o wpisaniu prawidłowej wartości bitrate dla usart, oraz ewentualnie skorygowaniu wartości osccal bez których współpraca z terminalem jest niemożliwa. Dla szybkości 115.2 należy stosować stabilny zegar (kwarc) RC może „odpłynąć” po zmianie temperatury. Na filmie można zobaczyć w skrócie możliwości loadera, oraz koegzystencję z programem głównym (widać przeglądanie co pozostawił po sobie w ram).
Schemat zamieszczam ze względów formalnych, ponieważ wszystkie peryferia są podłączone pod standardowe magistrale. TWI nie wymaga dodatkowych rezystorów (aktywne pullupy), wyprowadzenie CS SPI podłączone jest do portu B.0. Układ testowo pracował z prędkością 12.8MHz z wbudowanego generatora RC.
Cool? Ranking DIY
