STM32F100 a watchdog

Ahoj, mám prosbu. Lze nějak vypnout watchdog timer v MCU, pokud je už jednou spuštěný? Mě se to nějak nedaří a někde na netu jsem se dočetl, že to ani nejde…má někdo zkušenost?
Můj problém je ten, že když procesor přejde do režimu Stop mode a ještě před probuzením dojde WDT, MCU se resetuje…to mě dost prdí. Dík.

Myslím že to nejde vypnout, z pochopitelných důvodů. Pokud se periodicky probouzíš z režimu STOP, prodluž periodu (občerstvi watchdog) těsně před přechodem do toho režimu.

Periodické probouzení jsem neměl v plánu, ale lepší varianta asi není.
Jen dotaz…Co je v tomto případě pochopitelný důvod? Já to totiž nechci :smiley:

Důvod je “selhání aplikace” , takže když už se WDT spustí , tak ani nechtěné přepsání registru při nejakém kolapsu progrramu ho již nezastaví a skončí to resetem. Takových jednosměrných věcí je v STM32 více, namátkou zamykání konfigurací pwm, portů atd…
A opravdu WDT pořebuješ ? Mě se STM nikdy nekouslo a to jsme mu pěkně EMC zatopili, nebo si nevěříš jako programátor ? :wink:

Tohle není otázka tak úplně na místě (a v „éteru” se nevyskytuje jenom EMC), rozhodně je lepší když se jako programátor naučí WDT správně používat, než když se na to vykašle a obejde to, a jednou ho bude opravdu potřebovat a pak bude v pasti. Neznám přesně STM32, ale pokud nejde WDT po aktivaci už vypnout tak bych mu aspoň nějak rozumně prodloužil periodu (tedy pokud je ta možnost).

Máš na mysli něco konkréntního ?

Někdy je totiž lepší mít tohle ošetřeno už při návrhu elektroniky a desky než to pak léčit resetem od WDT. Znám spoustu situací kde by to client neakceptoval.

Používání WDT je samozřejmě v pořádku, ale někdy jeho použití dost koliduje se zamýšleným designem SW (viz. hazardrok) STM32 (army obecně) mají i jiné nástroje na podchycení selhání programu - hardfault, memory protect, usage fault a podobné nemaskovatelné vektory přerušení kde je možné lecos pořešit nebo poslat cpu do resetu.

Ano, měl jsem na mysli různé částice různých záření (i těch tvrdších), není jich zas tak úplně nejmíň a každou krabičku nemůžeme zabalit do pár kil olova… ale to není to až tak podstatné, podstata sdělení byla spíš v tom, že WDT je pojistka právě proti těm věcem, co jsme v návrhu ošetřit nedokázali (nebo třeba z různých důvodů ani nemohli).

V době, kdy se běžně používaly PCčka s 1-2GB RAM jsem někde četl článek (bohužel nemám link, už je to pár let), kde se pojednávalo o tom, že právě v tom 1GB RAM se vlivem různých okolností samovolně změní jeden bit průměrně za 1,5 hodiny (řešili to v tom článku proto, že to bylo pojednání o tom, jaký význam má ECC). Většinou to nevadí, ale je z toho celkem jasné, že když to bude nějaký “lucky” bit, tak to může vést k různým neočekávaným věcem. Tato problematika se týká i nás embedďáků, s tím že my tam to ECC bohužel ani nemáme. Sice máme těch bitů v součtu o dost míň, ale pořád nějakou jakoukoliv poruchu nemůžeme úplně vyloučit (tedy umět to s WDT se může hodit).

Nemusím myslím dodávat, že čím modernější elektroniku máme k dispozici, tím je na tyhle jevy citlivější.

Náš zákazník náš pán, pokud si to tak poručí, nemá s ním v takovém případě většinou cenu o tom sáhodlouze diskutovat.

Tohle me docela pobavilo :slight_smile: … Musim rict, ze s odstupem casu si prestavam asi verit, ale nemyslim si, ze to je problem muj spis bych to definoval jako kontrol neni nikdy dost

Na druhou stranu v dnesni dobe, kdy mame NMI_Handler, HardFault_Handler, MemManage_Handler,… mozna by se nad pouzitim WDT mohlo dlouze diskutovat.
Obsluhy techto chyb, ktere umi STMko samo vyvolavat dokazou vyresit vetsinu problemu, ktere jsem zatim dokazal vytvorit napr: HardFault_Handler spolehlive odchyti pokud se cte z pameti, ktera neexistuje…pri pouziti pointeru velmi casta zalezitost, ktera vybubla klidne i nekolik let po uvolneni softwaru.

To Mahoney: O částicicích vím i o tom článku (diskutovali jsme o tom v práci). To je samozřejmě věc hustoty integrace a statistiky (ta částice může s trochou štěstí vypnout i ten WDT:-)) Něco málo o tom vím, programoval jsem v týmu soft co letěl do kosmu :wink:
V každém případě, základ je dobrý hardware.
To Hazardrock: Tak musel jsem si rejpnout :wink:
A druhý axiom je TESTOVAT, TESTOVAT, TESTOVAT , což se v dnešní uspěchané době moc nenosí…

Blýská se na lepší časy, některé nové ARM M0 to mají (STM32F0xx) - slovy výrobce: SRAM with HW parity

Hele a nemá náhodou ST32F100 ty watchdogy dva ? Ten druhej (WWDG) na rozdíl od (IWDG) žije z APB clocku, takže když jsi ve stop módu, měl by stát taky, snad…

Ano, kromě IWDG je tam taky WWDG, window watchdog. Chová se rozdílně, jelikož občerstvování WWDG musí být v určitém intervalu od-do, nelze jej resetovat kdykoliv. WWDG tedy dokáže odchytit např. i chybu typu “kus programu proběhl příliš rychle”.

Co se týká kosmických částic a pamětí v MCU, to řeší (pro domácí prostředí) norma tuším IEC 60730 (alias class B compliance). Různé selftesty MCU běžící na pozadí aplikace.

A samozřejmě je vždy mnohem lepší si EMC vyřešit řádně již na plošném spoji. Bohužel se v práci setkávám často i s tím, že v rámci cost cuttingu se neosazují ani síťové filtry. Potom když se tam při testech posílají různá síťová přepětí, procesory zdechávají. Opětovné vrácení EMI filtrů pak kupodivu pomáhá, ale zákaznická firma je tam nechce. Smutné.