Az egyik legkézenfekvőbb kérdés az, hogy engedélyezed a watchdog időzítőt 1S késleltetéssel, majd arra kéred a mikrovezérlőt, hogy aludjon 2S-re, kinyomtat valamit, majd visszatér a ciklusba. Ennek elméletileg rendben kell lennie (a wdt-nek újra kell indítania a 2 másodperces várakozást), de láttam, hogy ez problémákat okoz.

Ezenkívül néhány bootloader (nevezetesen az Optiboot bootloader az Uno-n és az újabb táblákon) ) problémákat okozhat a watchdog időzítőkkel, ami azt eredményezheti, hogy a wdt továbbra is engedélyezett marad a visszaállítás után, annak ellenére, hogy a telepítési ciklus letiltja. Először is: próbálja meg növelni a wdt időt 2S-nél nagyobbra (képesnek kell lennie a WDTO_8S elvégzésére), és ellenőrizze, hogy a probléma továbbra is fennáll-e.

SZERKESZTÉS - Az OP egy Arduino Pro Mini klón. Az Arduino Pro Mini mellékelt betöltője nem támogatja a rendszer újraindítását a WDT segítségével. Lényegében egy olyan eszközön, amelynek bootloaderje nem támogatja a WDT újraindítását, a kártya újraindul, de az időzítő / visszaállítás nem okozza a kártya folyamatos újraindítását újraindításkor. Vannak alternatív bootloaderek az Arduino táblák számára, amelyek megoldhatják ezt a problémát. Egy másik megoldás egy másik módszer használata a tábla újraindításához.

A watchdog időzítő rendszer újraindításának engedélyezése és a ciklusban történő várakozás a visszaállításig törvényes módja annak, hogy az SW visszaállítsa a µC-t, mivel a watchdog segítségével elkapja a µC helytelen viselkedését, amelyet különböző okok okozhatnak. óvintézkedéseket kell tenni a watchdog rendszer visszaállítása során, mert az összes AVR-n, amely szintén őrzőkutyával rendelkezik, megszakítja az őrzőkutyát a 0000 = 16 ms-ra beállított előmérővel a watchdog rendszer visszaállítása után is aktív marad. Ezért a programozó felelőssége, hogy törölje az MCUSR funkciót, és az ilyen állapot bekövetkezése után a lehető leghamarabb kikapcsolja a watchdog időzítőt. Mivel az .data és .bss szakaszok inicializálásához szükséges LPM rutinok hosszabbak lehetnek, mint a watchdog időkorlátja, a watchdog letiltásának kódját a .init3 szakasz ban kell elhelyezni, az MCUSR opcionálisan elmenthető a forrás későbbi visszaállításához. Itt található a következő kód:

  uint8_t mcusr_copy __attribute__ ((szakasz (".noinit"))); void disable_wdt (érvénytelen) \ __attribute __ ((meztelen)) \ __attribute __ ((szakasz (". init3")))); void disable_wdt (void) {mcusr_copy = MCUSR; MCUSR = 0x00; wdt_disable ();}  

A probléma azonban olyan bootloader használatakor merülhet fel, amely nem veszi figyelembe a watchdog rendszer visszaállításának lehetőségét. Ebben az esetben a watchdog időtúllépése a bootloaderen belül történik (amelyet először hajtanak végre), mire a fenti kódnak lehetősége van kikapcsolni a watchdog időzítőt, és a µC beragad egy végtelen visszaállítási ciklusba. Mivel a µC visszaállítása nem törli a WDRF jelölést az MCUSR regiszterben (csak szoftveresen vagy Power-on reset-rel törölhető) akkor az áramellátás megszakítása és egy új kód feltöltése lesz, amikor a watchdog időzítőt még mindig nem aktiválja az előző kód. Az MCDRR regiszterben található WDRF -t törölni kell a wdt_disable () előtt, mert a WDE nem törölhető, ha WDRF még mindig be van állítva - ezért nagyon fontos a fenti kódban szereplő utasítások sorrendje. A .init3 szakaszban elhelyezett függvényt nem szabad későbbi kódból meghívni.

Az Arduino-t ezzel a paranccsal indíthatja újra:

  asm volatile ("jmp 0");  

Az egyik megoldás az őrzők kikapcsolása az initnél. Az optiboot 8.0 verziót használom, és tökéletesen működik. (érvénytelen) {MCUSR = 0; wdt_disable (); visszatér;}