Sygnały zegarowe i procedura startowa STM32

[Elvis]

Niestety nie byliśmy w stanie opisać wszystkie możliwości jakie daje stm32f103 - kurs to jedynie wprowadzenie, a opisanie nawet tak prostego mikrokontrolera to temat na książkę, może nawet kilka. Konieczne więc było wybranie co opiszemy, a co zostanie pominięte. Priorytety przerwań pozostawiliśmy domyślne - ale jeśli ktoś potrzebuje je zmodyfikować, to żaden problem.

Teraz na spokojnie można wrócić do pierwotnego pytania w tym wątku - czyli procedury uruchamiania mikrokontrolera stm32f103rb.

Po załączeniu zasilania generowany jest sygnał reset. Następnie sprawdzane są stany dwóch pinów, nazywanych BOOT0 i BOOT1. Od nich zależy procedura startowa układu:

W typowej konfiguracji BOOT0 jest połączony z masą układu, wówczas wykonywany jest program użytkownika z pamięci Flash. Inne możliwości to uruchomienie tzw. bootloadera, czyli programu ładującego, który znajduje się w wydzielonym fragmencie pamięci flash (System memory). Został on zaprogramowany przez firmę ST podczas produkcji i nie może być zmieniany przez użytkownika. Ostatnia opcja to start programu z pamięci RAM - opcja wydaje się przydatna podczas testowania programu, chociaż przyznam że z niej nigdy nie korzystałem.

Najczęściej będziemy chcieli uruchomić nasz program, więc zakładam że BOOT0 = 0 i to właśnie nasz kod z pamięci Flash jest wykonywany.

Procedura startowa polega na odczytaniu przez procesor pierwszych dwóch 32-bitowych słów. Pierwsze, czyli znajdujące się pod adresem 0x00000000 to wartość wskaźnika stosu. Najczęściej stos umieszcza się w górnej części pamięci RAM. Kolejne słowo, czyli wartość pod adresem 0x00000004 zawiera punkt startowy programu.

Procesor wczytuje więc spod adresu 0 wskaźnik stosu, umieszcza go w rejestrze R13 (SP), a następnie wczytuje wartość spod adresu 4 do rejestru R15 (PC) i w tym momencie zaczyna być wykonywany nasz program.

Oczywiście wspomniane wartości trzeba jakoś do pamięci Flash wprowadzić. Znajdziemy je w pliku startup/startup_stm32f103xb.s:

W tym pliku tworzona jest specjalna sekcja o nazwie .isr_vector. Linker umieści ją później na samym początku pliku binarnego, który wgramy do pamięci Flash. Dzięki temu jej zawartość pojawi się pod wspomnianymi adresami.

Widoczna tablica g_pfnVectors jest często nazywana wektorem przerwań. Jej pierwsze dwie pozycje już omówiliśmy - wartość _estack to wskaźnika na stos, a Reset_Handler to miejsce gdzie faktycznie zaczyna się program.

Kolejne pozycje to nazwy procedur obsługi przerwań - znajdziemy tam np. dobrze znane SysTick_Handler, czy EXTI0_IRQHandler. Co ciekawe te nazwy są umowne, ale możemy je zmienić, więc jeśli lubimy tworzyć własne standardy możemy pozbyć się tego koszmarnego sposobu nazywania i wymyślić inny, lepszy

Wspomniałem już o identyfikatorze Reset_Handler - to miejsce gdzie faktycznie zaczyna się wykonywanie programu, czyli powiedzmy procedura startowa.

CDN.

 

Identyfikator Reset_Handler znajdziemy w tym samym pliku co wektor przerwań, czyli startup_stm32f103xb.s. Kod jest krótki, ale ciekawy więc pozwolę sobie go omówić.

Jak widać jest to funkcja, którą możemy przedefiniować w kodzie (weak). Mało osób pewnie to robi, ale warto wiedzieć że można.

/* Copy the data segment initializers from flash to SRAM */
  movs r1, #0
  b LoopCopyDataInit

CopyDataInit:
  ldr r3, =_sidata
  ldr r3, [r3, r1]
  str r3, [r0, r1]
  adds r1, r1, #4

LoopCopyDataInit:
  ldr r0, =_sdata
  ldr r3, =_edata
  adds r2, r0, r1
  cmp r2, r3
  bcc CopyDataInit

Ten kod w języku C odpowiadałby wywołaniu memcpy(), czyli przekopiowaniu bloku pamięci. Docelowy obszar jest położony pomiędzy adresami _sdata, a _edata, natomiast źródło zaczyna się od adresu _sidata i ma ten sam rozmiar oczywiście. Same adresy ustala linker, ale ciekawe jest ich znaczenie. _sidata wskazuje na adres w pamięci Flash, podczas gdy _sdata w pamięci RAM.

Załóżmy że pisząc program zadeklarujemy globalną zmienną z wartością początkową, np.

int costam = 5;

Taka zmienna jest tworzona w pamięci RAM - inaczej nie byłaby zmienną, bo nie moglibyśmy jej zmieniać. Pojawia się jednak problem z jej początkową wartością - zawartość pamięci RAM jest przypadkowa, więc skąd procesor ma wiedzieć, że chcieliśmy mieć tam akurat 5?

Początkowe wartości zmiennych są więc zapisywane w pamięci Flash, ich adresy to właśnie blok _sidata. Natomiast same zmienne są w pamięci RAM, czyli bloku _sdata - edata. Kod który omawiamy przepisuje początkowe wartości z pamięci Flash do zmiennych w pamięci RAM. Taka magia.

 

Następny fragment kodu wygląda dość podobnie:

  ldr r2, =_sbss
  b LoopFillZerobss
/* Zero fill the bss segment. */
FillZerobss:
  movs r3, #0
  str r3, [r2], #4

LoopFillZerobss:
  ldr r3, = _ebss
  cmp r2, r3
  bcc FillZerobss

Tutaj jednak nie kopiujemy danych, a jedynie wypełniamy blok od adresu _sbss do _ebss zerami.

Okazuje się, że najczęściej używaną wartością początkową zmiennej jest właśnie zero. Wobec tego wszystkie zmienne globalne, które są inicjowane zerem, zbierane są w bloku między adresami _sbss i _ebss, a omawiany kod je zeruje.

Jeśli więc napiszemy w programie:

int zmienna = 0;
int inna_zmienna;

To obie zmienne trafią do segmentu bss i zostaną im przypisane wartości zero w tym fragmencie kodu.

 

Teraz już prawie jesteśmy w świecie języka C. Ostatnie fragmenty kodu to:

/* Call the clock system intitialization function.*/
    bl  SystemInit
/* Call static constructors */
    bl __libc_init_array
/* Call the application's entry point.*/
  bl main
  bx lr

Są to wywołania trzech funkcji napisanych w C. Pierwsza, czyli SystemInit jak czytamy w opisie ma zainicjalizować taktowanie systemu. Jest to funkcja jak każda inna, ale tak sobie ktoś wymyślił, że ją wywoła przed main.

Kolejna to wewnętrzna inicjalizacja biblioteki standardowej języka C. Co dokładnie robi __libc_init_array nie jestem pewien. Jej kod źródłowy znajdziemy np. tutaj: https://github.com/eblot/newlib/blob/master/newlib/libc/misc/init.c

Jak widać wywołuje ona inne funkcje, mam niejasne wrażenie że jest bardziej związana z C++ niż samym C. W każdym razie jeśli ktoś ma jakieś informacje o tej funkcji, prośba o udostępnienie, to kolejna ciekawa rzecz w procedurze uruchamiania.

Na koniec widzimy skok do funkcji main oraz błąd

Wywołanie funkcji main to moment, który większość osób uważa za początek programu. W urządzeniach wbudowanych funkcja main nie powinna się nigdy kończyć, jednak gdyby tak się stało, zostanie wywołana instrukcja bx lr. Prawdopodobnie miała to być nieskończona pętla, ale trochę nie wyszła... Co ciekawe komercyjne (czyli drogie) kompilatory, jak Keil i IAR mają ten fragment napisany poprawnie. Niestety w gcc jest błąd i zamiast zapętlić pustą instrukcję, zapętlona jest ostatnia używana procedura.

Inna sprawa, że samo wyjście z main() jest błędem, więc to tylko błąd na błędzie...

 

Na zakończenie jeszcze kilka słów o funkcji SystemInit. Jej kod znajdziemy w pliku system_stm32f1xx.c.

Ta funkcja, jeśli wierzyć fragmentowi copyright oraz paskudnie zaśmieconemu kodowi została napisana w firmie ST.

Jest idealnym przykładem na wady używania Doxygen-a. Kod jest nieczytelny, a opis funkcji to:

  *         Initialize the Embedded Flash Interface, the PLL and update the
  *         SystemCoreClock variable.

Oczywiście ta funkcja nie dotyka pamięci Flash, ani zmiennej SystemCoreClock, natomiast jedyne co robi to przypisuje domyślne ustawienia do rejestrów, które i tak mają domyślne wartości. Prawdopodobnie ma to związek z niedoskonałościami debuggera, ale jak widać opisem funkcji nie należy się sugerować.

Po jej wywołaniu taktowanie systemu będzie bazowało na wbudowanym generatorze 8 MHz, a pętla PLL będzie wyłączona.

Natomiast wspomniana zmienna SystemCoreClock zostanie ze swoją początkową wartością, czyli:

  uint32_t SystemCoreClock         = 72000000;        /*!< System Clock Frequency (Core Clock) */

Mamy więc kolejny błąd - zmienna nie odpowiada aktualnej konfiguracji systemu. Stąd w kursie stosowanie sztuczki z przypisaniem 8000000 do SystemCoreClock. Nie zmienia to taktowania, ale chociaż naprawia działanie biblioteki HAL.

Oczywiście funkcję SystemInit można zmienić. Można w niej zmienić konfigurację zegarów, używać 72MHz, 64MHz, albo jakiejkolwiek innej częstotliwości. Ważne jest tylko, żeby wartość SystemCoreClock odpowiadała rzeczywistości - z niej korzysta wiele modułów HAL.

 

Edytowano Październik 28, 2018 przez Elvis

[Mellon]

Brawo 

[Mellon]

Co prawda podczas debugowania po wywołaniu HAL_Init zmienna SystemCoreClock miała wartość 8MHz, pomimo że nie ustawiłem jej na prawidłową wartość. Ustawia ją SystemCoreClockUpdate(). Lecz nie wiem w którym momencie jest wywoływana tj. czy przed pierwszym użyciem tej zmiennej.

[Elvis]

Problem polega na tym, że domyślna implementacja SystemInit nie wywołuje SystemCoreClockUpdate. Inna sprawa, że skoro znamy częstotliwość zegara, to po co marnować czas na jej obliczanie? Moim zdaniem poprawne rozwiązanie to zmiana pliku system_stm32f1xx.c i przypisanie domyślnie do zmiennej SystemCoreClock wartości 8000000. Jeśli później ktoś zmieni taktowanie, to niech się sam martwi i odpowiednio dba o wartość zmiennej.

W nowszych modelach stm32 ten błąd został już poprawiony. Przykładowo we wspomnianym stm32f030 w pliku system_stm32f0xx.c domyślnie przypisywana jest poprawna wartość, czyli 8000000.

Domyślam się, że kod dla F1 nie został poprawiony, bo teraz są nowsze modele i nikt nie miał czasu... A testy były robione na 72MHz i "u mnie działało"

Pisząc kurs nie zdecydowałem się na modygikacje w system_stm32f1xx.c, bo tworząc każdy projekt trzeba byłoby o tym pamiętać. Po prostu łatwiej było umieścić zmiany w pliku źródłowym przykładów. Inna sprawa, że trochę naiwnie liczyłem że ST poprawi bibliotekę HAL i kłopot sam zniknie.

[Mellon]

Wtedy prościej utworzyć bibliotekę statyczną z poprawioną wartością tej zmiennej, ustawieniami zegarów (HSE), itp. i wydzielić do katalogu z którego wszystkie projekty dot. tej rodziny STM32 będą korzystać.

Dnia 26.10.2018 o 14:22, Elvis napisał:

W tym kursie podjęliśmy decyzję zostania tylko przy wbudowanym generatorze RC, więc jeśli już to i tak ten brakujący odcinek byłby o uzyskaniu 64MHz za pomocą PLL.

Wbudowany generator RC w pełnym zakresie temperatur ma wahania częstotliwości rzędu kilku procent. Natomiast rezonatory kwarcowe/ceramiczne mają wahania częstotliwości rzędu 15-30 ppm ((parts per million). Koszt takiego to ok 2 zł. A taki rezonator mamy w Nucleo jeśli nie odłamiemy programatora.

W przypadku wykorzystania do komunikacji, synchronizacji z innymi urządzeniami wymagany jest stabilny sygnał zegarowy. Dlaczego by nie skorzystać z niego.