Zde najdete naše technické články a bulletiny, o našich konstrukcích a výrobcích, a také o chybách, kterých je dobře se příště vyvarovat.

Tipy pro návrh vestavných systémů s MCU a FPGA: poučení z vlastních chyb

Komunikace MCU s FPGA v naší aplikaci probíhá jednak přes rozhraní SPI, jednak je FPGA připojen k paměťové sběrnici procesoru (AD+řízení). FPGA (RAM-based) se konfiguruje buď procesorem anebo z paměti flash přes jednobitové rozhraní SPI. Po nahrání firmware a parametrů pro jednotlivé bloky je FPGA připraveno k činnosti. To sice přináší skvělou možnost konfigurovat FPGA až "v poli" a případně i aktualizovat firmware, ale zato je zde riziko nestability celého systému.

Jelikož činnost FPGA probíhá relativně nezávisle na procesoru, vzniká otázka, jestli za všech myslitelných situací celý systém dokáže „ustát“ případné chybové události a jejich kombinace. Zde je několik opatření, která jsme provedli pro zajištění stability celého systému, včetně jeho připojení k internetu pro diagnostiku . Nedávno v [1] vyšel článek, v němž jsou podobné zásady doporučeny a diskutovány. My jsme je ještě doplnili o sledování FPGA.

-          Po zapnutí /resetu by se měl provést test celé paměti RAM a dalších hardwarových prostředků, přinejmenším kontrolou jejich registrů.

-          Paměť ROM by měla mít známý obsah (včetně nepoužité části) a měla by být chráněna kontrolním součtem. Během hlavního programu by se tato kontrola měla periodicky opakovat.

-          Samotná aplikace po nabootování z ROM / flash disku by se měla sama zkontrolovat a validovat. V aplikaci by neměly být nadbytečné kusy kódu, které se nepoužívají, ale jsou potenciálně nebezpečné.

-          Programování FPGA by mělo kontrolovat programovací data (kontrolní součet) a jejich počet vůči stavovým signálům programovacího rozhraní (např. DONE).

-          Při běhu aplikace by měl být kontrolován zásobník, tedy obsah stack-pointeru, a rovněž dalších ukazatelů na dynamické datové struktury a jejich vrchol. Článek [1] radí vůbec nepoužívat dynamické datové struktury, ale podle našich zkušeností u internetových aplikací to prostě nejde splnit. Stejně tak by měl být monitorován stav FPGA a případných podřízených procesorů, například jestli nedochází k nebezpečnému přiblížení ke konci časového „okna“ přiděleného běhu periodicky spouštěné úlohy. Doporučuje se periodicky sbírat a zaznamenávat diagnostická data, například o relativní chybovosti.

-          Činnost hlavního procesoru by měla být monitorována obvodem watch-dog nebo dohledovým „utility“ -procesorem. Obsluha „hlazení“ watch-doga musí být prováděna hlavní smyčkou programu, tou, co má nejnižší prioritu. Pokud se hlavní program z jakékoli příčiny „zasekne“, přestane „hladit“ psa, ten se probudí a systém resetuje. Obvod dohledu musí být robustní, necitlivý na stejné vlivy jako hlavní procesor.

-          Všechny vstupy musejí být ošetřeny. Nepoužívané signálové či přerušovací vstupy musejí být spolehlivě přitaženy do neaktivní úrovně. Vlna přepětí v síti nebo atmosférický výboj může jinak spustit nečekanou reakci. Imunitu proti těmto rušením je třeba ověřit.

-          Jednou z příčin chyb je i výpadek napájení, který nastane nečekaně. U nezálohovaných systémů je třeba mít časný detektor výpadku napájení, který umožní pod nemaskovatelným přerušením „uklidit“ všechny důležité informace na disk, zavřít soubory a zastavit systém v očekávání resetu od výpadku napájení anebo od watch-doga.

-          Doporučuje se zálohovat připojení k internetu ještě lokální pamětí nezávislou na napájení, například flash-diskem, a do této paměti zapisovat stavové informace při významných událostech v životě systému, například resety, výpadky napájení, chyby komunikace, navázání a ukončení spojení, zavírání souborů a jiné singulární situace.

Závěr:

Jsme přesvědčeni vlastní zkušeností, že aplikace těchto pravidel dá programátorům mnohem víc práce, než se na počátku vývoje zdá, ale tato práce se rozhodně vyplatí. Co se může pokazit, to se určitě pokazí, a dvojnásob to platí u internetových aplikací. Poslední pravidlo zní KISS. Keep it simple and stupid.

Odkaz: [1] Beningo, J.: 7 Tips for creating a reliable embedded system. www.EDN.com , Feb. 24, 2015.