Cane da guardia indipendente (IWDG) o Window watchdog (WWDG)?

Sto ancora cercando di trovare una risposta a questa domanda:

Perché mentre gli MCU stm32 hanno un cane da guardia perfetto (intendo il cane da guardia di Windows (WWDG)), c'è un cane da guardia semplice (cane da guardia indipendente (IWDG))?

Ho trovato questa pagina che ha detto:

La ST Microelectronics ha una linea di dispositivi Cortex-M3. M3 è diventato estremamente popolare per i dispositivi embedded di fascia bassa e STM32F di ST è rappresentativo di queste parti (sebbene il WDT sia un componente aggiuntivo ST e non rispecchi necessariamente le implementazioni di altri fornitori). STM32F ha due diversi meccanismi di protezione. Un "cane da guardia indipendente" è un bel design alla vaniglia che non ha altro che la facilità d'uso. Ma il loro Window Watchdog offre una protezione più solida. Alla scadenza di un conto alla rovescia, viene generato un reset, che può essere impedito ricaricando il timer. Niente di speciale lì. Ma se la ricarica avviene troppo rapidamente, anche il sistema si ripristinerà. In questo caso "troppo rapidamente" è determinato da un valore che si programma in un registro di controllo.

Un'altra caratteristica interessante: può generare un interrupt appena prima del ripristino. Scrivi un po 'di codice per catturare l'interrupt e puoi prendere qualche azione per, ad esempio, mettere il sistema in uno stato sicuro o per snapshot dei dati a scopo di debug. ST suggerisce di utilizzare l'ISR per ricaricare il cane da guardia, ovvero calciare il cane in modo che non si verifichi un ripristino. Non dare il loro consiglio. Se il programma si arresta in modo anomalo, i gestori di interrupt potrebbero continuare a funzionare normalmente. E l'utilizzo di un ISR per ricaricare il WDT invalida l'intero motivo di un watchdog della finestra.

e questo :

La nuova serie di CPU STM32F4 Cortex ™ -M4 di STMicroelectronics ha due watchdog indipendenti. Uno corre dal proprio oscillatore RC interno. Ciò significa che tutti i tipi di cose possono crollare nella CPU e il WDT continuerà a sparare. Esiste anche un "window watchdog" (WWDT) che richiede al codice di solleticare frequentemente, ma non troppo spesso. Questo è un modo molto efficace per assicurare che il codice in crash che scrive casualmente sul meccanismo di protezione non causi un solletico WDT e che il WWDT possa generare un interruzione poco prima che venga affermato il reset.

ok, diamo un'occhiata nel manuale di riferimento :

L'STM32F10xxx ha due periferiche di watchdog integrate che offrono una combinazione di alto livello di sicurezza, precisione di temporizzazione e flessibilità d'uso. Entrambe le periferiche di watchdog (Independent e Window) servono per rilevare e risolvere i malfunzionamenti dovuti a un errore del software e per attivare il ripristino del sistema o un interruzione (solo watchdog della finestra) quando il contatore raggiunge un determinato valore di timeout. Il watchdog indipendente (IWDG) è sincronizzato dal proprio clock a bassa velocità (LSI) dedicato e rimane quindi attivo anche se l'orologio principale non funziona. L'orologio watchdog (WWDG) della finestra è pre-calcolato rispetto all'orologio APB1 e ha una finestra temporale configurabile che può essere programmata per rilevare comportamenti anomali in ritardo o precoci dell'applicazione. L'IWDG è più adatto alle applicazioni che richiedono l'esecuzione del watchdog come processo totalmente indipendente al di fuori dell'applicazione principale, ma hanno vincoli di precisione di temporizzazione inferiori. Il WWDG è più adatto alle applicazioni che richiedono che il watchdog reagisca all'interno di una finestra di temporizzazione accurata.

Il watchdog della finestra viene utilizzato per rilevare il verificarsi di un errore del software, generalmente generato da interferenze esterne o da condizioni logiche impreviste, che induce il programma applicativo ad abbandonare la sua sequenza normale. Il circuito del watchdog genera un ripristino MCU alla scadenza di un periodo di tempo programmato, a meno che il programma non aggiorni il contenuto del downcounter prima che il bit T6 venga cancellato. Viene inoltre generato un ripristino MCU se il valore del downcounter a 7 bit (nel registro di controllo) viene aggiornato prima che il downcounter abbia raggiunto il valore del registro della finestra. Ciò implica che il contatore deve essere aggiornato in una finestra limitata.

Come puoi vedere, nessuno di loro ha detto Perché ci sono due cani da guardia. se chiedo che Quali sono le differenze tra i due watchdog, conterai tutte le funzionalità che puoi vedere in precedenza e se vuoi confrontare entrambi, ovviamente il watchdog di Window (WWDG) sarà il vincitore! allora Perché ci sono due cani da guardia?

Voglio sapere che quando dovrei usare IWDG e quando WWDG?

e c'è qualche ragione per dirci Perché chiamano il secondo orologio con questo nome -> "Window watchdog"?

I timer dei watchdog regolari devono essere ripristinati prima del timeout. Se si dispone di un WDT da 100 ms, è possibile ripristinarlo ogni 99,9 ms o ogni 10us e non scadrà mai.

I timer del watchdog della finestra hanno una finestra temporale entro la quale devono essere ripristinati. Se lo ripristini troppo presto o troppo tardi (dal ripristino precedente), il processore verrà ripristinato.

Lo scopo, se non è ovvio, è aiutare a garantire che il codice che reimposta il WDT sia il codice previsto, operando nel modo previsto. Un qualche tipo di condizione imprevista che genera ripristini WDT ad alta frequenza non impedisce il ripristino del sistema.

L'esecuzione di un WDT dall'orologio di sistema potrebbe essere un po 'un problema: se l'orologio non funziona e se non esiste un circuito di monitoraggio dell'orologio indipendente, possono accadere cose brutte. L'orologio indipendente per il WDT significa che se la cosa per qualche motivo inizia a funzionare a 1/10 di velocità, il WDT si ripristinerà (ma la finestra WDT non lo farebbe).

Usa entrambi se puoi.

Come dice la pagina, il ripristino del WDT con un ISR è generalmente un cattivo juju (ma può essere accettabile se l'ISR verifica che il ripristino del firmware funzioni prima di ripristinare il timer).

Il testo che hai incollato nella domanda fornisce le risposte di cui hai bisogno.

1. Usi IWDG quando hai bisogno di un semplice cane da guardia o quando hai bisogno di un cane da guardia completamente indipendente - IWDG ha il suo orologio, WWDG deriva il suo orologio da uno degli orologi del bus - se fallisce o il tuo software lo spegne, allora il cane da guardia muore.
2. Si utilizza WWDG quando è necessario un watchdog che può essere ripristinato entro un determinato intervallo di tempo (finestra). Se il software reimposta il WWDG troppo tardi, il WWDG farà scattare un reset del processore. Se il software reimposta il WWDG troppo in anticipo, causerà anche un ripristino del processore.

Viene chiamato "watchdog della finestra" per la semplice ragione che solo un watchdog resettato durante un periodo di tempo specificato (finestra di opportunità) impedirà al watchdog di ripristinare il processore.

Entrambi svolgono lavori simili, ma li svolgono in modo diverso. Ciò di cui hai bisogno dipende dai requisiti che devi soddisfare.

C'è un altro motivo per usare il watchdog della finestra, invece o o in aggiunta al watchdog indipendente. WWDG ha un interrupt che puoi agganciare. Ciò significa che, se il codice è entrato in un loop o in una fuga, è possibile impostare un punto di interruzione nell'ISR WWDG e lavorare all'indietro per scoprire cosa stava facendo il firmware quando il cane abbaiava.

Non puoi farlo con IWDG. Come suggerisce il nome, è indipendente dal processore. Piuttosto che sollevare un interrupt, asserisce e deassegue / RESET semplicemente - che non ti dà molti indizi sul perché abbaiò. Consiglio vivamente di impostare un WWDG all'interno dei normali parametri operativi, oltre a un IWDG in un periodo molto più lungo, forse 2 * WWDG massimo. Crea una funzione kick-dog che calcia entrambi. In questo modo, l'IWDG abbaia anche quando il WWDG si blocca, come backup finale.

La mia opinione su di esso:

Utilizzare entrambi contemporaneamente, perché cercano diverse condizioni non riuscite:

Il timer Independent Watchdog (IWDG) deve essere reimpostato continuamente prima di scadere . In pratica, puoi semplicemente aggiungere il codice di ripristino ovunque tu abbia uno stato di programma valido o una volta nel ciclo principale se hai un ciclo principale che dovrebbe essere eseguito frequentemente senza ritardi importanti. In questo modo, se la tua chiamata per resettare il timer (a volte viene chiamata "petting", "solletico, o semplicemente" resettaggio "" il cane da guardia ") non si verifica in tempo, significa che il tuo codice A) si è accidentalmente bloccato da qualche parte che non avevi previsto --- una sorta di imprevisto tipo di ciclo infinito stato, o B) intenzionalmente bloccato da qualche parte che hai imposto tramite unassert()chiamata di funzione con un ciclo infinito incorporato in cui si desidera che il codice vada ogni volta che una condizione importante non è vera. Quindi, ora che la tua condizione di asserzione è falsa, il tuo codice viene intenzionalmente bloccato in un ciclo infinito e il cane da guardia reimposta il microcontrollore per riportarlo a uno stato valido. Si noti inoltre che "il watchdog indipendente (IWDG) è sincronizzato dal proprio clock a bassa velocità (LSI) dedicato e rimane quindi attivo anche se l'orologio principale non funziona" (consultare il Manuale di riferimento ST RM0008 p493 ).

Mi sembra tuttavia che il timer Window Watchdog (WWDG) sia progettato per non cercare i casi sopra descritti (in cui il codice o involontariamente o intenzionalmente [tramite un'asserzione] viene "bloccato" da qualche parte), ma più specificamente per il caso in cui A) il tuo codice NON esegue qualcosa che dovrebbe . In altre parole, ha un errore che causa l'esecuzione troppo rapida del suo ciclo principale o altra sottosezione di codice (o da saltare del tutto), quindi reimposta il watchdog troppo presto, fuori dalla sua finestra, e il mcu viene ripristinato. Oppure, B)l'altra condizione che può individuare è un'impostazione del timer non riuscita. Forse lo stai reimpostando a un intervallo fisso, ma il tuo timer usato per creare questo intervallo o cambia accidentalmente le sue configurazioni in qualche luogo che non avrebbe dovuto, o lo configuri erroneamente in primo luogo, quindi l'intervallo di tempo sarà spento, il tuo fisso il ripristino dell'intervallo di tempo reimposterà il WWDG al di fuori della sua finestra (o troppo presto o troppo tardi) e l'MCU verrà ripristinato per avvisare l'utente e / o correggere la condizione.

Questa è la mia opinione su di esso. Sono benvenuti pensieri o feedback.

Il cane da guardia "a finestre" è solo un normale cane da guardia che protegge alcune pratiche di programmazione ancora peggiori. Come altri hanno detto, hai un "lasso di tempo" solitamente regolabile dove dovrebbe essere fornito il tuo "feed".

Nessuno di questi è a prova di proiettile se il codice può essere inserito in un ciclo sostenuto automaticamente. Per esempio. Se si prevede di "alimentare" in base agli IRQ relativi al timer, questa può essere una pratica estremamente negativa poiché il codice può essere bloccato in alcune attività / mentre nel thread di posta, mentre gli interrupt possono comunque alimentare il WWDT nella sequenza corretta.

In realtà, puoi usare gli interrupt per alimentare WWDT se puoi abbassare la tua priorità IRQ con il normale codice di esecuzione come puoi fare su MIPS (Microchip).

Se il tuo codice è supporto vitale, critico, ecc., Lasciali cadere tutti e usa WDT esterno (preferibilmente basato su domande e risposte).