Więcej o firmie ELESOFTROM

Firma ELESOFTROM specjalizuje się w wykonywaniu i naprawianiu oprogramowania dla sterowników mikroprocesorowych.

Posiadamy ponad 10-letnie doświadczenie w tej dziedzinie.

W realizowanych projektach stawiamy na niezawodność i wydajność programów.

Naprawa oprogramowania

Oprogramowanie na zamówienie


Strona główna

Pełna oferta

Doświadczenie

O firmie

Kontakt


DioneOS - RTOS dla urządzeń embedded

Firma ELESOFTROM opracowała system RTOS dla procesorów ARM Cortex-M3 oraz msp430.

System jest zoptymalizowany pod względem wydajności, dzięki czemu uzyskano krótki czas przełączania pomiędzy wątkami.
System dostarcza elementy (np. semafory, mutexy, timery, kolejki itp.) niezbędne do tworzenia wielowątkowego firmware'u.

Wersja dla Cortexa została całkowicie przetestowana przy pomocy środowiska do automatycznego testowania.

Przeczytaj więcej:

Strona o systemie DioneOS

Niezawodność

Wydajność

Dokumentacja DioneOSa

Prezentacje n.t. DioneOS


^ Blog index    << Jak zainstalować i skalibrować TouchScreen ...    >> Maszyny stanowe - opis zachowania systemu

Przerwania w ARM Cortex-M3

2013-11-26    dr inż. Piotr Romaniuk

Spis treści

NVIC - Nested Interrupt Controller
Pozorne zamieszanie w nazewnictwie
Wyjątki, błędy i przerwania
Tablica wektorów przerwań
Stan wyjątku
Priorytety przerwań
Kolejność wyjątków
Maskowanie (blokowanie) wyjątków
Sprzętowe odkładanie na stosie rejestrów
Tail-chaining
Late arriving interrupt
Potok procesora a przerwania
Materiały na temat przerwań ARM-Cortex-M3

NVIC - Kontroler przerwań w Cortex-M3

Integralną częścią procesora ARMv7-M jest kontroler przerwań NVIC [Nested Vectored Interrupt Controller]. NVIC umożliwia uzyskanie 496 niezależnych przerwań. Kontroler może być wyzwalany poziomem lub zboczem na jego linii wejściowej. NVIC wykorzystuje tabelę wektorów wyjątków (uogólnione pojęcie przerwania) i zaawansowany sposób ustalania priorytetów, pozwalający na konfigurację wywłaszczania przerwań i ich ważności. Procesor Cortex-M3 obsługuje dodatkowe mechanizmy w zakresie obsługi przerwań takie jak: sprzętowe odkładanie rejestrów na stosie po wywołaniu przerwania a także optymalizacje w sytuacji wywłaszczających (zagnieżdzonych) się przerwań.

Pozorne zamieszanie w nazewnictwie
Posłużmy się przykładem mikrokontrolera STM32L firmy ST Microelectronics. Wydawać by się mogło, że panuje tu zamieszanie w nazewnictwie, można by się zastanawiać jak się do siebie maja: ARMv7-M, Cortex-M3, STM32L.

ARMv7-M to typ architektury, realizacją tej architektury jest Cortex-M3. Natomiast STM32L jest mikrokontrolerem, który ma w sobie Cortexa-M3 (oprócz tego procesora ma także wiele interfejsów, timerów, pamieć FLASH itp.).

Wyjątki, błędy i przerwania
W dokumentacji procesora ARMv7-M pojawiają się następujące określenia:

Wyjątek [Exception] jest pojęciem ogólnym obejmującym wszystkie inne. Może pojawic się z powodu:

  • wykonania instrukcji generującej wyjątek (celowo), np. SVC #n
  • jako konsekwencja zachowania systemu
    • z powodu pojawienia się przerwania sprzętowego
    • naruszenia zasad ochrony pamięci
    • błędów wyrównania lub magistrali
    • błędów stanu procesora
    • zdarzeń debugujących

Trzeba pamiętać, że procesor ARMv7-M różni się od innych procesorów ARMv7 w zakresie przerwań nastepującymi elementami:

  • wykonuje sprzętowe odkładanie na stosie rejestrów przy wejściu do ISR (przy wyjściu odtwarza rejestry ze stosu)
  • używa tablicy wektorów funkcji obsługujących wyjątki
  • inaczej grupowane są wyjątki

Tablica wektorów przerwań
Tablica wektorów przerwań składa się z elementów o rozmiarze słowa (32 bity). Pierwszy element to wartość wskaźnika stosu (SP) do inicjalizacji po resecie. Kolejne elementy tablicy to adresy procedur ISR odpowiadające kolejnym wyjątkom. Ich adresy w tabeli muszą mieć usatwiony bit0 co jest interpretowane przez procesor jako wejście w tryb Thumb przy wejściu w ISR. Nieustawienie tego bitu skutkuje wyjątkiem UsageFault a przy resecie HardFault.

Stan wyjątku
Wyjątki synchroniczne mogą być w jednym ze stanów:

  • oczekujący [pending] - wyjątek jest już zgłoszony ale nie jest jeszcze obsługiwany przez procesor
  • aktywny [active] - procesor już rozpoczął obługę wyjątku i jeszcze nie zakończył. Wyjątek w takim stanie może być wywłaszczony przez wyjątek o wyższym priorytecie.
  • nieaktywny [inactive] - jeśli wyjątek nie jest w stanie aktywnym ani oczekującym

W przypadku wyjątków asynchronicznych (np. przerwań zewnętrznych), wyjątek taki może być równocześnie w stanie aktywnym i oczekującym. Dzięki temu np. nie zostanie zgubione przerwanie zgłoszone podczas jego obsługi.

Priorytety przerwań
ARMv7-M używa złożonego sposobu priorytetyzacji wyjątków. Trzy pierwsze, podstawowe wyjątki (t.j. Reset, NMI, HardFault) mają odpowiednio priorytety -3, -2, -1, których nie można zmienić. Priorytety pozostałych wyjątków można konfigurować.

Każdy konfigurowalny priorytet składa się z dwóch części (pól bitowych):
1. Grupy wywłaszczania [preemption group]
2. Podpriorytetu [sub-priority]
Wartość priorytetu jest nie więcej niż 8-bitowa (Uwaga: dla STM32L jest 4 bitowa). Dwuczęściowe określanie priorytetu pozwala na panowanie nad wywłaszczaniem przerwań. Podczas podejmowania decyzji o tym które przerwanie będzie wykonywane stosuje się nastepujące zasady:

  • priorytet o mniejszej wartości jest bardziej istotny
  • wyjątki mogą zostać wywłaszczone tylko przez wyjątki należace do ważniejszej grupy wywłaszczania,
  • jeśli dwa przerwania należą do tej samej grupy to obsługiwane jest to, które ma bardziej istotny priorytet (tzn. mniejsza wartość subpriority)
  • jeśli przerwania mają takie same wartości priorytetów, to obsługiwane jest najpierw to, które ma mniejszy numer (jest wcześniej w tabeli wyjątków) - to jest na stałe ustalone
  • na początku wszystkie wyjątki mają priorytet 0

Na początku konfiguracji ustala się podział n-bitowego priorytetu na powyżej przedstawione części.
Dla STM32L możliwe są nastepujące ustawienia:
Lp podział liczba grup wywłaszczania liczba sub-priorytetów w grupie uwagi
1. 0:4 1 16 bez wywłaszczania
2. 1:3 2 8
3. 2:2 4 4
4. 3:1 8 2
5. 4:0 16 1 każde może być wywłaszczone

Przypisując wyjątki (w tym przerwania) do odpowiednich grup wywłaszczania oraz nadając im sub-priorytety można zrealizować zamierzone reguły wywłaszczania.

Przykład
Niech jakiś system embedded używa procesora STM32L i wykorzytsuje 3 przerwania: EXTI0 (z zewnętrznej końcówki GPIO), USART1 (z USART, odebrany/wysłany znak) oraz TIM9 (przerwanie Timera). Załóżmy, że wymagane jest aby przerwania od timera i usarta nie wywłaszczały się wzajemnie, a gdyby oczekiwały oba, to niech pierwsze wywoła się to od usarta. Dodatkowo wymaga się aby przerwanie od końcówki GPIO miało największy priorytet i mogło wywłaszczyć oba pozostałe.

Aby spełnić te założenia, można skonfigurować priorytety nastepująco:
* podział priorytetu na grupa:sub-priorytet: 2:2
* priorytet EXTI0: 0.0 = 0
* priorytet USART1: 1.0 = 4
* priorytet TIM9: 1.1 = 5

Kolejność wyjątków

Kolejność wyjątków ma znaczenie dwojakie:
- określa który z nich jest ważniejszy gdy mają te same priorytety
- odpowiada lokalizacji wektorów w tablicy wektorów wyjątków
Poniżej przedstawiony jest fragment listy wyjątków dla STM32L1xx o małej i średniej wielkości
PriorytetNazwa Opis Adres uwagi
-3 Reset Reset 0x0000.0004 priorytet stały
-2 NMI przerwanie niemaskowalne 0x0000.0008 priorytet stały
-1 HardFault błędy krytyczne 0x0000.000c priorytet stały
0 MemManage manager pamięci 0x0000.0010
1 BusFault błąd podczas fazy prefetch lub dostępu do pamięci 0x0000.0014
2 UsageFault niezdefiniowana instrukcja lub niewłaściwy stan 0x0000.0018
3 SVC_Handler system service call przez instrukcję SVC 0x0000.002c
4 DebugMon debug monitor 0x0000.0030
5 PendSV żądanie opóźnionego wywołania systemowego 0x0000.0038
6 SysTick Timer systemowy - przerwanie okresowe 0x0000.003c
7 WWDG Window watchdog 0x0000.0040
.. ... ... 0x0000.0044
13 EXTI0 przerwanie z końcówki GPIO 0x0000.0058
.. ... ... 0x0000.005c
17 EXTI4 przerwanie z końcówki GPIO 0x0000.0068
18 DMA1_Channel1 kanał 1 DMA1 0x0000.006c
.. ... ... 0x0000.0070

Na początku powyższej listy znajdują się przerwania pochodzące z samego procesora (Cortex-M3) - wyróżnione ciemniejszym kolorem. Wg terminologii z dokumentacji ARMv7-M PendSV oraz SysTick są przerwaniami zewnętrznymi dla core.
UWAGA: Biblioteka CMSIS używa innej numeracji wyjątków: IRQn <0 - wyjątki procesora, IRQn >= 0 - przerwania zewnętrzne (w stosunku do procesora [core])

Maskowanie (blokowanie) wyjątków
Wyjątki mogą być maskowane w różny sposób:
* globalnie poprzez ustawienie flag w rejestrach PRIMASK oraz FAULTMASK (instrukcje CPSIE/D i/f)
* poprzez ograniczenie dopuszczajnych priorytetów - rejestr BASEPRI (dokładnie poprzez określenie grupy wywłaszczania)
* poprzez ustawienie odpowiedniej maski w kontrolerze przerwań
Ustawienie BASEPRI=0 powoduje, że ograniczenie to jest nieaktywne. Ustawienie wartości większej od zera prowadzi do blokowania przerwań posiadających wartość priorytetu większą lub równą wartości rejestru BASEPRI. Uwaga: BASEPRI wpływa na blokowanie grup wywłaszczania (nie na sub-priorytet).

Sprzętowe odkładanie na stosie rejestrów
Po zgłoszeniu przerwania jednocześnie wykonywane jest przez procesor Cortex-M3 pobieranie wektora z tablicy wektorów wyjątków oraz odkładanie na stosie podstawowych rejestrów (t.j. r0-r3, r12, LR, PC, xPSR).

Po zakończeniu obsługi ISR rejestry są odtwarzane ze stosu.

Tail-chaining
Aby zaoszczędzić czas podczas obsługi przerwań następujących po sobie projektancji Cortex-M3 wprowadzili tzw. Tail-Chaining. W przypadku gdy jakieś przerwanie oczekuje podczas kończenia ISR nie jest wykonywane odtwarzanie rejestrów ze stosu i ponowne zapisywanie tylko od razu sterowanie jest przenoszone do kolejnego ISR.

Late arriving interrupt
Aby polepszyć szybkośc reakcji i wywłaszczanie przerwań, Cortex-M3 może wywłaszczyć bieżące przerwanie jeszcze tuż przed wejściem w jego ISR. Przykładowo: jeśli przerwanie o niskim priorytecie odłożyło już na stosie rejestry ale jeszcze nie rozpocząl się jego ISR, a w tym czasie pojawiło się przerwanie wywłaszczające, to procesor zaczyna wykonywać to ważniejsze, Taki schemat działania jest opisany w dokumentacji jako Late-Arriving-Interrupt.

Potok procesora a przerwania

Procesor Cortex-M3 posiada potok [pipeline], w którym w kolejnych etapach instrukcje są pobierane, dekodowane i wykonywane. Z tego powodu, dla niektórych instrukcji, efekt ich działania pojawia się później niź przy następnej instrukcji. Dzieje się tak np. dla instrukcji CPSIE i, gdzie przerwania nie są jeszcze włączone dla następującej po niej instrukcji. Oczywiście nie jest to jedyny przypadek. Jeśli takie zjawisko jest niekorzystne, to należy zastosować odpowiednią barierę synchronizującą (w postaci odpowiedniej instrukcji) - zapewniają one przejście przez potok i wykonanie poprzedniej instrukcji (włącznie z zapisem do pamięci) zanim rozpocznie się kolejna instrukcja.

Cortex-M3 dostarcza następujących barier:
DMB - Data Memory Barrier
DSB - Data Synchronization Barrier
ISB - Instruction Synchronization Barrier

Materiały na temat przerwań ARM-Cortexa-M3

  1. ARM Information Center,
  2. ARMv7-M Architecture Reference Manual,
  3. Cortex-M3 Technical Reference Manual,
  4. STM32L1xx Reference Manual