Ponieważ to forum zrzesza sporo osób zajmujących się projektowaniem różnych konstrukcji oraz realizacją ciekawych i przydatnych urządzeń elektronicznych zawierających procesory chciałbym podzielić się rozwiązaniem problemu zawieszania się procesora rodziny ARM z rdzeniem Cortex M3 na który natrafiliśmy podczas prac przy module CSDU.
Jak wiecie z wcześniejszych moich opisów nasz moduł chodzi pod kontrolą systemu czasu rzeczywistego opartego o dystrybucję FreeRTOS. Głównym projektantem jądra systemu oraz jego adaptacją do naszych potrzeb jest Marcin Smoczyński. Po tym jak Marcin zwany w naszym zespole Smoqiem zakończył pracę zajęli się nim Przemek Szulim i Marcin Kłos. Po dadaniu kolejnej funkcjonalności, czyli transmisji danych - system zaczął się wieszać przy zbyt dużych porcjach danych wysyłanych z aplikacji do modułu CSDU - był to główny powód opóźnienia w zakończeniu naszego projektu.
Po trzech tygodniach od rozpoczęcia pracy nad rozwiązaniem tego problemu Marcin Smoczyński znalazł rozwiązanie, które chciałem podać, ponieważ nie jest oczywiste i rozwiązuje również problem błędu w bibliotece dostarczanej przez ST. Tym którzy wejdą w Cortexa i system operacyjny FreeRTOS pozwoli to zaoszczędzić sporo czasu
. Myślę, że za czas jakiś większość projektów będzie realizowana na ARMach, bo ich poznanie pozwala na rozwinięcie skrzydeł...
Przyczyną wysypywania się systemu były nieprawidłowe priorytety przerwań portu szeregowego. Wyższy priorytet powodował wchodzenie w paradę schedulerowi FreeRTOS gdy ten był w sekcji krytycznej. Wywołanie wtedy funkcji API FreeRTOSa (w tym wypadku xQueueSendFromISR) powodowało pośrednio zawieszenie jądra systemu (poprzez nadpisanie stosu), czasem w losowej sytuacji HardFault.
Dlaczego problem się teraz ujawnił z taką intensywnością a nie wcześniej. Powodów jest kilka:
- problem nie występował kiedy działał jedynie jeden wątek a reszta była uśpiona
- prawdopodobieństwo wystąpienia wzrastało wraz z obciążeniem jądra (m.in. ze wzrostem częstotliwości regulacji) oraz z wielkością strumienia danych przesyłanych przez port szeregowy (częstotliwość przerwania)
- inne przerwania, które również miały teoretycznie zły priorytet (m.in. timery i ADC) nie wywoływały żadnych systemowych API, dzięki czemu nie wysypywały systemu. Ten pukt jest ważny i nie jest taki teoretyczny, gdyż dopóki ISR nie wywołuje funkcji API FreeRTOSa może on hulać z dowolnym priorytetem. Dołożenie jakiegokolwiek API (np. kolejki czy mutexa) spowodowałoby to samo co w przypadku portu szeregowego, czyli niechybny wysyp
- w bibliotece ST FWlib jest bug, który powoduje błędne ustawienie priorytetów przerwań w przypadku wykorzystania domyślnego grupowania priorytetów 7.1
Aby to naprawić trzeba ustawić priorytet przerwania portu szeregowego niższy od configMAX_SYSCALL_INTERRUPT_PRIORITY (priorytet przerwań FreeRTOSa), czyli musi mieć wartość C0, D0, E0 lub F0 (trzeba pamiętać o odwrotnej notacji).
// grupowanie priorytetów 4.0 (16 poziomów preemption, 0 poziomów subpriority)
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);
NVIC_InitStructure.NVIC_IRQChannel = USART3_IRQChannel;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 15;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
To zapewni priorytet przerwania portu szeregowego o wartości 0xF0.
Pozostałe przerwania mogą mieć priorytet dowolny, dopóki nie wykorzystują API FreeRTOSa.
Działanie NVIC jest bardzo mocno powiązane z działaniem całego rdzenia CortexM3, stąd w nocie katalogowej STM32 można zamiast jego opisu znaleźć odesłanie do noty całego rdzenia:
http://infocenter.arm.com/help/topic/co ... p1_trm.pdf
W CM3 dostępne jest max. 256 priorytetów przerwań (8bit). Specyfikacja jednak dopuszcza obcięcie tej wartości do minimalnie 3bit. STM32 zapewnia 4bit, czyli 16 poziomów. Pozostałe 4 bity sa zaniedbywane. Bity znaczące są liczone zawsze od MSB, ponieważ ucięcie LSB wprowadza mniej problemów podczas przenoszenie programu pomiędzy procesorami z rdzeniem CM3. Dlatego też mamy poziomy 00, 10, ..., F0. Poziomy te następnie są grupowane pomiędzy preemption priority (lewe) i subpriority (prawe) przy pomocy wartości PRIGROUP rejestru SCB->AIRCR. Domyślny podział to 7:1 (PRIGROUP=0). Na STM32 oznacza to 16 poziomów preemption i 0 subpriority (4:0). Później to można zmienić na 3:1, 2:2, 1:3 lub 0:4 (odpowiednio PRIGROUP=3,4,5,6 lub 7; ustawienie 0, 1 lub nie zmienia niczego).
Problem pojawia się w momencie kiedy chcemy ustawić priorytet przerwania przy pomocy funkcji STLib, NVIC_Init:
/* Compute the Corresponding IRQ Priority --------------------------------*/
tmppriority = (0x700 - (SCB->AIRCR & (u32)0x700))>> 0x08;
tmppre = (0x4 - tmppriority);
tmpsub = tmpsub >> tmppriority;
Druga linijka jest krytyczna. Jeżeli nie ustawiliśmy podziału priorytetów funkcją NVIC_PriorityGroupConfig i wykorzystujemy domyślną wartość PRIGROUP=0 (jak najbardziej prawidłową z punktu widzenia rdzenia!), to tmppre będzie miał wartość -3 (0xFFFFFFFD) i spowoduje to nieprawidłowe ustawienie priorytetu przerwania. Jest to ewidentny bug typu integer overflow. Aby się przed nim zabezpieczyć wystarczy wywołać przed ustawieniem jakiegokolwiek priorytetu, funkcję:
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);
która spowoduje zapisanie wartości PRIGROUP=3 a co za tym idzie podziału 4:0. Wtedy NVIC_Init wywoła się prawidłowo. Naturalnie w razie potrzeby można wykorzystać PriorityGroup innej wartości.
