Bootloader dla zestawu FREEboard – wprowadzenie

W artykule przedstawiamy szczegółowy opis konfiguracji bibliotek tworzących opisany w artykule bootloader dla płytki FREEboard. Konfiguracja umożliwia zoptymalizowanie cech i parametrów bootloadera do wymogów aplikacji. Osoby zainteresowane korzystaniem z podstawowej możliwości bootloadera – programowania pamięci Flash mikrokontrolera – nie muszą poznawać tajników jego konfiguracji i kompilacji programu wynikowego, zachęcamy ich przeczytania artykułu poświęconego korzystaniu z bootloadera KBOOT dla zestawu FREEboard.

KINETIS Bootloader jest narzędziem programowym, przechowywanym w pamięci Flash mikrokontrolera z rodziny KINETIS firmy Freescale, wykorzystywanym do aktualizacji oprogramowania aplikacji, znajdującego się zazwyczaj w tej samej pamięci, przy pomocy jednego z dostępnych połączeń szeregowych (UART, I2C, SPI, USB…). Narzędzie umożliwia szybkie i łatwe programowanie układu w trakcie pełnego cyklu życiowego urządzenia, poczynając od fazy projektowej, poprzez fazę produkcji i kończąc na etapie pracy urządzenia w środowisku docelowym.

Z oficjalnej strony internetowej producenta Freescale można pobrać pakiet zawierający kody źródłowe omawianego bootloadera, który jest w wysokim stopniu konfigurowalny za sprawą przemyślanej struktury projektu – rysunek 1. Dodatkowo oprócz dokumentacji są tam również zawarte aplikacje dla systemów komputerowych, ułatwiające pracę z bootloaderem (narzędzia wiersza poleceń oraz aplikacje graficzne).

 

Rys. 1. Struktura bootloadera dla mikrokontrolerów KINETIS, udostępnionego przez firmę Freescale

 

Co aktualnie oferuje Freescale?

W chwili przygotowania artykułu (grudzień 2014) KINETIS Bootloader w wersji 1.1.0 obsługuje mikrokontrolery z serii K22F, K64F oraz KL25Z (przy odrobinie pracy można samemu przygotować obsługę innego mikrokontrolera rodziny KINETIS). Z zadeklarowanych przez producenta charakterystyk bootloadera warto wymienić najważniejsze:

  • łatwa implementacja w dowolnym mikrokontrolerze z rodziny KINETIS,
  • możliwość komunikacji z hostem poprzez magistrale UART, USB HID, I2C oraz SPI, a także potencjalnie realizowalna komunikacja z wykorzystaniem magistrali CAN,
  • uniwersalny protokół bootloadera, niezależny od aktualnie wykorzystywanej magistrali,
  • opcje zabezpieczenia pamięci Flash,
  • detekcja aktywnej magistrali (aktywnego peryferium),
  • narzędzia ułatwiające pracę hosta z bootloaderem,
  • kody źródłowe udostępniane zgodnie z licencją BSD Open Source.

 

Organizacja przestrzeni w pamięci i działanie bootloadera

W pamięci Flash mikrokontrolera z zaimplementowanym narzędziem KINETIS Bootloader można wyróżnić dwa główne obszary (rysunek 1):

  • obszar bootloadera – znajduje się pod adresem 0x0 i zawiera tablicę wektorów bootloadera wraz z jego kodem. Domyślnie dla układów serii KL25Z pod obszar bootloadera zarezerwowanych jest 32 kB pamięci Flash (można to zmienić w projekcie bootloadera).  
  • obszar aplikacji użytkownika – rozpoczyna się od adresu zdefiniowanego w stałej BL_APP_VECTOR_TABLE_ADDRESS (domyślnie dla układów KL25Z jest to adres 0x8000). Oprócz tablicy wektorów aplikacji użytkownika oraz właściwego oprogramowania w obszarze tym występuje jeszcze sekcja konfiguracji bootloadera (Bootloader Configuration Area, BCA) przesunięta o adres 0x3C0 względem początku danego obszaru (rysunek 2).

 

Rys. 2. Organizacja przestrzeni w pamięci Flash mikrokontrolera z funkcją KINETIS Bootloader [1]

 

Podczas inicjalizacji bootloadera czytane jest pierwsze 4-bajtowe pole sekcji BCA i w sytuacji, gdy jest w nim zawarty ciąg ‚kcfg’ to automatycznie odczytywane są pozostałe pola tej sekcji. Po zebraniu wszystkich danych z sekcji BCA bootloader skonfiguruje sygnały zegarowe oraz wszystkie peryferia, które mają być aktywnie wykorzystywane w czasie jego działania. Natomiast w trakcie pracy bootloadera sprawdzana jest zawartość dwóch 32-bitowych pól: stackPointer (pod adresem BL_APP_VECTOR_TABLE_ADDRESS) przechowujące wskaźnik na stos aplikacji oraz entryPoint (pod adresem BL_APP_VECTOR_TABLE_ADDRESS+4) przechowujące adres startu aplikacji. Jeżeli w tych polach jest zapisana wartość 0xFF to bootloader kontynuuje swoje działanie w trybie poleceń. W pozostałych przypadkach zakończy on swoją pracę po czasie określonym w [ms] w 16-bitowym polu peripheralDetectionTimeoutMs sekcji BCA i kontrolę nad układem przejmie aplikacja użytkownika. Takie rozwiązanie pozwala na skomunikowanie się z bootloaderem w czasie od podania zasilania dla układu do uruchomienia docelowej aplikacji.

 

Rys. 3. Tablica wektorów w obszarze aplikacji użytkownika wraz z sekcją BCA [1]

 

Konfiguracja bootloadera

Pakiet Freescale KINETIS Bootloader Package dostępny na stronie [2] zawiera przykładowy projekt, przygotowany w środowisku IAR Embedded Workbench, w którym występują pliki konfiguracyjne dotyczące zarówno pracy i funkcjonalności bootloadera jak również wykorzystywanych przez niego zasobów sprzętowych dostępnych w konkretnym układzie (pliki te są umieszczone w podkatalogu targets/<seria_mikrokontrolera>/src):

  • bootloader_config.h – makra konfiguracyjne wykorzystywane przy kompilacji projektu,
  • clock_config_x.c – funkcje konfigurujące sygnały zegarowe,
  • hardware_init_x.c – funkcje konfigurujące wyprowadzenia i najważniejsze elementy systemu, operujące bezpośrednio na rejestrach mikrokontrolera,
  • memory_map_x.c – mapa pamięci mikrokontrolera, czyli sposób przydziału przestrzeni adresowej poszczególnym składowym mikrokontrolera (pamięć Flash, pamięć SRAM, itd.),
  • peripherals_x.c – tablica deskryptorów układów peryferyjnych.

Makra konfiguracyjne umożliwiają w prosty sposób dostrojenie funkcjonalności bootloadera:

  • BL_DEFAULT_PERIPHERAL_DETECT_TIMEOUT określa maksymalny domyślny czas w [ms] detekcji aktywnego układu peryferyjnego (czyli wymieniającego dane z otoczeniem),
  • BL_ENABLE_CRC_CHECK włącza (1) sprawdzanie sumy kontrolnej (aktualnie nie jest używane z powodu braku zaimplementowanej funkcji sprawdzającej),
  • BL_FEATURE_READ_MEMORY aktywuje (1) obsługę komend odczytu pamięci Flash układu,
  • BL_FLASH_VERIFY_DISABLE wyłącza (1) weryfikację operacji kasowania i zapisu pamięci Flash układu,
  • BL_HAS_MASS_ERASE powinno być ustawione na wartość (1) w sytuacji, gdy polecenie ERSALLU jest obsługiwane przez wewnętrzny kontroler pamięci Flash (tylko w niektórych nowych układach),
  • BL_MIN_PROFILE wybiera maksymalną (0) lub minimalną (1) konfigurację bootloadera, przy czym w tym drugim przypadku obsługiwana jest tylko część pełnego zbioru komend,
  • BL_UART_AUTOBAUD_IRQ wymusza (1) wykorzystanie przerwań od zmiany stanu linii do celów autodetekcji prędkości transmisji na magistrali UART zamiast mechanizmu odpytywania (0).

O autorze