Uso del watchdog nei PIC

[Paolino]

Impiegate per caso un sistema operativo?

[grandegiove]

No Paolino, nessun S.O.

[WALTERmwp]

Azzardo un'ipotesi (una delle tante che, ingenerale, si potrebbero fare) a proposito di questo ...

La scheda dove occorre il bug è slave di una rete RS485 a 1 Mbit ma in seguito al blocco l'UART del PIC si blocca e non c'è verso di riprendere la comunicazione.

... sono stati aggiunti altri slave ?
Il protocollo è rimasto immutato e di conseguenza anche il driver è rimasto inalterato ?
Rispetto al "passato", ci sono state delle "variazioni" nella quantità di informazioni richieste/trasmesse (sempre, si intende, col medesimo driver) ?

Saluti

[DanteCpp]

Scusate se mi intrometto, premetto di non esser un'esperto controllista, ma trovo questa situazione di debugging estremo veramente interessante.

Comunque dal momento che il micro è connesso ad una rete (master-slaves), non sarebbe sufficiente che gli slaves notifichino periodicamente il loro stato al master? In questo modo se pur la comunicazione si interrompe per azione del WCD si avranno comunque informazioni preliminari alla situazione critica.

Mi sembra più pratico dell' inserire un'ulteriore strato di software da guardia!

PS. sempre che tu possa agire anche sul master.

[WALTERmwp]

Ciao DanteCpp, la mia opinione a proposito di questo ...

non sarebbe sufficiente che gli slaves notifichino periodicamente il loro stato al master? In questo modo se pur la comunicazione si interrompe per azione del WCD si avranno comunque informazioni preliminari alla situazione critica.

... (a prescindere dall'accessibilità nei confronti del Master) è che alla eventuale mancata risposta sarebbe comunque estremamente improbabile associare la causa; non potresti, cioè, identificare il punto in cui il codice ha "deviato" per un percorso anomalo (un loop infinito, una perversa ricorsione, un accesso incongruente allo stack ... ) o comunque sarebbe estremamente improbabile (non impossibile, eh).
Se poi tu volessi impiegare la mancata risposta dello slave, per diagnosticare indirettamente il fault, potresti essere ingannato da un "semplice" problema di comunicazione.
Una delle ultime cosa che farei, in ogni caso, sarebbe quella di andare a "toccare" il driver sul Master (ti porteresti nel campo delle "garantite imprevedibilità") a meno che non si ritenga il programma di comunicazione talmente robusto e consolidato da poterlo padroneggiare (alterare) senza crearsi più problemi di quelli che esistono.
Tieni presente, però, che questo è il mio punto di vista e si basa su considerazioni di carattere generale.
La risposta più coerente te la potrà dare @grandegiove.

Saluti

[DanteCpp]

non potresti, cioè, identificare il punto in cui il codice ha "deviato" per un percorso anomalo (un loop infinito, una perversa ricorsione, un accesso incongruente allo stack ... ).

Come no, se il master crea un log dei dati di debug (per esempio il contenuto del puntatore di programma) o un'indicatore più grossolano aggiunto qua e la, è possibile identificare situazioni di deadlock cosi come deviazioni anomale del flusso d'esecuzione. Naturalmente non è come avere il micro attaccato alla seriale, ma almeno permetterebbe di carpire qualche informazione...

[WALTERmwp]

Come no, se il master crea un log dei dati di debug

... il fault avviene sullo slave ... e, in ogni caso, una mancata risposta (a prescindere dalla frequenza di polling) non è riconducibile, associabile, alla porzione di codice dedicata alla comunicazione (sullo slave): potrebbe essere qualunque cosa.

Saluti

[Paolino]

Sono un po' stanco stasera. Il mio pensiero su questo argomento è che la struttura del firmware sarebbe dovuta già essere tale da prevedere trasferimenti dèi valori degli stati di ogni slave.

Vediamo se grandegiove se la cava col salvataggio dei dati in eeprom.

Ciao.

Paolo

[grandegiove]

Ciao a tutti,

grazie a tutti per la partecipazione e il sostegno.

Cominciamo col dire che ancora non ho trovato l'inghippo.

Non ho ancora avuto modo di avere un feedback dalle macchine col sistema di autodiagnostica.

Alcune precisazioni: ho con tutta probabilità individuato la routine di servizio interrupt (ISR) dove avviene il blocco ed è la routine che viene servita con il livello di priorità più alto. Questo è necessario perché l'operazione svolta nell'ISR ha dei vincoli real time critici ed è il cuore dell'applicazione.

L'ISR che gestisce la ricezione dei dati sulla linea seriale è ad un livello più basso.

Esiste un sistema di monitor della comunicazione seriale così come la possibilità di verificare in qualsiasi momento la condizione dello slave. A patto però che sia attiva la comunicazione seriale.

Essendo il blocco in una ISR a priorità più alta rispetto alla gestione della seriale tutto il sistema di monitor diventa inutilizzabile. Nell'ISR critica si ha una sequenza di operazioni abbastanza complessa: normalmente è buona cosa non appesantire l'ISR ma in questo caso il vincolo temporale impone di eseguire quelle operazioni all'interno e quindi non è pensabile di rivedere i livelli di priorità. Il ritardo introdotto dalla ricezione dei dati seriali rallenterebbe in modo inaccettabile l'esecuzione dell'ISR critica.

Vediamo se arrivano sviluppi.

Buon pomeriggio ragazzi!

[GuidoB]

Ciao grandegiove,
premetto che non conosco i pic32, ma penso si possano utilizzare gli stessi metodi di altre famiglie...

spero di aver creato un sistema di diagnostica efficace.

Sostanzialmente ho predisposto un finto watchdog con un timer.

...

Ho quindi predisposto un timer il cui overflow scatena per l'appunto un interrupt di livello 7.

...

Mi sembra un'ottima idea!

In questo modo in caso di blocco del codice da qualche parte, prima scatta l'interrupt del timer, ho modo di salvare nella eeprom una variabile "punto del programma" che ho assegnato qua e la nel codice

Qui invece mi sembrerebbe meglio salvare nella eeprom (o in una zona della ram che sopravviva al reset, se esiste) la "coda" dello stack.
Così vedi l'indirizzo di ritorno dalla routine di interrupt e, con un po' di lavoro, la catena di chiamate a procedura che ti ha portato in quel punto, i valori dei parametri passati e delle variabili locali.

Per farlo dovresti "poppare" dallo stack gli ultimi valori e salvarli in eeprom. Il più importante è il primo (o uno dei primi, dipende dal micro) che "poppi", cioè l'indirizzo di ritorno. Poi, senza aspettare il watchdog, puoi chiamare il reset da dentro l'interrupt per evitare di incasinare ulteriormente la macchina con lo stack che hai appena corrotto coi tuoi "pop". Oppure studi un meccanismo per ripristinare lo stack... vedi tu cosa ti conviene.

Leggendo dallo stack, non hai piú bisogno di settare una variabile "punto del programma" che per forza di cose metti dove tu sospetti che sia il problema. I problemi sono subdoli e tante volte non sono dove ci aspettiamo che siano...

Un problema del genere mi aveva tenuto impegnato un mese e mezzo...

trovo questa situazione di debugging estremo veramente interessante.

Questa definizione mi sembra molto azzeccata!