Watchdog i recovery flight controllera

Watchdog jest niezależnym mechanizmem, który resetuje albo przełącza system, gdy oprogramowanie nie potwierdzi postępu w określonym czasie. Nie jest lekiem na każdy błąd: źle umieszczone odświeżenie może działać mimo zawieszonej estymacji, a niekontrolowany reset może pogorszyć sytuację w locie. Skuteczny projekt łączy sprzętowy watchdog, monitor żywotności podsystemów, trwały zapis przyczyny resetu, ograniczone recovery i jawny tryb bezpieczny.

Spis treści#

Co watchdog wykrywa
Czego watchdog nie dowodzi
IWDG i WWDG
Zewnętrzny supervisor
Dobór timeoutu
Odświeżenie zależne od postępu
Monitor zadań RTOS
Monitor bare-metal
Liveness, deadline i plausibility
Hierarchia recovery
Reset nie jest stanem bezpiecznym
Reset reason i crash record
HardFault i early warning
Boot loop
Watchdog urządzeń peryferyjnych
Brownout i zegary
Debugowanie
Wstrzykiwanie awarii
Metryki eksploatacyjne
Lista projektowa
Powiązane tematy
Przypisy

Co watchdog wykrywa#

Sprzętowy licznik wykrywa brak odświeżenia. Przy poprawnej architekturze brak ten może wynikać z:

nieskończonej pętli albo deadlocku;
zawieszenia scheduler-a lub wyłączenia przerwań;
zakleszczenia sterownika czekającego na flagę peryferium;
przeciążenia CPU uniemożliwiającego dotrzymanie deadline;
uszkodzenia zegara głównego, jeśli watchdog ma własne źródło;
błędu pamięci lub skoku programu, który przerwał ścieżkę nadzoru.

Watchdog mierzy czas, a nie intencję programu. Aby brak refresh odpowiadał utracie istotnej funkcji, oprogramowanie musi warunkować odświeżenie potwierdzonym postępem.

W flight controllerze wymagane funkcje nie są równoważne. Utrata loggera może pozwolić na kontynuację lotu, ale brak aktualizacji pętli rate lub komend aktuatorów jest krytyczny. Monitor przechowuje osobny kontrakt dla każdej funkcji.

Czego watchdog nie dowodzi#

Program może wykonywać kod i regularnie odświeżać licznik, a jednocześnie:

publikować zamrożoną próbkę IMU;
sterować z błędnym znakiem osi;
nie odczytywać nowych komend RC;
generować NaN w regulatorze;
wysyłać stare wartości do ESC;
działać w pamięci po cichej korupcji danych;
być logicznie w złym stanie maszyny failsafe.

Dlatego „watchdog nie resetuje” nie jest testem poprawności lotu. Potrzebne są trzy warstwy:

liveness — kod wykonuje cykle;
timeliness — cykle mieszczą się w deadline i mają akceptowalny jitter;
correctness/plausibility — dane zmieniają się, mają poprawny wiek, zakres i spójność.

Watchdog sprzętowy jest ostatnią linią. Wcześniejsze monitory mogą odizolować konkretny sensor albo przejść w failsafe bez resetowania całego MCU.

IWDG i WWDG#

Rodziny STM32 typowo oferują independent watchdog i window watchdog. Szczegóły zawsze pochodzą z reference manual konkretnego układu.

IWDG jest taktowany niezależnym oscylatorem LSI. Może działać, gdy zatrzyma się zegar główny, i po uruchomieniu często nie może być zatrzymany do resetu. Jego timeout ma tolerancję wynikającą z niedokładnego LSI. Do obliczeń wykorzystuje się skrajne częstotliwości z datasheetu, nie nominalne 32 kHz.

WWDG jest związany z zegarem systemowym/peryferyjnym i wymaga refresh w oknie: zbyt późne i zbyt wczesne odświeżenie powoduje reset. Wykrywa więc kod, który przypadkowo wywołuje refresh zbyt często. Jeśli jednak awaria zatrzyma również źródło zegara WWDG, niezależny IWDG zapewnia inną domenę detekcji.

Rozsądna hierarchia może używać window watchdog do szybkiego wykrycia błędnej sekwencji i IWDG jako niezależnego bezpiecznika. Dwa watch dogi nie są automatycznie lepsze: ich timeouty, reset cause i zachowanie podczas debug/low-power trzeba zaprojektować wspólnie.

Niektóre MCU mają early wake-up interrupt tuż przed resetem. Jest ono szansą zapisania małego rekordu, nie czasem na pełny flush logu do systemu plików.

Zewnętrzny supervisor#

Watchdog wewnętrzny współdzieli z MCU zasilanie, reset i część krzemu. Zewnętrzny supervisor może monitorować napięcie, osobny pin heartbeat i wymusić reset lub odcięcie domeny.

Zewnętrzny układ ma wartość, gdy analiza awarii obejmuje:

zablokowany pin resetu lub uszkodzenie MCU;
awarię wewnętrznego oscylatora watchdoga;
potrzebę power-cycle urządzeń, których reset MCU nie obejmuje;
kontrolę sekwencji kilku szyn;
niezależny limit czasu certyfikowanego toru.

Heartbeat nie może być prostym PWM generowanym całkowicie sprzętowo bez udziału krytycznego kodu. Timer będzie przełączał pin mimo deadlocku zadań. Lepsze jest okno, w którym monitor programowy świadomie zmienia stan po zebraniu dowodów postępu.

Power-cycle jest bardziej inwazyjny od resetu CPU. Może zgasić sensory, pamięć i transceivery, a przy niewłaściwej kolejności zasilić je przez piny sygnałowe. Supervisor musi respektować minimalny czas wyłączenia i stabilizacji szyn.

Dobór timeoutu#

Timeout musi być dłuższy od potwierdzonego najgorszego czasu poprawnej pracy, ale krótszy od maksymalnego tolerowanego czasu braku sterowania. Te dwa warunki mogą być sprzeczne — wtedy architektura potrzebuje szybszej lokalnej reakcji aktuatorów, a nie przypadkowego kompromisu licznika.

Budżet obejmuje:

T_wdg_min > T_monitor_period_max
            + T_blocking_critical_section_max
            + T_irq_latency_max
            + T_clock_tolerance
            + margines

Z drugiej strony:

T_detection + T_reset + T_boot + T_reinit < T_hazard

Jeżeli ESC przechodzi w bezpieczny stan po braku nowych poleceń w 100 ms, a FC potrzebuje 800 ms na reboot, watchdog nie zapewnia ciągłości sterowania. Zapewnia jedynie próbę odzyskania systemu po wcześniejszej reakcji failsafe aktuatora.

Najgorszy czas mierzy się przy zapisie flash, pełnym DMA, przeciążeniu magistral, wyłączonej pamięci cache tam, gdzie może się zdarzyć, i w obsłudze błędów. Średnia pętla 400 µs nie uzasadnia timeoutu 1 ms, jeśli erase flash trwa znacznie dłużej.

Odświeżenie zależne od postępu#

Najgorszy wzorzec to odświeżanie w przerwaniu timera o najwyższym priorytecie. Timer może działać mimo zatrzymania całej aplikacji. Równie słabe jest odświeżanie w idle task: dowodzi tylko, że scheduler czasem nie ma pracy, a krytyczne zadanie mogło umrzeć.

Dedykowany supervisor otrzymuje znaczniki postępu od wymaganych modułów. Odświeża sprzętowy watchdog tylko, gdy wszystkie warunki dla bieżącego trybu są spełnione.

bool healthy = true;
healthy &= deadline_ok(TASK_RATE);
healthy &= deadline_ok(TASK_ESTIMATOR);
healthy &= sample_fresh(IMU_PRIMARY);
healthy &= actuator_path_progressed();

if (healthy && system_state_allows_refresh()) {
    iwdg_refresh();
}

Flaga bool ustawiona raz nie jest dowodem kolejnych cykli. Każdy moduł publikuje monotoniczny licznik generacji albo timestamp ostatniego zakończonego cyklu. Monitor pamięta poprzednią wartość i wymaga jej zmiany.

Supervisor nie może sam czekać na mutex kontrolowanego zadania, bo deadlock obejmie również nadzór. Odczytuje atomowe heartbeat i ma minimalną zależność od heap, loggera oraz skomplikowanych sterowników.

Monitor zadań RTOS#

Dla każdego zadania definiuje się:

Pole	Znaczenie
`period/deadline`	oczekiwany czas między postępami
`criticality`	reset, degradacja albo tylko alarm
`phase`	czy zadanie jest aktywne w danym trybie
`generation`	licznik ukończonych jednostek pracy
`last_start/end`	timestamp i czas wykonania
`overrun_count`	przekroczenia budżetu

Zadanie zgłasza ukończenie sensownej jednostki: pętla rate po opublikowaniu wyjścia, estymator po poprawnej aktualizacji stanu, driver IMU po odebraniu nowej próbki. Wejście do funkcji nie wystarcza.

Priorytet supervisora musi pozwalać mu wykonać się przy przeciążeniu, lecz nie może naruszać najbardziej krytycznego IRQ. Jeśli niskie zadanie trzyma mutex potrzebny wysokiemu, priority inheritance zmniejsza klasyczne priority inversion, ale nie naprawia długiej operacji w sekcji krytycznej.

FreeRTOS task notification lub atomowy licznik może przekazywać heartbeat. Event group z jednym bitem na zadanie wymaga ostrożności: zadanie może ustawić bit wielokrotnie, a monitor widzi tylko jeden; po skasowaniu łatwo powstaje wyścig. Licznik i deadline są bardziej informacyjne.

Monitor uwzględnia tryb startu i kalibracji. GNSS nie jest wymagany do postępu rate loop, a logger może nie działać przed zamontowaniem pamięci. Lista krytycznych funkcji jest funkcją stanu, ale przejścia tej polityki muszą być testowalne i jawne.

Monitor bare-metal#

W superloop każdy moduł ma ograniczoną maszynę stanów i nigdy nie czeka bez timeoutu. Główna iteracja zwiększa licznik dopiero po przejściu wszystkich wymaganych etapów.

read_due_inputs()
run_estimator_if_ready()
run_control_if_due()
publish_actuators()
service_comms_budgeted()
supervisor_check_and_refresh()

Przerwania ustawiają zdarzenia i przenoszą krótkie porcje danych. Pętla nie może utknąć na while (!(SPI->SR & DONE)). Każdy sterownik ma stan, deadline i recovery.

Watchdog nie powinien być odświeżany po każdym obrocie superloop, jeśli obrót nie wykonał rate loop z powodu zamrożonego znacznika czasu. Sprawdza się postęp niezależnego timera, nową próbkę i publikację aktuatorów.

Liveness, deadline i plausibility#

Liveness odpowiada „czy zadanie coś kończy”. Deadline odpowiada „czy kończy na czas”. Plausibility odpowiada „czy wynik może być poprawny”. Przykładowy IMU wymaga:

wzrostu licznika próbek;
wieku próbki poniżej limitu;
prawidłowego statusu FIFO i CRC, jeśli dostępne;
wartości skończonych i w zakresie sensora;
wiarygodnego dt;
zgodności konfiguracji rejestrów;
porównania z drugim sensorem, jeśli istnieje.

Nie każdy błąd plausibility powinien zatrzymać refresh MCU. Awaria jednego IMU przy działającym drugim prowadzi do izolacji sensora. Brak postępu całego toru od wejścia do wyjścia może uzasadniać reset.

End-to-end monitor jest cenniejszy od samych heartbeat zadań. Numer próbki IMU przechodzi przez estymator i kontroler do rekordu wyjścia. Jeśli każde zadanie „żyje”, ale kolejka między nimi jest zamrożona, brak nowej generacji na końcu ujawni awarię.

Hierarchia recovery#

Recovery zaczyna się od najmniejszej domeny:

ponów pojedynczą transakcję po przejściowym błędzie;
zresetuj peryferium MCU i wyczyść jego DMA/FIFO;
zresetuj konkretny sensor lub jego szynę zasilania;
przełącz się na redundantny sensor;
uruchom tryb zdegradowany/failsafe;
zresetuj MCU;
użyj zewnętrznego power-cycle, jeśli przewidziano.

Każdy poziom ma limit prób i backoff. Nieskończone restartowanie I²C co milisekundę może zająć CPU bardziej niż sama awaria. Licznik recovery jest częścią health.

Reset peryferium wymaga przywrócenia całego kontraktu: zegara, GPIO, DMA, przerwań, rejestrów sensora, filtrów i generacji timestampów. Samo wyzerowanie bitu enable często pozostawia aktywny CS albo stary callback.

Jeżeli recovery zmienia źródło danych, estymator musi wiedzieć o skoku bias i orientacji. „Przezroczyste” przełączenie dwóch IMU bez reinitializacji kowariancji może być groźniejsze od krótkiej przerwy.

Reset nie jest stanem bezpiecznym#

W czasie resetu GPIO wracają do stanów wejściowych lub domyślnych. Wyjścia ESC/serw mogą pływać, zatrzymać się albo przyjąć poziom interpretowany jako komenda. Zewnętrzne pull-down/up i protokół aktuatora definiują bezpieczny stan niezależny od firmware.

ESC powinien mieć własny timeout ważności poleceń. Po braku nowych ramek przechodzi do zdefiniowanego zachowania. Nie wolno zakładać, że ostatnia komenda zniknie wraz z resetem FC.

Bootloader może przez setki milisekund nie sterować wyjściami. Inicjalizacja najpierw ustawia bezpieczne GPIO, waliduje reset cause i sensory, a dopiero potem zezwala na generowanie aktuatorów. Arm state nie jest zachowywany automatycznie przez reset.

W locie ponowne automatyczne uzbrojenie po reboocie jest decyzją systemową o dużym ryzyku. W małym cywilnym UAV często bezpieczniejsze jest pozostanie rozbrojonym/failsafe. Jeśli wymagania przewidują kontynuację, potrzebny jest osobny, zweryfikowany supervisor aktuatorów i jednoznaczna rekonstrukcja stanu.

Reset reason i crash record#

Na samym początku boot zapisuje się rejestry przyczyny resetu, zanim kod inicjalizacyjny je skasuje. Typowe flagi obejmują power-on, brownout, pin reset, software reset, IWDG, WWDG i low-power.

Minimalny crash record w backup SRAM lub wydzielonej stronie nieulotnej może zawierać:

magic + version + CRC
boot_counter
reset_flags
last_supervisor_reason
last_task_id / progress counters
fault registers + PC/LR/SP
system_state / armed flag
monotonic timestamp if available

Rekord ma stały rozmiar i prosty CRC. Zapisywanie pełnego logu do flash w chwili awarii jest ryzykowne: erase trwa długo, stos może być uszkodzony, a napięcie spadać. Early-warning zapisuje tylko przygotowane wcześniej atomowe dane.

Flash ma ograniczoną trwałość. Licznik bootów wykorzystuje wear leveling, backup registers albo journal. Uszkodzony rekord jest ignorowany po sprawdzeniu magic/version/CRC, nie blokuje startu.

Po uruchomieniu dane trafiają do blackboxa i telemetrii. Flagi resetu czyści się dopiero po ich skopiowaniu. Inaczej drugi reset utraci historię pierwszego.

HardFault i early warning#

Handler wyjątków powinien działać bez heap, printf i zależności od RTOS. Kopiuje stacked registers, SCB fault status i minimalny kontekst do przygotowanego obszaru. Następnie pozwala watchdogowi zresetować system albo wywołuje kontrolowany reset zgodnie z polityką.

Nieskończona pętla w HardFault z odświeżaniem watchdoga jest błędem. Pętla bez refresh jest dopuszczalna, jeśli wyjścia już osiągnęły bezpieczny stan, a watchdog zapewni reset.

Early-warning interrupt watchdoga nie może zakładać sprawnego schedulera. Ma wysoki, ale przemyślany priorytet, nie używa mutexów i zapisuje kilka słów. Jeżeli flash jest zajęta albo napięcie niskie, pomija zapis zamiast przedłużać hazard.

Fault handler nie może wiarygodnie kontynuować lotu po dowolnym memory fault. Izolowane błędy urządzeń obsługuje się wcześniej; wyjątek CPU zwykle kończy się bezpiecznym resetem.

Boot loop#

Stała awaria może powodować cykl boot–watchdog–boot. System prowadzi licznik resetów w oknie czasu. Po przekroczeniu progu wchodzi w maintenance/safe boot:

aktuatory pozostają nieaktywne;
minimalne sensory i komunikacja serwisowa są uruchamiane;
ostatnia konfiguracja może zostać zastąpiona wersją znaną jako dobra;
automatyczna aktualizacja i ciężkie moduły są wyłączone;
powód jest wyraźnie sygnalizowany.

Licznik nie może rosnąć wiecznie po każdym normalnym power cycle. Zeruje się po dostatecznie długiej stabilnej pracy albo kontrolowanym poleceniu serwisowym.

Safe boot nie powinien ukrywać problemu przez natychmiastowe kasowanie logu. Portal serwisowy pokazuje łańcuch reset reasons i moduł, który nie zgłosił postępu.

Rollback firmware wymaga dwóch slotów albo innej atomowej strategii. Watchdog potwierdza nowy obraz dopiero po osiągnięciu kamienia milowego boot i stabilnej pracy, nie natychmiast po skoku do aplikacji.

Watchdog urządzeń peryferyjnych#

MCU może działać, gdy sensor, modem lub transceiver jest zawieszony. Każdy driver ma deadline transakcji, licznik świeżości danych i własną maszynę recovery.

Przykłady:

I²C stuck SDA: impulsy SCL, STOP, reset domeny z limitem;
SPI IMU: timeout DMA, CS high, reset peryferium, WHO_AM_I i pełna rekonfiguracja;
UART GNSS: brak poprawnej ramki, reset parsera, następnie modułu;
CAN bus-off: log błędu, backoff, restart kontrolera, degradacja;
karta SD: anulowanie loggera bez blokowania rate loop.

Watchdog komponentu odróżnia brak nowych danych od braku zmian wartości. Dron nieruchomy może mieć prawie stały akcelerometr, ale licznik próbek i timestamp nadal rosną.

Reset urządzenia nie może zablokować wspólnej magistrali ani odciąć zasilania sensorowi redundantnemu. Domeny recovery powinny odpowiadać domenom sprzętowym.

Brownout i zegary#

Przy zapadzie napięcia MCU może wykonywać błędny kod przed resetem, jeśli brownout threshold jest źle ustawiony. BOR powinien zadziałać powyżej napięcia, przy którym CPU, flash i peryferia tracą gwarancje, z uwzględnieniem tolerancji i szybkości opadania.

Watchdog nie zastępuje BOR. Może nie zdążyć albo sam pracować poza zakresem. Po resecie brownout system nie uzbraja się, dopóki napięcie nie jest stabilne i przyczyna nie zostanie zapisana.

IWDG z niezależnym LSI pomaga przy utracie PLL/HSE. Jednak oprogramowanie powinno mieć clock security/fallback, jeśli MCU go oferuje, oraz mierzyć błędy zegarów. Zatrzymanie SysTick może sprawić, że software timeout oparty na tym samym zegarze nigdy nie upłynie; sprzętowy niezależny licznik przełamuje tę wspólną przyczynę.

LSI ma szeroką tolerancję. Timeout oblicza się dla najszybszego LSI, aby nie resetował poprawnego kodu, oraz najwolniejszego, aby znać maksymalny czas detekcji. Kalibracja może poprawić typową wartość, ale projekt bezpieczny nie zależy wyłącznie od jednego pomiaru fabrycznego.

Debugowanie#

Debugger zatrzymujący rdzeń tworzy konflikt z aktywnym watchdogiem. MCU może oferować freeze bit dla IWDG/WWDG w debug. Jego zachowanie zależy od rodziny i opcji, a produkcyjna konfiguracja nie powinna przypadkiem pozostawić watchdoga wyłączonego.

Trzy tryby testowe są użyteczne:

watchdog zamrożony przy halt — wygodne debugowanie kodu;
watchdog aktywny — test rzeczywistego resetu bez breakpointów;
sztuczny provider refresh — tylko dla testów modułowych z wyraźnym oznaczeniem.

Breakpoint przed refresh przy aktywnym IWDG wywoła reset i może wyglądać jak niestabilność debuggera. Startup odczytuje reset cause, więc przyczyna pozostaje jednoznaczna.

Log przez UART w krytycznym monitorze może sam zmienić timing i ukryć lub stworzyć błąd. Stosuje się trace buffer w RAM, hardware cycle counter i odczyt po resecie.

Wstrzykiwanie awarii#

Watchdog, którego nie wyzwolono w teście, jest tylko założeniem. Kontrolowane testy na stanowisku obejmują:

nieskończoną pętlę w każdym krytycznym zadaniu;
deadlock dwóch mutexów;
wyłączenie przerwań na czas przekraczający budżet;
zamrożenie licznika postępu przy działającym schedulerze;
zalanie przerwaniami i pełne RX FIFO;
brak completion DMA;
zatrzymanie lub zmianę zegara głównego;
reset w trakcie zapisu konfiguracji;
brownout o różnych zboczach;
uszkodzony crash record i pełną pamięć logu;
kolejne resety prowadzące do safe boot;
awarię zewnętrznego supervisora/heartbeat.

Dla każdego przypadku mierzy się czas detekcji, stan wyjść, reset cause, czas boot, tryb po restarcie i kompletność rekordu. Test powinien wykazać, że żaden sterownik nie odświeża watchdoga poza supervisorem.

Hardware-in-the-loop obserwuje sygnały aktuatorów podczas resetu. Test software-only nie pokaże pływającego pinu ani zachowania ESC po utracie ramek.

Fault injection jest wbudowane pod flagą testową niedostępną w normalnym interfejsie operacyjnym. Każdy scenariusz ma identyfikator zapisany przed aktywacją, aby odróżnić oczekiwany reset od nowej usterki.

Metryki eksploatacyjne#

System zapisuje mały zestaw liczników, który pozwala wykryć pogarszanie jeszcze bez resetu:

minimalny/maksymalny zapas do deadline monitora;
najdłuższy czas wykonania krytycznych zadań;
liczba deadline miss i watchdog near-miss;
restarty urządzeń według przyczyny;
IWDG/WWDG/BOR/software reset;
liczba boot-loop i wejść safe boot;
wiek najstarszych wymaganych danych;
stan heap/stack watermark, jeśli używane;
maksymalna długość kolejek i overflow.

Near-miss jest ważny: watchdog z timeoutem 500 ms nie zadziała przy regularnych blokadach 450 ms, choć sterowanie jest już niedopuszczalne. Deadline monitor daje wcześniejszy sygnał.

Liczniki są nasycane albo wystarczająco szerokie. Przepełnienie licznika heartbeat nie może zostać uznane za brak postępu. Timestampy porównuje się arytmetyką odporną na wrap.

Telemetria nie wysyła każdej próbki monitora. Agreguje maksima i zdarzenia, a blackbox przechowuje szczegóły wokół fault.

Lista projektowa#

Watchdog ma niezależne źródło zegara tam, gdzie wymaga tego analiza awarii.
Timeout policzono dla skrajnej częstotliwości watchdoga i worst-case runtime.
Refresh wykonuje jeden supervisor po dowodzie postępu end-to-end.
Flagi „alive” są licznikami/timestampami, nie bitami ustawionymi raz.
Lista wymaganych funkcji zależy jawnie od trybu systemu.
Peryferia mają własne deadline i ograniczone recovery.
Każdy poziom recovery ma limit, backoff i licznik.
Wyjścia aktuatorów są bezpieczne sprzętowo podczas resetu.
ESC/serwa mają określone zachowanie po utracie poleceń.
Reset cause jest kopiowany przed skasowaniem flag.
Crash record ma magic, wersję, CRC i stały rozmiar.
Boot loop prowadzi do maintenance, nie do nieskończonego uzbrajania.
BOR i clock failure są analizowane oddzielnie od watchdoga.
Debug freeze nie zmienia konfiguracji produkcyjnej.
Testy wstrzykują deadlock, IRQ lock, DMA hang, brownout i restart sensorów.
HIL mierzy rzeczywisty stan wyjść przez cały reboot.

Powiązane tematy#

Przypisy#

STMicroelectronics, Getting started with watchdog timers — rozróżnienie WWDG/IWDG, zegary, okno i podstawy konfiguracji.
STMicroelectronics, STM32H743/753 documentation — dokumentacja rodziny MCU używanej w kontrolerach lotu; szczegóły resetów, watchdogów i fault status należy wiązać z konkretną rewizją.
FreeRTOS, Kernel books and reference manuals — scheduler, priorytety, mutexy i mechanizmy komunikacji zadań.
PX4, PX4 Autopilot source repository — referencyjny kod otwartego autopilota i przykłady nadzoru podsystemów.

Utworzono: 15 sierpnia 2026. Ostatnia aktualizacja: 15 sierpnia 2026. Źródła zweryfikowano: 15 sierpnia 2026.

Źródła z centralnego rejestru

STMicroelectronics: Getting started with watchdog timers [dokumentacja producenta]
STMicroelectronics: STM32H743/753 documentation [producent]
FreeRTOS Reference Manual [dokumentacja projektu]
PX4 Autopilot source repository [repozytorium open source]