STM32 w flight controllerach

STM32 dominuje w wielu flight controllerach, ponieważ łączy rdzenie Cortex-M z szybkimi timerami, DMA, bogatym zestawem interfejsów i dojrzałym toolchainem. Oznaczenie F4, F7 lub H7 jest jednak tylko nazwą rodziny. O przydatności decyduje konkretny wariant, obudowa, ilość flash/RAM, mapowanie DMA, liczba timerów, domeny pamięci i obsługiwane peryferia.

F4, F7 i H7 bez marketingu#

Rodzina/typowy układ	Rdzeń	Cechy istotne dla FC	Typowe ograniczenie
STM32F411	Cortex-M4F do 100 MHz	FPU single, DMA, timery, mała obudowa	128 KB RAM, mniej peryferiów
STM32F405	Cortex-M4F do 168 MHz	wiele timerów/SPI/UART, 1 MB flash	brak cache, ograniczony RAM względem nowszych
STM32F7xx	Cortex-M7 do ok. 216 MHz	cache, TCM, szybszy rdzeń, więcej RAM	coherency DMA/cache
STM32H743	Cortex-M7 do 480 MHz	do 2 MB flash, rozbudowane DMA i domeny RAM	złożona mapa pamięci i zegarów

F411 może wystarczyć dla prostego kontrolera, lecz funkcje takie jak szybki Blackbox, kilka IMU, OSD, RPM filtering i rozbudowana telemetria konkurują o CPU, pamięć i DMA. H7 nie naprawi złego schedulera ani blokującego sterownika; daje większy budżet, ale wprowadza cache i bardziej złożoną architekturę magistral.

Peripherals są ważniejsze niż DMIPS#

Pętla sterowania potrzebuje deterministycznego dostarczania próbek i wyjść. SPI z DMA może pobierać IMU bez kopiowania każdego bajtu przez CPU. Timer generuje DShot/PWM z precyzyjnym czasem. UART z DMA obsługuje szybki odbiornik RC i telemetrię. SDIO/SDMMC lub SPI zapisuje log.

Tabela zasobów projektu powinna przypisać:

każdą instancję IMU do SPI, chip-select i DRDY;
wyjścia silników do timerów, kanałów i strumieni DMA;
UART-y do RC, GNSS, telemetrii i debug;
I²C do wolniejszych sensorów z planem recovery;
ADC do napięcia, prądu i RSSI z właściwym zakresem;
pamięć logu do interfejsu i bufora;
USB, CAN i SWD do konkretnych pinów.

Konflikt DMA może ujawnić się dopiero po jednoczesnym włączeniu DShot i urządzenia SPI. „Każde urządzenie działa osobno” nie jest testem całej konfiguracji.

Timery i generowanie wyjść#

Timer ma licznik, prescaler, kanały capture/compare i źródła żądań DMA. Kanały tego samego timera współdzielą częstotliwość bazową oraz część zasobów. Nie każde wyprowadzenie z funkcją TIMx_CHy nadaje się do wybranego protokołu przy zajętych alternatywnych funkcjach.

DShot jest cyfrowe, ale często generowane sprzętem PWM + DMA. Bufor określa kolejne szerokości bitów, DMA zasila rejestr compare, a timer utrzymuje timing bez jitteru kodu. Bidirectional DShot wymaga zmiany kierunku linii, pomiaru odpowiedzi i precyzyjnego okna; obciążenie zasobów różni się od zwykłego PWM.

Input capture może mierzyć impulsy lub RPM. 32-bitowy timer zmniejsza problem overflow dla długich okresów, lecz sterownik nadal musi obsługiwać zawinięcie i timeout braku impulsów.

DMA i własność bufora#

DMA przenosi dane między peryferium a pamięcią równolegle do CPU. Poprawny projekt definiuje właściciela bufora, jego długość, wyrównanie, moment gotowości i reakcję na błąd. Nadpisanie bufora przed zakończeniem transferu tworzy usterki zależne od czasu.

Typowy odbiór IMU:

DRDY zapisuje timestamp i uruchamia transakcję SPI;
DMA przesyła rejestry do bufora;
completion ISR oznacza próbkę jako gotową;
kod poza ISR skaluje i publikuje dane;
timeout wykrywa brak DRDY lub zablokowaną magistralę.

ISR powinno być krótkie. Filtracja, logowanie i protokół nie należą do przerwania DMA.

Cache, TCM i coherency#

Cortex-M7 w F7/H7 ma cache instrukcji i danych. Jeżeli DMA zapisuje RAM, CPU może nadal widzieć starą linię D-cache; jeżeli CPU zmienił bufor tylko w cache, DMA może wysłać starą zawartość pamięci. Rozwiązaniem jest umieszczenie bufora w regionie non-cacheable albo poprawne clean/invalidate wraz z wyrównaniem do linii cache.

Nie każda pamięć jest dostępna dla każdego DMA. DTCM daje niski i przewidywalny czas dla CPU, ale wybrane kontrolery DMA mogą nie mieć do niej dostępu. Linker script jest więc elementem architektury czasu rzeczywistego, nie tylko sposobem zmieszczenia sekcji.

Reguła praktyczna: dla każdego bufora DMA udokumentować region pamięci, dostęp mastera, politykę cache, wyrównanie i operacje utrzymania spójności.

Zegary i timestamp#

PLL i prescalery tworzą zegary rdzenia, AHB, APB i timerów. W STM32 timer może otrzymywać częstotliwość inną niż prosty zegar APB zależnie od prescalera. Błędne założenie daje niewłaściwy baud rate, sampling lub DShot.

System potrzebuje monotonicznego licznika o znanej rozdzielczości. Timestamp próbki powinien powstać możliwie blisko DRDY, nie po zakończeniu zmiennego przetwarzania. SysTick/RTOS tick jest często za wolny do analizy fazy pętli.

Źródło HSE ma tolerancję, startup i wrażliwość PCB. HSI umożliwia recovery, ale może nie spełnić wszystkich wymagań interfejsów. CSS i procedura błędu zegara powinny prowadzić do kontrolowanego stanu, nie do dalszego generowania wyjść z nieznaną częstotliwością.

FPU i obliczenia#

M4F przyspiesza float, M7 może oferować także double-precision zależnie od układu. Użycie double nie poprawia automatycznie estymacji, a może zwiększyć czas i pamięć. Należy mierzyć błąd numeryczny oraz wykonanie z rzeczywistymi flagami kompilatora.

DSP instructions pomagają w filtrach i operacjach wektorowych, lecz deterministyczność wymaga kontroli denormals, wyjątków i biblioteki. Optymalizacja zmieniająca kolejność działań może wpłynąć na wynik filtra; testy powinny mieć tolerancje, nie identyczność bitową bez uzasadnienia.

Watchdog, reset i brownout#

Independent watchdog korzysta z oddzielnego oscylatora i może zresetować MCU po zawieszeniu. Window watchdog wykrywa także zbyt wczesne karmienie. Watchdog ma być karmiony po potwierdzeniu krytycznych zadań, nie w przerwaniu niezależnym od kondycji aplikacji.

Po resecie firmware powinien zachować przyczynę, zapewnić bezpieczne stany pinów i nie wznowić aktuatorów bez pełnej inicjalizacji. Brownout może uszkodzić zapis flash lub SD. BOR/PVD, hold-up zasilania i atomowy format konfiguracji tworzą wspólny mechanizm odporności.

Bootloader i aktualizacja#

STM32 ma system bootloader w ROM, a FC zwykle własny bootloader w flash. Projekt partycji musi rezerwować miejsce, znać vector offset i chronić procedurę recovery. Aktualizacja powinna sprawdzać target, rozmiar, integralność oraz zgodność sprzętu.

Podwójny obraz lub rollback wymaga wystarczającej flash i atomowego znacznika stanu. Sam CRC wykrywa uszkodzenie, ale nie uwierzytelnia firmware. Dla systemu o podwyższonych wymaganiach potrzebny jest podpis, ochrona klucza i kontrola debug access.

SWD i diagnostyka#

Pady SWDIO, SWCLK, GND, 3V3 i opcjonalnie NRST powinny być dostępne. Debugger pozwala zatrzymać rdzeń, obejrzeć fault registers, stos i peryferia. UART debug jest przydatny, lecz może zmieniać timing i zawiesić się przy pełnym buforze.

HardFault handler powinien zachować co najmniej stacked PC/LR, CFSR, HFSR, BFAR/MMFAR, aktywny task i przyczynę resetu. Bez tego „losowy restart” pozostaje nieweryfikowalny.

PCB i integralność sygnału#

Szybki MCU wymaga poprawnego odsprzęgania każdego VDD, krótkiej pętli kondensatora, właściwego VCAP i ciągłej płaszczyzny masy. IMU powinno być odseparowane od przetwornicy, dużych prądów i krawędzi sygnałów silnikowych. SPI prowadzi się krótko, kontrolując return path; rezystor szeregowy przy źródle może ograniczyć ringing.

ADC mierzący baterię potrzebuje dzielnika, filtra, czasu próbkowania i kalibracji odniesienia. Nie wolno przekraczać zakresu pinu podczas transientu. USB wymaga pary różnicowej oraz ESD; CAN transceivera, terminacji i ochrony common-mode.

Dobór układu#

Dobór zaczyna się od macierzy wymagań, nie od najwyższej częstotliwości:

policzyć flash z zapasem na kolejne wydanie i bootloader;
policzyć RAM: stosy, kolejki, log, bufory DMA i estimator;
przypisać wszystkie timery, kanały DMA i piny;
sprawdzić dostępność pamięci dla DMA i cache;
zweryfikować liczbę SPI/UART/CAN/USB;
przejrzeć errata konkretnej rewizji;
ocenić obudowę, montaż, dostępność i alternatywy;
zbudować prototyp i zmierzyć WCET oraz jitter pod pełnym obciążeniem.

F405 pozostaje rozsądnym wyborem dla prostszych FC, F7 daje większy budżet i cache, a H7 obsługuje rozbudowane sensory i logowanie. Żadna rodzina nie zastępuje poprawnej alokacji zasobów.

Test kwalifikacyjny MCU/PCB#

cold/warm start przy krańcach napięcia;
test wszystkich IMU i magistral równocześnie;
DShot/PWM pod pełnym loggingiem;
przeciążenie UART i odzyskanie po błędzie;
wymuszony timeout I²C/SPI;
zapis SD i reset w trakcie zapisu;
watchdog po kontrolowanym deadlocku;
brownout i odczyt przyczyny resetu;
pomiar temperatury MCU/regulatora;
wielogodzinny log jitteru i błędów DMA;
SWD recovery po uszkodzonym obrazie.

Typowe błędy#

wybór MCU na podstawie litery F/H bez pełnego numeru;
założenie, że każdy pin timera obsłuży dowolny DShot;
bufor DMA w niedostępnej pamięci TCM;
brak clean/invalidate cache na M7;
karmienie watchdog z niezależnego przerwania;
timestamp po filtracji zamiast przy DRDY;
logowanie w ISR;
brak SWD i udokumentowanego recovery;
nieuwzględnienie errata i wariantu obudowy.

Mapa pamięci i linker#

Kod, stałe, stosy, sterty, bufory DMA i logi muszą zmieścić się nie tylko liczbowo, ale także w odpowiednich bankach. Linker script określa, gdzie trafia sekcja. Na H7 pamięci DTCM, AXI SRAM i SRAM domen mają różne właściwości oraz dostępność dla DMA.

Umieszczenie bufora w szybkiej pamięci niewidocznej dla danego kontrolera DMA daje awarię mimo poprawnego wskaźnika CPU. Z kolei duży bufor logu w pamięci o niskim opóźnieniu może niepotrzebnie wypchnąć stos krytycznej pętli. Projekt tworzy tabelę:

Obiekt	Rozmiar	Właściciel	Dostęp DMA	Cache	Czas życia
próbki IMU	stały	driver/estimator	tak	kontrolowany	ciągły
ramki DShot	mały	output driver	tak	kontrolowany	cykliczny
stos pętli	wg high-water mark	RTOS	niepotrzebny	CPU	task
log	duży	logger	SD/Flash DMA	zależny	kolejka

Stack overflow może uszkodzić sąsiednie dane i objawić się daleko od przyczyny. W buildzie testowym włącza się canary, MPU guard lub kontrolę high-water mark. Heap w ścieżce czasu rzeczywistego jest ograniczany, bo fragmentacja i nieokreślony czas alokacji utrudniają gwarancje.

Przerwania i priorytety#

NVIC umożliwia zagnieżdżanie przerwań. Numery priorytetów ARM są odwrotne intuicyjnie: niższa wartość zwykle oznacza wyższy priorytet. Liczba zaimplementowanych bitów zależy od układu. RTOS dodatkowo narzuca próg, powyżej którego ISR nie może wywoływać jego API.

ISR powinna potwierdzić zdarzenie, zapisać timestamp, zabezpieczyć minimalne dane i obudzić zadanie. Filtracja, parser oraz zapis logu należą poza przerwaniem. Długa ISR blokuje zadania o mniejszym priorytecie i może opóźnić inne peryferia.

Priorytet nie jest wybierany według „ważności funkcji”, ale deadline i skutków opóźnienia. Data-ready IMU ma mały budżet, jednak handler błędu zasilania może mieć jeszcze wyższy priorytet. Analiza obejmuje najgorszy czas i możliwość lawiny przerwań.

Timery w praktyce#

Timer ma zegar wejściowy, prescaler, licznik, kanały capture/compare i opcjonalne wyjścia komplementarne. Częstotliwość timerów może być mnożona względem magistrali APB, co jest częstym źródłem błędu. Wartość obliczona z zegara rdzenia nie musi być właściwa.

Input capture timestampuje zbocza RC lub sensora sprzętowo, ograniczając jitter ISR. Output compare generuje precyzyjne zdarzenia. DMA może dostarczyć sekwencję dla DShot bez bit-bangingu. Konflikt pojawia się, gdy dwa wyjścia wymagają tego samego kanału, requestu DMA lub pinu alternatywnego.

Zaawansowane timery mają break input i dead-time przydatne w sterowaniu mocy, ale typowy FC nadal używa zewnętrznych ESC. Nieaktywne wyjście po resecie musi mieć bezpieczny stan elektryczny; bootloader i konfiguracja GPIO nie mogą wygenerować przypadkowego impulsu.

DMA, cache i bariery#

DMA działa równolegle z CPU. Descriptor lub bufor nie może zostać zmieniony, dopóki transfer go używa. Typowy wzorzec to ping-pong: DMA zapisuje jedną połowę, CPU przetwarza drugą. Flaga completion sama nie naprawia błędnego czasu życia danych.

Na MCU z D-cache CPU może czytać starą kopię po zapisie DMA albo DMA stare dane pozostające tylko w cache. Rozwiązaniem jest pamięć non-cacheable, właściwa konfiguracja MPU albo clean/invalidate dla zaokrąglonego zakresu linii cache. Operacja na niepełnej linii może naruszyć sąsiedni obiekt, dlatego bufory wyrównuje się i izoluje.

Bariery pamięci (DMB, DSB, ISB) mają różne znaczenia. volatile wymusza dostęp kompilatora, lecz nie gwarantuje kolejności magistrali ani coherency cache. Kod sterownika powinien opierać się na dokumentacji Cortex‑M i HAL/RTOS, nie na przypadkowych opóźnieniach.

Magistrale sensorów#

SPI daje pełny dupleks i kontrolę chip-select, ale wymaga osobnej linii CS dla urządzeń. Maksymalny zegar zależy od sensora, długości ścieżek, poziomów oraz trybu CPOL/CPHA. Odczyt rejestru ID przy małej prędkości nie dowodzi poprawności burstów IMU przy docelowym zegarze.

I²C jest wygodne dla wolniejszych sensorów, lecz linia open-drain wymaga pull-up dobranego do pojemności. Zbyt słaby rezystor daje wolne zbocze, zbyt mocny zwiększa prąd. Urządzenie trzymające SDA może zablokować magistralę; driver potrzebuje timeoutu i procedury recovery.

UART obsługuje GNSS, RC i telemetrię. Każdy port wymaga budżetu bajtów, bufora pierścieniowego i polityki overflow. DMA idle-line może efektywnie odbierać zmienną długość, lecz parser musi rozdzielać ramki oraz walidować CRC.

CAN jest różnicową magistralą z arbitrażem. Wymaga transceivera, terminacji i właściwego prowadzenia pary. Sam kontroler CAN w MCU nie jest fizycznym interfejsem do przewodu.

Zegary i źródła czasu#

PLL mnoży źródło HSE/HSI do zegara systemowego. Każda domena ma limit. Błędna konfiguracja wait states Flash albo napięcia regulatora może działać w chłodnym laboratorium i zawodzić przy temperaturze. Sekwencja producenta jest wymaganiem, nie sugestią.

Dla sterowania najważniejszy jest monotonny licznik o znanej rozdzielczości. Czas UTC z GNSS może skakać i służy do datowania, a nie obliczania dt. Overflow licznika obsługuje się arytmetyką bez znaku i testuje sztucznie.

Synchronizacja PPS timestampuje krawędź timerem, zamiast obsługiwać ją wyłącznie opóźnioną ISR. Relacja między zegarem sensora, MCU i GNSS powinna być logowana. Dryft oscylatora wpływa na interwały, UART i protokoły czasu.

Reset i domeny zasilania#

Źródła resetu obejmują power-on, brownout, watchdog, pin reset, software reset i błędy bezpieczeństwa. Pierwszy kod po starcie powinien zapisać flagi, zanim zostaną skasowane. Bez tej informacji „losowy restart” jest trudny do odróżnienia od aktualizacji.

Brownout threshold musi zapewnić, że CPU nie wykonuje kodu przy napięciu poza specyfikacją. Osobne szyny analogowe, VCAP i kondensatory odsprzęgające prowadzi się zgodnie z datasheetem. Zapas regulatora sprawdza się przy zapisie Flash, aktywnym radiu i wszystkich sensorach.

Watchdog niezależny od głównego zegara chroni przed zawieszeniem, lecz odświeżanie go z jednego timera może maskować martwe zadania. Health manager zbiera heartbeat krytycznych modułów i dopiero wtedy wykonuje refresh. Po resecie wyjścia aktuatorów mają pozostać bezpieczne.

Boot i aktualizacja odporna na przerwanie#

Wbudowany ROM bootloader STM32 obsługuje interfejsy zależne od dokładnego układu i rewizji; źródłem jest AN2606. Płytka musi fizycznie udostępnić potrzebne piny oraz sposób wejścia w boot mode. Nie wolno zakładać, że każdy STM32F4 ma identyczny zestaw.

Własny bootloader weryfikuje rozmiar, kompatybilność i integralność obrazu przed skokiem. Odporna aktualizacja może używać dwóch slotów, flagi pending i rollback. Sam CRC wykrywa przypadkowe uszkodzenie, lecz nie potwierdza autora; do bezpiecznej dystrybucji potrzebny jest podpis i chroniony klucz zaufania.

VTOR, stos początkowy, tablica przerwań oraz wyczyszczenie peryferiów muszą być poprawne przy przekazaniu sterowania. Błąd ujawniający się tylko po bootloaderze, a nie po debuggerze, często wynika z pozostawionego zegara, przerwania lub cache.

Diagnostyka faultów Cortex‑M#

HardFault jest końcowym skutkiem wielu błędów. Handler powinien zachować stacked PC/LR, rejestry fault status, adres błędu, stos i identyfikator builda. Symbolizacja PC wskazuje instrukcję, ale pierwotna korupcja mogła powstać wcześniej.

BusFault może wynikać z niedostępnej pamięci lub błędu magistrali, UsageFault z nielegalnej instrukcji, dzielenia przez zero albo niepoprawnego stanu, a MemManage z MPU. Włączenie konfigurowalnych faultów daje dokładniejszą diagnozę niż eskalacja wszystkiego do HardFault.

SWD umożliwia breakpoint, watchpoint i podgląd pamięci, lecz zatrzymanie rdzenia zaburza czas rzeczywisty. Trace, liczniki DWT i log w RAM często są lepsze dla jitteru. Pinów SWD nie powinno się usuwać z prototypu; pady testowe mają znaną masę i stabilne połączenie.

Kryteria wyboru konkretnego STM32#

Wybór zaczyna się od tabeli zasobów:

liczba i typy SPI dla IMU oraz pamięci;
UART dla GNSS, RC, telemetrii i debug;
CAN/FDCAN wraz z transceiverem;
timery i requesty DMA dla wszystkich wyjść;
RAM w bankach dostępnych wymaganym masterom;
Flash z zapasem na funkcje i aktualizację;
pakiet możliwy do routingu oraz temperaturę;
dostępność w łańcuchu dostaw i dojrzałość wsparcia firmware.

F411 bywa wystarczający dla prostego kontrolera, F405 daje więcej zasobów, F7 ułatwia intensywne obliczenia i ma inną architekturę pamięci, a H7 wnosi duży zapas oraz większą złożoność cache i domen. „Najszybszy” MCU może zwiększyć ryzyko projektu, jeśli zespół nie potrafi zweryfikować coherency.

Plan bring-up płytki#

Zmierzyć szyny i reset bez MCU wykonującego aplikację.
Połączyć SWD i odczytać IDCODE.
Uruchomić minimalny zegar z HSI oraz GPIO diagnostyczne.
Zweryfikować HSE/PLL i wszystkie częstotliwości timerem lub MCO.
Testować peryferia pojedynczo przy małych prędkościach.
Sprawdzić ID sensorów, następnie ciągły transfer DMA i błędy.
Zmierzyć jitter data-ready → zakończenie pętli.
Wywołać watchdog, brownout, błąd magistrali i odzyskanie I²C.
Obciążyć równocześnie logowanie, RC, GNSS i wyjścia.
Powtórzyć przy skrajnych napięciach i temperaturze przewidzianej projektu.

Każdy test ma liczbowy limit oraz zapis wersji. Miganie LED potwierdza jedynie wykonanie pewnej ścieżki, nie poprawność kontrolera lotu.

Powiązane tematy#

Przypisy#

STM32F411 documentation — datasheet, RM0383 i errata.
STM32F405/415 documentation — RM0090, datasheet i errata.
STM32F765 product information — Cortex-M7, cache, TCM i pamięć.
STM32H743/753 documentation — RM0433, domeny pamięci i peryferia.
PM0253 — Cortex-M7 programming manual — cache, MPU, FPU i wyjątki.
AN2606 — system memory boot mode — recovery przez ROM bootloader.

Źródła z centralnego rejestru

STMicroelectronics: STM32F7 series [producent]
STMicroelectronics: STM32H743/753 documentation [producent]