PODZESPOA
Y
Mikrokontrolery STM32
Bezpieczeństwo i stabilność
Dodatkowe
materiały na CD
aplikacji
Architektura rdzenia Cortex M3 oferuje wiele udogodnień istotnych operacyjnego (OS  Operating system). System
operacyjny pracuje w trybie uprzywilejowanym,
przy tworzeniu wbudowanych systemów operacyjnych. Dzięki
natomiast program użytkownika uruchamiany
przedstawionym w niniejszym artykule mechanizmom implementacja
jest przez OS i wykonywany w trybie o ograni-
RTOS jest znacznie uproszczona w stosunku do mikrokontrolerów
czonych możliwościach.
wyposażonych w inne rdzenie. Dodatkowym atutem rdzenia Cortex
Mikrokontroler obsługując przerwanie za-
M3 jest to, że aktualnie już kilku wiodących producentów ma
wsze pracuje w trybie uprzywilejowanym (PL)
w swojej ofercie mikrokontrolery z tym rdzeniem, co znakomicie
nawet, jeśli w trakcie normalnego wykonywa-
poprawia przenośność aplikacji. Podane w artykule informacje nia programu ustawiony jest tryb użytkownika
(UL). Te relacje przedstawiono na rys. 2, nato-
dotyczą mikrokontrolerów STM32.
miast rys. 3 przedstawia pracę mikrokontrolera
z włączonym trybem użytkownika. Z ostatniego
Aplikacje pisane z myślą o wykorzystaniu rysunku jasno wynika, że rdzeń Cortex pracując
w systemie operacyjnym działającym na mikro- w trybie UL, w czasie wchodzenia od obsługi
kontrolerze określonego producenta z rdzeniem przerwania, przełącza się w tryb PL, natomiast
Cortex M3, mogą być uruchomione na dowol- kończąc obsługę przerwania wraca do poprzed-
nym innym mikrokontrolerze z tym rdzeniem. niego trybu nieuprzywilejowanego (użytkowni-
Aplikacja korzysta z API, którego zadaniem jest ka).
należyta komunikacja ze sprzętem, stąd tak Przedstawiony mechanizm znacznie zwięk-
duża przenośność w obrębie mikrokontrolerów sza stabilność systemu mikroprocesorowego,
z rdzeniem Cortex. Jest to poważny argument ponieważ aplikacja użytkownika, która ze swej
przemawiający za stosowaniem we własnych natury posiada większe prawdopodobieństwo
rozwiązaniach układów z tym rdzeniem. wygenerowania błędnych zachowań, ma ogra-
niczony dostęp do kluczowych zasobów (np.
Tryby pracy rdzenia Cortex Rys. 2. NVIC i SysTick), a co za tym idzie, nie może
Z punktu widzenia wykonywanego kodu, bezpośrednio zachwiać stabilności pracy całego
mikrokontroler może pracować wykonując Dodatkowo rozróżnia się dwa poziomy układu.
program normalnie (Thread mode  TM), albo o różnych prawach dostępu do kluczowych ob- Po uruchomieniu mikrokontroler zawsze
może obsługiwać przerwanie (Handler mode szarów w przestrzeni adresowej: rozpoczyna pracę w trybie uprzywilejowa-
 HM). Obie sytuacje przedstawiono na rys. 1.  tryb uprzywilejowany (Privileged level  PL), nym, a zatem do zadań systemu operacyjnego
Takie rozróżnienie ma kluczowe znaczenie dla  tryb użytkownika (Unprivileged/User level w pierwszej kolejności należy, jeszcze przed uru-
aplikacji opartych o systemy operacyjne, spra-  UL). chomieniem aplikacji użytkownika, włączenie
wa ta poruszona jest w dalszej części tego ar- Powyższy podział ma uzasadnienie w apli- trybu nieuprzywilejowanego  UL.
tykułu. kacjach pracujących pod kontrolą systemu Przejście z trybu użytkownika do trybu
uprzywilejowanego nie jest możliwe bezpo-
średnio. Aplikacja uruchomiona w systemie
operacyjnym nie ma możliwości wyłączenia
trybu użytkownika, ponieważ nie ma dostępu
do specjalnego rejestru kontrolnego CONTROL.
Zapis do niego z poziomu aplikacji jest ignoro-
wany. Zmiany można dokonać tylko podczas
obsługi przerwania, która jest przeprowadzana
w trybie pełnych uprawnień  PL. Wygląd całego
rejestru CONTROL (z wartościami domyślnymi),
wraz z opisem ważnych bitów, przedstawiono
na rys. 4.
System operacyjny, który zajmuje się przełą-
czaniem kontekstów zadań i nadzorem nad po-
prawnością pracy całego układu, może zmienić
(pracując w przerwaniach) status uprawnień.
Innymi słowy, aby przejść do trybu uprzywile-
Rys. 1. jowanego (PL) wykonywania programu należy
114 ELEKTRONIKA PRAKTYCZNA 4/2009
Bezpieczeństwo i stabilność aplikacji
Rys. 6.
Rys. 3.
również wskaz
nik stosu R13 wskazuje na stos
systemowy MSP tuż po uruchomieniu się mikro-
kontrolera.
Wykorzystanie dwóch stosów dodatkowo
zwiększa odporność całego systemu na błędy,
ponieważ jeśli aplikacja użytkownika zacznie
wykonywać na stosie nieprawidłowe operacje,
to nie wpłynie to negatywnie na stabilność dzia-
łania układu. System operacyjny (jeżeli pracuje
wykorzystując przerwania) ma swój, oddzielny
stos MSP.
Mikrokontroler rozpoczynając obsługę prze-
rwania umieszcza zawartość kluczowych reje-
strów systemowych na stosie, natomiast powra-
cając z obsługi przerwania zdejmuje te wartości,
Rys. 4. na powrót zapisując je do rejestrów. Dzięki temu
przerwany proces nie traci informacji i może być
dalej wykonywany bez przeszkód.
Jeśli wykorzystywany jest tylko stos MSP,
to sprawa jest oczywista i mikrokontroler za-
chowuje się tak, jak to opisano powyżej. Wąt-
pliwości rodzą się dopiero w przypadku, gdy
wykorzystywane są oba stosy. W takiej sytuacji,
do przechowywania informacji o przerywanym
procesie wykorzystywany jest stos użytkownika
PSP, natomiast MSP wykorzystywany jest tylko
wewnątrz obsługi przerwania. Zachowanie takie
przedstawiono na rys. 7.
Rys. 5. Gdy mikrokontroler pracuje w trybie uprzy-
wilejowanym, to dostęp (lub zapis) do obydwu
zmienić w funkcji obsługi przerwania ustawie- tację rejestru wskaz
nika stosu. Mikrokontrolery stosów jest możliwy bezpośrednio, za pomocą
nia specjalnego rejestru kontrolnego CONTROL, STM32 są 32 bitowe, a więc stos jest inkremen- instrukcji odczytu (MRS) lub zapisu (MSR) reje-
czyli wyzerować najmłodszy bit. towany (lub dekrementowany) zawsze o 4. stru specjalnego. Odczyt i zapis stosu MSP i PSP
w asemblerze może wyglądać następująco:
Stos Dwa stosy, MSP i PSP MRS r0, PSP ; Odczyt PSP do R0
Stos jest elementem systemu mikroproceso- Rejestr R13 jest wskaz
nikiem stosu  ściślej MSR PSP, r0 ; Zapis R0 do PSP
rowego, który pozwala przechowywać kluczowe są to dwa bankowane wskaz
niki stosu. W zależ- MRS r0, MSP ; Odczyt MSP do R0
informacje. Fizycznie jest to obszar w pamięci, ności od ustawienia drugiego bitu w specjalnym MSR MSP, r0 ; Zapis R0 do MSP
który współpracuje ze specjalnym rejestrem rejestrze kontrolnym CONTROL (rys. 4), może on Powyższe instrukcje można, rzecz jasna,
wskaz
nikowym. Na stosie informacje wpisywane wskazywać na stos systemowy MSP (Main Stack zapisać przy użyciu zdefiniowanych przez fir-
są w sposób liniowy, co oznacza, że aby odczy- Pointer) lub na stos użytkownika PSP (Process mę ST funkcji, które zadeklarowano jako makra
tać zagrzebane dane, należy najpierw ściągnąć Stack Pointer). Skoro wskaz
nik stosu jest banko- asemblerowe. W takiej sytuacji, odczyt stosu
ze stosu dane nowsze (rys. 5). wany, to w danej chwili R13 może wskazywać użytkownika realizowany jest za pomocą nastę-
Z perspektywy programisty, dostęp do stosu tylko jeden stos (MSP lub PSP). Przedstawiono pującego fragmentu kodu:
realizowany jest przez użycie polecenia zdejmo- to na rys. 6. Ponadto, obsługując przerwanie Wartość_PSP = __MRS_PSP();
wania (POP) i wkładania (PUSH) na stos. Po każ- mikrokontroler zawsze korzysta ze stosu MSP. Procedura zapisu na stos PSP natomiast po-
dej operacji PUSH rejestr wskaz
nikowy (w przy- Przy okazji opisu trybów pracy mikrokontro- lega na wywołaniu odpowiedniego fragmentu
padku rdzenia Cortex jest to rejestr R13) jest lerów STM32 pojawiła się wzmianka o tym, że kodu asemblera:
dekrementowany, czyli wskazuje młodszy adres. po uruchomieniu układ zawsze pracuje w trybie __MSR_PSP( (u32)NOWA_WARTOSC );
Analogicznie operacja POP powoduje inkremen- uprzywilejowanym. Konsekwencją tego jest, że Analogicznie zapis i odczyt stosu MSP:
ELEKTRONIKA PRAKTYCZNA 4/2009 115
PODZESPOA
Y
Wartość_MSP = __MRS_MSP();
__MSR_MSP( (u32)NOWA_WARTOSC );
Zastosowanie powyższych instrukcji umoż-
liwia systemowi operacyjnemu dostęp do stosu
aplikacji (PSP), a więc pełną kontrolę nad pro-
gramem użytkownika.
Tryb użytkownika i PSP
Oddzielne wykorzystanie mechanizmu
poziomów uprzywilejowania i modelu dwóch
stosów jest oczywiście użyteczne, ale znacz-
ne zwiększenie możliwości uzyskuje się przez
połączenie obydwu. Na list. 1 przedstawiono
fragment programu, który jest odpowiedzialny
za włączenie trybu użytkownika i obsługi sto-
su PSP. Gdy te operacje zostaną zrealizowane,
to następuje wywołanie przerwania od wyjątku
systemowego SVC (omówiony w dalszej części Rys. 7.
artykułu). Funkcja obsługi przerwania SVC wy-
łącza tryb użytkownika. Wywołanie przerwania
List. 1.
jest zabiegiem koniecznym do zmiany poziomu // Inicjalizacja PSP
for(Index = 0; Index < 0x200; Index++)
uprzywilejowania. Jak było to już napisane, jego
PSPMem[Index] = 0x00;
zmiana z trybu użytkownika do trybu uprzywile-
__MSR_PSP((u32)PSPMem + 0x200);
jowanego jest możliwa tylko w funkcji obsługi
// Wybor PSP i trybu uzytkownika
przerwania. Ilustruje to przykład funkcji obsługi
__MSR_CONTROL(0x03);
przerwania SVC umieszczony poniżej:
// Wygenerowanie SVC, powrot to trybu uprzywilejowanego
void SVCHandler(void)
__SVC();
{
__MSR_CONTROL(0);
} poprawności przenoszenia aplikacji pomiędzy systemu operacyjnego. Takie ograniczenia
Instrukcja wewnątrz ciała funkcji ma za za- rdzeniami ARM7 i Cortex M3. w stosunku do aplikacji uruchamianych w sys-
danie wpisać do specjalnego rejestru kontrolne- Wyjątek SVC (System service call) temie operacyjnym mają bardzo istotne zna-
go wartość 0, co odpowiada wyzerowaniu bitów W dobrze zaprojektowanym systemie ope- czenie ze względu na ograniczone zaufanie dla
CONTROL[0] i CONTROL[1], które odpowiedzial- racyjnym, uruchomiona w nim aplikacja nie programów użytkownika. W związku z powyż-
ne są za aktualny poziom uprzywilejowania oraz może bezpośrednio odwołać się do sprzętu. szym musi istnieć mechanizm pozwalający na
wykorzystywany stos. Odnosząc to zdanie do konkretnego przypad- bezpieczne korzystanie ze sprzętu przez uru-
Omawiane możliwości zwiększenia stabil- ku można powiedzieć, że aplikacja użytkowni- chomiony w systemie operacyjnym program
ności pracy systemu zaimplementowano przede ka nie ma możliwości operowania na portach użytkownika. Do realizacji tego zadania prze-
wszystkim z myślą o systemach operacyjnych, wejścia/wyjścia inaczej, niż za pośrednictwem znaczono wyjątek SVC.
jednak nic nie stoi na przeszkodzie, aby wyko-
rzystać je w aplikacjach nie pracujących pod
kontrolą OS.
Wyjątki systemowe
Kontrolę wykonywanych przez STM32 za-
dań znacznie ułatwiają trzy wyjątki systemowe,
dostępne w architekturze Cortex. Docelowym Rys. 8.
ich zadaniem jest praca pod kontrolą systemu
operacyjnego, aczkolwiek w aplikacjach bez
OS również można je z doskonałym Skutkiem
wykorzystać do zapewnienia większej kontroli
i stabilności pracy.
Do cyklicznego przełączania kontekstu za-
dań stworzono systemowy, 24 bitowy, timer Sy-
sTick. Jego zadaniem jest generowanie w okre-
ślonych odstępach czasu przerwania, a funkcja
jego obsługi może zajmować się właśnie przełą-
czaniem kontekstu zadań. Bardziej szczegółowo
zasadę działania i sposób konfiguracji timera
SysTick omówiono w EP12/08.
Pozostałe dwa wyjątki systemowe, to SVC
i PendSV. Pierwsza instrukcja przerwania jest
analogiczna do instrukcji przerwania SWI, którą
miały mikrokontrolery z rdzeniem ARM7. Zmia-
na nazwy wynika z potrzeby zabezpieczenia Rys. 9.
116 ELEKTRONIKA PRAKTYCZNA 4/2009
Bezpieczeństwo i stabilność aplikacji
czenia kontekstu zadań i wywołanie przerwania
PendSV. Dopiero to ostatnie przerwanie wykonu-
je właściwe przełączenie kontekstów tak, że gdy
mikrokontroler powraca do normalnego wyko-
nywania programu, to wówczas podejmowane
już jest wykonywanie następnego zadania.
Jeśli w trakcie przełączania kontekstów
zadań w funkcji obsługi przerwania PendSV
system zarejestruje inne przerwanie, to przełą-
czanie kontekstów zostaje wstrzymane przez
wywłaszczenie PendSV (pamiętajmy, że jego
priorytet jest najniższy). Cały omawiany proces
przedstawiono na rys. 9.
PendSV i SysTick
Podobnie ma się sprawa wtedy, gdy system
operacyjny przygotowuje przełączanie konteks-
tów zadań przy pomocy przerwania od timera Sy-
Rys. 10. sTick. W takiej sytuacji, zakładając, że przerwanie
od SysTick ma wysoki priorytet, a chwilę wcześ-
Jeśli program użytkownika chce skorzy- racyjny rozpocznie przełączanie kontekstów za- niej był obsługiwany jakiś inny wyjątek, nastąpi
stać ze sprzętu, to musi wywołać funkcję SVC, dań, to wychodząc z funkcji obsługi przerwania wywłaszczenie tego ostatniego na rzecz SysTick.
a dopiero ta realizuje zadanie z użyciem wyma- od timera SysTick, OS będzie próbował zmusić W związku z tym, że obsługa wywłaszczo-
ganego sprzętu. W dużym uproszczeniu przed- mikrokontroler do rozpoczęcia realizacji nowe- nego przerwania jest zdecydowanie ważniejsza
stawiono to na rys. 8. Dzięki temu wszystkie go zadania. Jest to rzecz jasna zachowanie błęd- od wykonywania uruchomionych w systemie
operacje z użyciem np. urządzeń peryferyjnych ne, ponieważ obsługa pierwszego przerwania zadań, to funkcja obsługi przerwania od timera
są pod kontrolą systemu operacyjnego. zostanie znacznie opóz
niona. Poza tym, może SysTick (podobnie jak SVC) tylko przygotowuje
Wyjątek PendSV zostać wygenerowany błąd. system do przełączenia kontekstu zadań i ge-
Jak napisano wcześniej, w najprostszym sys- Rozwiązaniem powyższego problemu jest neruje wyjątek PendSV. Teraz, skoro PendSV ma
temie operacyjnym, za przełączanie kontekstów zastosowanie wyjątku PendSV. Jego progra- najniższy priorytet, mikrokontroler wraca do
uruchomionych zadań odpowiada timer SysTick. mowalny priorytet jest ustawiany na najniższy obsługi wywłaszczonego wcześniej przerwania.
Podczas pracy takiego systemu może powstać możliwy, dzięki czemu przerwanie to nigdy nie Gdy czynności z tą obsługą zostaną zakończone,
prosty, choć nie zawsze oczywisty problem. wywłaszczy innych obsługiwanych przerwań. to oczekujący wyjątek PendSV zaczyna być reali-
Podczas realizacji zadanie (program użyt- Przeanalizujmy teraz zachowanie systemu zowany, konsekwencją czego jest przełączenie
kownika) może zostać zgłoszone przerwanie, z zaimplementowaną obsługą PendSV. Załóżmy, kontekstu i rozpoczęcie obsługi kolejnego uru-
które wywłaszczy dotychczasowy proces. Jeśli że zadanie realizowane w systemie nie ma ak- chomionego w systemie zadania, patrz rys. 10.
teraz, czyli w trakcie obsługi zgłoszonego prze- tualnie nic do zrobienia. Generuje wyjątek SVC, Krzysztof Paprocki
rwania, timer SysTick przerwie je i system ope- którego zadaniem jest przygotowanie do przełą- [e-mail]
REKLAMA
ELEKTRONIKA PRAKTYCZNA 4/2009 117