Niezależny organ nadzorczy (IWDG) czy organ nadzorujący okno (WWDG)?

Wciąż szukam odpowiedzi na to pytanie:

Dlaczego chociaż MCU stm32 mają doskonały watchdog (mam na myśli Watchdoga Window (WWDG)), istnieje prosty watchdog (Independent Watchdog (IWDG))?

Znalazłem tę stronę , która powiedziała:

ST Microelectronics ma linię urządzeń Cortex-M3. M3 stał się niezwykle popularny na niższych urządzeniach wbudowanych, a STM32F ST jest reprezentatywny dla tych części (chociaż WDT jest dodatkiem ST i niekoniecznie odzwierciedla implementacje innych dostawców). STM32F ma dwa różne mechanizmy ochronne. „Independent Watchdog” to dość waniliowy projekt, który nie ma wiele do zaoferowania poza łatwością użycia. Ale ich Windows Watchdog zapewnia bardziej niezawodną ochronę. Po upływie czasu odliczania generowany jest reset, który może być utrudniony przez ponowne załadowanie timera. Nic specjalnego. Ale jeśli przeładowanie nastąpi zbyt szybko, system również się zresetuje. W tym przypadku „zbyt szybko” jest określane przez wartość, którą program wprowadza do rejestru sterującego.

Kolejna fajna funkcja: może wygenerować przerwanie tuż przed resetowaniem. Napisz trochę kodu, aby złapać przerwanie i możesz podjąć pewne działania, na przykład, aby ustawić system w bezpiecznym stanie lub wykonać migawkę danych w celu debugowania. ST sugeruje użycie ISR do przeładowania watchdoga - to znaczy, wykop psa, aby reset nie nastąpił. Nie słuchaj ich rad. Jeśli program się zawiesi, programy obsługi przerwań mogą równie dobrze nadal działać normalnie. A użycie ISR do ponownego załadowania WDT unieważnia cały powód działania strażnika okien.

a to :

Nowa seria procesorów STM32F4 Cortex ™ -M4 firmy STMicroelectronics ma dwa niezależne organy nadzorujące. Jeden działa z własnego wewnętrznego oscylatora RC. Oznacza to, że wszystkie rodzaje rzeczy mogą się zawalić w procesorze, a WDT nadal będzie działać. Istnieje również „strażnik okien” (WWDT), który wymaga, aby kod często go łaskotał, ale niezbyt często. Jest to bardzo skuteczny sposób na zapewnienie, że rozbity kod, który losowo zapisuje się w mechanizmie ochronnym, nie powoduje łaskotania WDT, a WWDT może wygenerować przerwanie krótko przed potwierdzeniem resetu.

ok, spójrzmy do podręcznika :

STM32F10xxx ma dwa wbudowane urządzenia peryferyjne typu watchdog, które oferują połączenie wysokiego poziomu bezpieczeństwa, dokładności pomiaru czasu i elastyczności użytkowania. Oba urządzenia peryferyjne watchdog (niezależne i Window) służą do wykrywania i usuwania usterek spowodowanych awarią oprogramowania oraz do wyzwalania resetu systemu lub przerwania (tylko watchdog okna), gdy licznik osiągnie określoną wartość limitu czasu. Niezależny organ nadzorujący (IWDG) jest taktowany przez własny dedykowany zegar niskiej prędkości (LSI), dzięki czemu pozostaje aktywny nawet w przypadku awarii głównego zegara. Zegar watchdoga (WWDG) jest wstępnie przeskalowany z zegara APB1 i ma konfigurowalne okno czasowe, które można zaprogramować w celu wykrycia nienormalnie późnego lub wczesnego działania aplikacji. IWDG najlepiej nadaje się do aplikacji, które wymagają, aby watchdog działał jako całkowicie niezależny proces poza główną aplikacją, ale mają niższe ograniczenia dokładności pomiaru czasu. WWDG najlepiej nadaje się do aplikacji, które wymagają, aby strażnik zareagował w dokładnym oknie czasowym.

Watchdog okna służy do wykrywania wystąpienia błędu oprogramowania, zwykle generowanego przez zakłócenia zewnętrzne lub nieprzewidziane warunki logiczne, które powodują, że program aplikacji porzuca normalną sekwencję. Obwód watchdog generuje reset MCU po upływie zaprogramowanego okresu czasu, chyba że program odświeży zawartość zliczania, zanim bit T6 zostanie skasowany. Reset MCU jest również generowany, jeśli 7-bitowa wartość zliczania w dół (w rejestrze kontrolnym) zostanie odświeżona, zanim zliczacz osiągnie wartość rejestru okna. Oznacza to, że licznik musi zostać odświeżony w ograniczonym oknie.

Jak widać, żaden z nich nie powiedział, że Dlaczego nie ma dwóch watchdog. jeśli zapytam, jakie są różnice między oboma organami nadzorującymi, policzysz wszystkie funkcje, które widzisz powyżej, a jeśli chcesz porównać oba, oczywiście strażnik systemu Windows (WWDG) będzie zwycięzcą! to dlaczego są dwa stróżujące?

Chcę wiedzieć, kiedy powinienem używać IWDG, a kiedy WWDG?

i czy jest jakiś powód, który mówi nam, dlaczego nazywają drugi zegarek o tej nazwie -> „Watchdog okna”?

Zwykłe zegary nadzorujące muszą zostać zresetowane w pewnym momencie, zanim upłynie limit czasu. Jeśli masz WDT 100 ms, możesz go zresetować co 99,9 ms lub co 10us i nigdy nie przekroczy limitu czasu.

Zegary kontrolne okna mają okno czasowe, w którym należy je zresetować. Jeśli zresetujesz go za wcześnie lub za późno (od poprzedniego resetu) spowoduje to zresetowanie procesora.

Celem, jeśli nie jest to oczywiste, jest pomoc w zapewnieniu, że kod resetujący WDT jest kodem zamierzonym, działającym w zamierzony sposób. Jakiś nieprzewidziany stan, który generuje resety WDT o wysokiej częstotliwości, nie uniemożliwi resetowania systemu.

Uruchomienie WDT z zegara systemowego może być pewnym problemem - jeśli zegar zawiedzie i jeśli nie będzie niezależnego obwodu monitora zegara, mogą się zdarzyć złe rzeczy. Niezależny zegar dla WDT oznacza, że ​​gdyby rzecz z jakiegoś powodu zaczęła działać z prędkością 1/10, WDT zresetuje się (ale okno WDT nie uruchomi się).

Użyj obu, jeśli możesz.

Jak mówi strona, resetowanie WDT za pomocą ISR jest ogólnie złe juju (ale może być do zaakceptowania, jeśli ISR ​​sprawdzi, czy reset oprogramowania układowego działa przed zresetowaniem timera).

Tekst wklejony do pytania zawiera odpowiedzi, których potrzebujesz.

1. Korzystasz z IWDG, gdy potrzebujesz prostego watchdoga lub gdy potrzebujesz całkowicie niezależnego watchdoga - IWDG ma swój własny zegar, WWDG wyprowadza swój zegar z jednego z zegarów magistrali - jeśli zawiedzie lub oprogramowanie wyłączy się, wtedy watchdog umiera.
2. Używasz WWDG, gdy potrzebujesz watchdoga, który można zresetować tylko w określonym przedziale czasu (okno). Jeśli twoje oprogramowanie resetuje WWDG zbyt późno, wówczas WWDG wyłączy reset procesora. Jeśli twoje oprogramowanie zbyt wcześnie resetuje WWDG, spowoduje to również zresetowanie procesora.

Nazywa się to „watchdogiem okna” z tego prostego powodu, że tylko resetowanie watchdoga w określonym przedziale czasu (okno możliwości) zapobiegnie zresetowaniu go przez procesor.

Obaj wykonują podobne prace, ale wykonują je inaczej. To, czego potrzebujesz, zależy od wymagań, które musisz spełnić.

Jest jeszcze jeden powód, dla którego należy korzystać z watchdoga okna, zamiast lub jako dodatek do niezależnego watchdoga. WWDG ma przerwanie, które możesz podpiąć. Oznacza to, że jeśli kod dostanie się w pętlę lub fugę, możesz ustawić punkt przerwania w WWDG ISR i pracować wstecz, aby dowiedzieć się, co robi oprogramowanie układowe, gdy pies szczeka.

Nie możesz tego zrobić za pomocą IWDG. Jak sama nazwa wskazuje, jest to niezależne od procesora. Zamiast wywoływać przerwanie, po prostu zapewnia i dezertuje / RESET - co nie daje wielu wskazówek, dlaczego szczeka. Zdecydowanie sugeruję ustawienie WWDG w ramach normalnych parametrów pracy, a także IWDG na znacznie dłuższy okres, być może maksymalnie 2 * WWDG. Utwórz funkcję kick-dog, która kopie oba. W ten sposób IWDG szczeka tylko wtedy, gdy blokuje się WWDG, jako ostateczna kopia zapasowa.

Moje zdanie na ten temat:

Używaj obu jednocześnie, ponieważ szukają różnych nieudanych warunków:

Te niezależne Watchdog (IWDG) timera należy zresetować ciągle przed nim czas na zewnątrz. W praktyce możesz po prostu dodać kod resetowania wszędzie tam, gdzie masz prawidłowy stan programu, lub jeden raz w głównej pętli, jeśli masz główną pętlę, która powinna być wykonywana często bez większych opóźnień. W ten sposób, jeśli twoje wezwanie do zresetowania timera (jest to czasami nazywane „pieszczeniem”, „łaskotaniem lub po prostu„ resetowaniem ”„ psa stróżującego ”) nie pojawia się na czas, oznacza to, że Twój kod A) przypadkowo utknął gdzieś nie przewidziałeś --- jakiś nieprzewidziany stan nieskończonej pętli lub B) celowo utknął gdzieś narzucony przezassert()wywołanie funkcji z osadzoną nieskończoną pętlą, do której ma przejść kod, gdy jakiś ważny warunek nie jest spełniony. Zatem teraz, gdy warunek potwierdzenia jest fałszywy, kod celowo utknął w nieskończonej pętli, a watchdog resetuje mikrokontroler, aby przywrócić go do prawidłowego stanu. Należy również zauważyć, że „niezależny organ nadzorujący (IWDG) jest taktowany przez własny dedykowany zegar niskiej prędkości (LSI), a zatem pozostaje aktywny nawet w przypadku awarii głównego zegara” (patrz ST RM0008 Reference Manual p493 ).

Wydaje mi się jednak, że licznik czasu programu Window Watchdog (WWDG) nie jest przeznaczony do wyszukiwania przypadków opisanych powyżej (gdzie Twój kod jest niechcący lub umyślny [przez aser] gdzieś się „zacina”), ale bardziej szczegółowo w przypadku, gdy A) Twój kod NIE wykonuje czegoś, co powinien . Innymi słowy, ma błąd, który powoduje, że jego główna pętla lub inna podsekcja kodu wykonuje się zbyt szybko (lub zostaje całkowicie pominięta), więc zbyt wcześnie resetujesz watchdoga poza jego oknem, a mcu zostaje zresetowane. Lub B)innym warunkiem, który może wykryć, jest nieudana konfiguracja timera. Być może resetujesz go w ustalonym odstępie czasu, ale twój licznik użyty do utworzenia tego przedziału albo przypadkowo zmienia konfiguracje gdzieś, gdzie nie powinien, albo źle go konfigurujesz, wtedy przedział czasowy będzie wyłączony, twój ustalony reset przedziałów czasowych wyzeruje WWDG poza jego oknem (albo za wcześnie, albo za późno), a mcu zostanie zresetowany, aby powiadomić cię i / lub naprawić warunek.

To jest moje zdanie na ten temat. Myśli i opinie są mile widziane.

„okienkowy” organ nadzorczy jest zwykłym organem nadzorującym, który chroni niektórych przed jeszcze gorszymi praktykami programowania. Jak inni powiedzieli, masz „ramy czasowe”, które zazwyczaj można regulować w miejscu, w którym należy dostarczyć „paszę”.

Żaden z nich nie jest kuloodporny, jeśli Twój kod może wejść w automatycznie podtrzymywaną pętlę. Na przykład. Jeśli planujesz „feed” w oparciu o IRQ związane z timerem, może to być bardzo zła praktyka, ponieważ twój kod może utknąć w pewnym do / podczas wątku pocztowego, podczas gdy przerwania mogą nadal podawać WWDT we właściwej kolejności.

W rzeczywistości możesz użyć przerwań do karmienia WWDT, jeśli możesz obniżyć swój priorytet IRQ w normalnym kodzie wykonania, tak jak możesz to zrobić w MIPS (Microchip).

Jeśli Twój kod obsługuje obsługę krytyczną, krytyczną itp., Po prostu usuń je wszystkie i użyj zewnętrznego WDT (najlepiej na podstawie pytań i odpowiedzi).