Watchdog – czyli pies stróżujący Twojej aplikacji

Każdy, kto na co dzień zajmuje się programowaniem systemów wbudowanych, spotkał się pewnie nie raz z sytuacją, w której wykonywany program (a właściwie jego wątek) dociera do pętli nieskończonej i w efekcie „zawiesza się”. Czasem może to być pożądane działanie (np. przy debuggowaniu), jednak najczęściej wynika to z błędu aplikacji (niewłaściwa obsługa wyjątku błędu czy np. blokująca funkcja Spi_ReadData bez zdefiniowanego timeoutu). W takich sytuacjach nieodzowne staje się zastosowanie watchdoga.

Więcej o tym systemie dowiecie się z niniejszego artykułu.

Czym jest watchdog i po co się go stosuje?

Watchdog, jak sama nazwa wskazuje, ma za zadanie czuwać nad bezpieczeństwem naszej aplikacji. W najprostszym ujęciu jest to specjalny timer, który przy odpowiedniej konfiguracji generuje sygnał resetu procesora/systemu w odpowiedzi na przepełnienie swojego licznika, czyli osiągnięcie przez niego zdefiniowanej wartości timeoutu.

W momencie, gdy watchdog jest skonfigurowany i włączony, jedyną możliwością uniknięcia resetu jest odświeżenie licznika przez aplikację lub całkowite wyłączenie przez nią watchdoga, zanim timeout zostanie osiągnięty. Jest to mechanizm szczególnie często wykorzystywany w systemach, które muszą spełniać wymagania związane z bezpieczeństwem użytkownika (np. w branży automotive). Może on również znaleźć zastosowanie w aplikacjach niezwiązanych z bezpieczeństwem – jako dodatkowy środek podnoszący niezawodność produktu.

Wewnętrzne i zewnętrzne watchdogi

W systemach wbudowanych można spotkać watchdogi wewnętrzne lub zewnętrzne. W ogólnym ujęciu realizują one tę samą funkcję, jednak różnią się swoją implementacją. Często dla projektów z wysokimi wymogami bezpieczeństwa stosowane są oba mechanizmy jednocześnie w celu zapewnienia redundancji.

Watchdog wewnętrzny jest to timer wbudowany w mikrokontroler, na którym wykonywana jest aplikacja (innymi słowy – jest to peryferium tego mikrokontrolera). Konfiguracja oraz obsługa przez aplikację realizowana jest poprzez bezpośredni zapis/odczyt rejestrów z przestrzeni adresowej mikrokontrolera. Sygnał resetu (lub przerwania) przekazywany jest bezpośrednio do wewnętrznej linii resetu (lub przerwania) mikrokontrolera.

Watchdog zewnętrzny to, z perspektywy głównego kontrolera, osobny układ scalony z własnym firmware’em, którego konfiguracja i obsługa odbywają się poprzez wysyłanie określonych komend po zewnętrznej magistrali danych (np. SPI) oraz interakcję z jego wejściami/wyjściami cyfrowymi. Spotkać można zarówno układy scalone realizujące praktycznie tylko i wyłącznie funkcję watchdoga lub bardziej zaawansowane, łączące w sobie np. funkcje CAN transceivera i watchdoga.

Zastosowania watchdoga

Z opisanych wcześniej właściwości watchdoga wynika, że jest to dobre narzędzie do monitorowania i kontroli wywoływania określonych funkcji programu w narzuconym przedziale czasowym. W oparciu o tę funkcjonalność można tworzyć mechanizmy software’owe o różnych praktycznych zastosowaniach:

• alive monitoring – najprostsza forma wykorzystania watchdoga. Polega na zdefiniowaniu jednego lub wielu miejsc w programie, które z założenia powinny wykonywać się cyklicznie. Po osiągnięciu wszystkich zdefiniowanych miejsc w danym cyklu SW odświeża licznik watchdoga. W przeciwnym wypadku następuje reset.
• deadline monitoring – przydatny w sytuacji, gdy czas wykonywania danej operacji nie może (np. ze względów bezpieczeństwa) być dłuższy niż pewna wartość graniczna (deadline). Jeśli czas wykonywania monitorowanej funkcji przekroczy deadline, to funkcja resetująca licznik watchdoga nie zdąży się wykonać i nastąpi reset.
• program flow monitoring (logical supervision) – polega na zdefiniowaniu sekwencji zdarzeń w programie, które powinny wykonać się w narzuconym czasie. Tylko po wykonaniu wszystkich zdarzeń w odpowiedniej kolejności licznik watchdoga jest resetowany.

Konfiguracja watchdoga

Typowe parametry watchdoga

Typowa konfiguracja watchdoga polega przede wszystkim na ustaleniu wartości timeoutu licznika, po przekroczeniu której ma nastąpić reset. Dodatkowo, bardzo popularnym parametrem konfiguracyjnym jest wartość początkowa okna watchdoga wykorzystywana w trybie okienkowym (ang. window mode). Ponadto, w rejestrach kontrolnych watchdogów na niektórych platformach spotkać można np.:

• soft/hard lock protection – parametry definiujące możliwość ponownego nadpisania raz zapisanego rejestru kontrolnego,
• stop/freeze mode handling – parametry definiujące, czy licznik watchdoga jest zatrzymywany w momencie wejścia mikrokontrolera odpowiednio w Stop Mode / Debug Mode, co pozwala uniknąć resetu podczas debuggowania,
• keyed trigger/service mode – parametry definiujące, jaką wartość należy wpisywać do rejestru odpowiedzialnego za cykliczne odświeżanie licznika watchdoga (np. ustalone w nocie katalogowej stałe wartości kluczy lub wartości zmienne obliczane na podstawie ustalonego algorytmu),
• clock selection – zegar wewnętrzny lub zewnętrzny,
• timeout reaction – domyślnie reset, ale w niektórych przypadkach dostępne są też opcje np. „1.timeout-przerwanie, 2.timeout-reset”.

Tryb okienkowy

Window mode pozwala na zdefiniowanie w osobnym rejestrze minimalnej wartości licznika watchdoga, przy której jego odświeżanie jest dozwolone. W efekcie definiowany jest cykliczny przedział czasowy (okno), w którym aplikacja powinna resetować licznik watchdoga. Pozwala to na bardziej precyzyjne monitorowanie zależności czasowych w aplikacji.

Przykładowa konfiguracja wewnętrznego watchdoga

Załóżmy, że nasza aplikacja obsługuje sterownik ładowarki baterii samochodów elektrycznych. Główną funkcją systemu jest pomiar, analiza i kontrola parametrów elektrycznych ładowania (prąd, napięcie). Pomiar napięcia dokonywany jest przez zewnętrzny układ scalony Xyz, z którego nasz mikrokontroler cyklicznie czyta dane pomiarowe. Układ ten posiada predefiniowane funkcje diagnostyczne pozwalające na weryfikację na bieżąco własnej sprawności (np. self-test).

W celu spełnienia zdefiniowanej poprzez analizę bezpieczeństwa klasyfikacji ASIL jedno z wymagań brzmi następująco:

• SW musi wykonywać istotne dla bezpieczeństwa funkcje diagnostyczne układu Xyz minimum co 100 ms.
• Funkcje diagnostyczne układu Xyz nie mogą być wykonywane przez SW częściej niż raz na 70ms.

Dodatkowym założeniem jest, że za kontrolę wymogów czasowych wykonywania funkcji istotnych dla bezpieczeństwa układu scalonego Xyz odpowiada wewnętrzny watchdog mikrokontrolera:

• SW musi monitorować kryteria czasowe wykonywania istotnych dla bezpieczeństwa funkcji diagnostycznych układu Xyz z wykorzystaniem watchdoga wewnętrznego DWD (Digital Watchdog).

Ponadto definiujemy, jakiej reakcji spodziewamy się na niespełnienie kryteriów czasowych. Dla przykładu:

• Jeśli DWD wykryje, że wykonywanie funkcji diagnostycznych układu Xyz przekroczyło kryteria czasowe SW powinien zapisać kod błędu w pamięci FLASH i zresetować system.

Na podstawie wymienionych wyżej wymagań zakładamy, że nasza funkcja obsługująca wykonywanie mechanizmów diagnostycznych układu Xyz będzie wykonywana w tasku cyklicznym co 90 ms (np. co 9. wykonanie tasku 10 ms).

Na podstawie powyższych założeń można skonfigurować wewnętrzny watchdog DWD (Digital Watchdog) mikrokontrolera RM57Lx w następujący sposób.

Krok 1: Ustaw wartość timeoutu (rejestr RTIDWDPRLD)

Rejestr RTIDWDPRLD (pole DWDPRLD) przechowuje zdefiniowaną przez użytkownika wartość przepełnienia licznika (preload/deadline). Do rejestru jest możliwy zapis wyłącznie przed włączeniem watchdoga.

Czas przepełnienia licznika watchdoga można wyznaczyć z równania:

T_exp = (DWDPRLD+1) x 2¹³ / RTICLK1

gdzie:

DWDPRLD = 0…4095
RTICLK1 – częstotliwość zegara taktującego moduł RTI, przyjmijmy 8MHz

W naszym przypadku przyjmujemy:

T_exp = 100 ms

Czyli:

DWDPRLD = T_exp*RTICLK1/2¹³-1 = 100 ms*8 MHz/8192-1 = 96,66 = 96

Dla wartości DWDPRLD = 96 finalnie otrzymujemy deadline watchdoga T_exp = 99,33 ms

Krok 2: Ustaw wielkość okna watchdoga (rejestr RTIWWDSIZECTRL)

Rejestr RTIWWDSIZECTRL pozwala na zdefiniowanie rozmiaru okna watchdoga poprzez wybór jednej z wartości z tabeli:

Zgodnie z wymaganiami, licznik watchdoga powinien być odświeżany cyklicznie w przedziale czasowym [70 ms;100 ms]. W związku z tym dobieramy wartość z tabeli:

WWDSIZE = 0x00000500 (odp. Rozmiarowi okna 25%)

Przy powyższych założeniach faktycznie zdefiniowany przedział czasowy (okno) wygląda następująco:

[99,33*75%; 99,33 ms] = [74,50 ms; 99,33ms]

Przedział ten pozwala spełnić w/w wymagania czasowe.

Krok 3: Ustaw reakcję watchdoga na błąd (rejestr RTIWWDRXNCTRL)

W omawianym przez nas mikrokontrolerze istnieje możliwość wyboru, w jaki sposób watchdog reaguje na błąd, tj. na przepełnienie licznika lub próbę jego odświeżenia poza zdefiniowanym oknem, poprzez ustawienia wartości rejestru RTIWWDRXNCTRL zgodnie z poniższą tabelą:

W naszym przypadku po wykryciu przekroczenia kryteriów czasowych przez aplikację SW powinien zapisać kod błędu do pamięci nieulotnej, a następnie zresetować system. W związku z tym wybieramy obsługę błędu w przerwaniu i ustawiamy wartość

WWDRXN = 0x0A

W funkcji obsługi przerwania zawarta będzie obsługa zapisu kodu błędu do pamięci FLASH oraz wywołanie wprost resetu systemu (software reset).

Uwaga! W przedstawionym wyżej rozwiązaniu system nie zostanie zresetowany, jeśli aplikacja „zawiesi się” w trakcie wykonywania zdefiniowanej przez nas funkcji obsługi przerwania (tj. podczas zapisywania kodu błędu). Rozpatrywany przez nas moduł watchdoga daje możliwość zmiany konfiguracji rejestru RTIWWDRXNCTRL, nawet jeśli watchdog został już uprzednio włączony.

W związku z tym rozsądnym rozwiązaniem jest zmiana konfiguracji RTIWWDRXNCTRL na początku funkcji obsługi przerwania błędu watchdoga WWDRXN = 0x05 (dzięki temu watchdog zresetuje system, nawet jeśli funkcja obsługi przerwania utknie w pętli nieskończonej). Alternatywnym rozwiązaniem przedstawionego problemu jest zastosowanie równolegle watchdoga zewnętrznego, który reagowałby na błąd (przekroczenie timeoutu) resetem. W takim przypadku timeout watchdoga zewnętrznego powinien być odpowiednio dłuższy i uwzględniać deadline na wykonanie funkcji obsługi przerwania watchdoga wewnętrznego.

Krok 4: Włącz watchdog (rejestr RTIDWDCTRL)

Rejestr RTIDWDCTRL służy do włączenia watchdoga poprzez zapis zdefiniowanego klucza. W mikrokontrolerze RM57Lx, po uprzednim włączeniu watchdoga, można go wyłączyć jedynie poprzez system reset (aplikacja nie może wyłączyć watchdoga). W celu włączenia watchdoga zapisujemy odpowiednią wartość klucza:

DWDCTRL = 0xA98559DA (zapisz wartość klucza do włączania watchdoga).

Włączenie watchdoga powinno być ostatnim krokiem jego inicjalizacji. Jak już wcześniej wspomniałem, w wybranym mikrokontrolerze niektóre parametry konfiguracyjne mogą być modyfikowane już po włączeniu watchdoga (np. wielkość okna lub reakcja na błąd), jednak nie zaleca się włączać watchdoga, zanim wartości początkowe tych parametrów nie zostaną ustawione wprost przez aplikację.

Watchdog a debuggowanie

W poprzednich rozdziałach omówiłem podstawowe kwestie związane z watchdogiem oraz opisałem jego przykładową konfigurację. W ostatnim punkcie tego artykułu chciałbym poruszyć zagadnienia związane z debuggowaniem aplikacji z watchdogiem.

Jak watchdog wpływa na możliwość debuggowania programu?

Głównym problemem, które należy rozpatrzyć w kontekście debuggowania aplikacji z watchdogiem, jest określenie, jak ma pracować watchdog w momencie wstrzymania wykonywania instrukcji przez CPU na żądanie debuggera (czyli wejście w tryb Debug Suspend).

Jeśli zależy nam, żeby debuggowanie było możliwe, musimy uniknąć sytuacji, w której wykonywanie programu jest wstrzymane przez debugger, a licznik watchdoga kontynuuje pracę. W przeciwnym wypadku każdorazowe spotkanie naszego Program Countera z breakpointem skończy się przerwaniem lub resetem wygenerowanym przez watchdoga.

Większość mikrokontrolerów daje użytkownikowi możliwość konfiguracji pracy watchdoga dla trybu Debug Suspend.

Dla przykładu:

• dla omawianego w poprzednim rozdziale mikrokontrolera RM57Lx istnieje parametr konfiguracyjny COS (Continue on Suspend) w rejestrze RTIGCTRL, który definiuje zbiorczo zachowanie wszystkich liczników wchodzących w skład modułu RTI (Real Time Interrupt) – w tym watchdoga DWD – na wejście aplikacji w tryb Debug Suspend (halting debug):

• dla mikrokontrolera z rodziny MPC563X od NXP istnieje możliwość bezpośredniej konfiguracji zachowania licznika watchdoga w trybie Debug Suspend z poziomu rejestru SWT_CR (Software Watchdog Control Register), bit FRZ:

Również w sytuacji, kiedy nasza aplikacja korzysta z zewnętrznego watchdoga, powinniśmy uwzględnić jego wpływ na możliwość debuggowania. Najprostszym (i najczęściej jedynym) rozwiązaniem jest wyłączenie watchdoga na czas debuggowania. Zwykle zewnętrzne układy scalone z funkcją watchdoga mają osobne wejście cyfrowe kontrolujące jego stan (on/off).

Konfiguracja tych pinów jest nadrzędna w stosunku do rejestrów kontrolnych odpowiedzialnych za ustawienia watchdoga w danym układzie scalonym. Stan w/w pinów kontroluje się przeważnie z pominięciem aplikacji głównego mikrokontrolera np. poprzez zastosowanie zworki lub przekaźnika kontrolowanego przez zewnętrzny tester.

Uwaga! Wszystkie w/w mechanizmy nie wymagają wyłączania watchdoga bezpośrednio przez aplikację dla wersji software’u przeznaczonej do debuggowania. Ma to oczywistą zaletę – w momencie uruchomienia takiej aplikacji na mikrokontrolerze bez połączenia z debuggerem (lub w przypadku watchdoga zewnętrznego z odpowiednio ustawioną zworką) watchdog zareaguje resetem/przerwaniem na błąd.

Jak testować/debuggować działanie watchdoga?

Na koniec warto przytoczyć kilka praktycznych wskazówek, jak podejść do debuggowania oraz testowania funkcjonalności samego watchdoga.

W fazie pisania/konfiguracji sterownika watchdoga możliwość debuggowania z podglądem jego rejestrów wydaje się niezbędna. W niektórych mikrokontrolerach w takich rejestrach wyszczególniono flagi odpowiadające różnym typom błędów, na które watchdog reaguje resetem (start/end window violation, invalid register access itd.).

Również ustawienie przerwania zamiast resetu jako reakcji na błąd watchdoga (przynajmniej w SW testowym/deweloperskim) może być pomocne w debuggowaniu. Pozwala to zapisać kod/flagę błędu w pamięci nieulotnej lub postawić breakpoint w funkcji obsługi przerwania w celu sprawdzenia kontekstu błędu.

Jednak przy debuggowaniu watchdoga należy też mieć na uwadze ograniczenia, które można spotkać w niektórych mikrokontrolerach. Przykładowo w mikrokontrolerach z rodziny Aurix TC3xx watchdogi wewnętrzne są domyślnie wyłączone przy podpiętym debuggerze (czyli kiedy OCDS jest włączony) – ustawienia takie są nadrzędne nad konfiguracją rejestrów watchdoga przez użytkownika. W takich przypadkach należy wykonać kroki zgodnie z dokumentacją mikrokontrolera w celu włączenia watchdoga dla trybu debug (jeśli takowe są udostępnione). Nierzadko identyfikacja wpływu debuggera na zachowanie watchdoga może być kłopotliwa z uwagi na poziom skomplikowania dokumentacji mikrokontrolera.

W związku z powyższymi ograniczeniami zdecydowanie zalecaną praktyką jest finalnie przeprowadzenie testów funkcjonalnych watchdoga z odłączonym debuggerem.

W celu przetestowania watchdoga bez udziału debuggera należy przygotować środowisko testowe pozwalające na weryfikację wykonania resetu po błędzie watchdoga (np. dedykowana ramka CAN wysyłana w fazie start-up aplikacji). W celu sprawdzenia głównej funkcjonalności watchdoga – czyli reakcji na przepełnienie licznika – warto zaimplementować prostą funkcję testową blokującą po określonym czasie lub na żądanie testera (wysłane np. po magistrali CAN) wykonanie wątku odpowiedzialnego za cykliczne resetowanie tego licznika.

Podsumowanie

W artykule omówiłem główne zagadnienia dotyczące watchdoga. Opisałem jego funkcjonalność oraz podział na watchdogi wewnętrzne i zewnętrzne. Wymieniłem główne zastosowania oraz parametry konfiguracyjne. Na przykładzie pokazałem typową konfigurację rejestrów watchdoga wewnętrznego w oparciu o uproszczone wymagania. Na koniec poruszyłem zagadnienia związane z debuggowaniem aplikacji z watchdogiem.

W praktyce, aby w pełni wykorzystać korzyści płynące z używania watchdoga w aplikacji, tworzone są specjalne komponenty software’owe pozwalające monitorować wykonanie w określonym czasie wielu fragmentów kodu w aplikacji i reagować na wykryte błędy z wykorzystaniem jednego lub wielu watchdogów (przykład: WdgM w standardzie Autosar). Jest to jednak temat na osobny artykuł.

Bibliografia

1. RM57Lx 16/32-Bit RISC Flash Microcontroller Technical Reference Manual, Texas Instruments Incorporated, 2018-03
2. MPC5634M Microcontroller Reference Manual, Freescale Semiconductor, 2012-09
3. Infineon-AURIX_TC3xx_Part1-UserManual-v02_00-EN, Infineon Technologies AG, 2021-02
4. Specification of Watchdog Manager AUTOSAR CP R22-11, AUTOSAR, 2022-11