ElectroYou

Ciao a tutti,

esiste un modo per sapere in che punto dell'esecuzione era il PIC quando il watchdog timer interviene e resetta il PIC?

Ho letto e riletto la sezione del datasheet del PIC32MX795F512L riguardo al watchdog e non ho trovato nulla a a riguardo.

Ho un firmware che si blocca ogni moooolto tempo e vorrei capire la causa.


Grazie mille ragazzi.. Buona giornata!


I'm looking for a firmware bug...

Ciao grandegiove.
Non ho letto il DS del PIC32 che hai citato, ma di solito il reset del micro a fronte di un overflow del watchdog non registra l'istruzione ultima in esecuzione prima del reset. Ciò che succede è che alcuni PIC hanno a disposizione dei registri che eindicano la causa di un restart e tra queste c'è il watchdog.

Ciao.

Paolo.

Ciao Paolino,

grazie mille per la risposta.

Purtroppo la risposta che temevo. La ritenevo una cosa talmente utile che ho pensato fossi io a non trovarla.

Ora la ricerca del bug si fa davvero molto molto complicata

Grazie mille!

Non conosco il tuo progetto, ma dato che il reset avviene dopo molto tempo, non riesci a monitorare mediante porta seriale ed un PC che registra i dati, il flusso del firmware?

Ciao.

Paolo.

Ciao Paolino,

il firmware in questione è fatto girare su macchine che lavorano all'aria aperta. Il problema si verifica ogni molte ore di lavoro (io ho visto lavorare la macchina per due giorni consecutivi senza mai bloccarsi).

Se uniamo il fatto che le macchine sono dislocate geograficamente un po' qua e un po' là beccare il bug debuggando è una bella impresa.

Il bug si è presentato da una certa versione in poi ma dal codice non riesco a capire dove sia il problema.

Edit: ovviamente a banco ho provato a simulare il problema per ore e ore e ovviamente tutto fila liscio

Per questo pensavo di inserire una parte autodiagnosticante per arrivare a capire dove si blocca.

Grazie!

Ciao grandegiove, mi inserisco nel thread senza nulla aggiungere a quanto per competenza ti ha già riferito @Paolino; invece, incuriosito da questi "enigmi", proporrei a questo punto di spostare l'attenzione su ...

grandegiove ha scritto:Il bug si è presentato da una certa versione in poi ma dal codice non riesco a capire dove sia il problema.

... e fare un passo indietro col proposito di stabilire cosa è cambiato, ammesso sia cambiato qualcosa.
Tra l'altro, sei certo che il "problema" non fosse già latente (quanto è stato fatto nella versione successiva, magari, non ha fatto altro che farlo emergere).
E' solo un'idea in più, che probabilmente hai già preso in considerazione, ma ...

Saluti

Ciao a tutti:

Update:

del bug nemmeno l'ombra. Però spero di aver creato un sistema di diagnostica efficace.

Sostanzialmente ho predisposto un finto watchdog con un timer.

I PIC32 consentono 7 livelli di priorità di interrupt.

Ho rivisto i livelli degli interrupt che utilizzo nell'applicazione in modo da non avere nessun interrupt a priorità 7 (la più alta).

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

Ho quindi attivato il watchdog con periodo T e settato il timer con periodo T/2. Il watchdog e il timer vengono azzerati nello stesso punto del main. (T/2 è già un tempo che presuppone il blocco dell'esecuzione da qualche parte).


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 e solo dopo interverrà il watchdog che resetterà il PIC permettendo alla macchina di continuare a lavorare.

Tutto ciò funziona se il blocco è comunque all'interno del codice e gestibile quindi via firmware, in questo caso il finto watchdog funziona. Per qualsiasi altro blocco o overflow che "disorienti" il program counter credo che il WDT intervenga senza che il timer abbia modo di fare il suo lavoro.



Scusate la spiegazione poco chiara ma spero che l'idea si capisca..

cosa ne dite ragazzi?

Direi che il salvataggio su eeprom è senz'altro utile, se proprio non riesci a usare un altro metodo (vedi ad esempio un datalogger su seriale, come ti dicevo prima).
Unica precauzione è il numero di scritture su eeprom: verifica che, statisticamente, tu stia entro i limiti ammessi.

CIao.

Paolo.

Anch'io penso che un "trace" via seriale sarebbe, in linea di principio, la modalità più "pratica".
Poi, è vero che, qualunque manipolazione si va ad operare sul firmware comporta il "rischio", concreto, di andare ad alterare lo stato stesso del sistema sul quale si vuole indagare, con le conseguenze del caso.
E' insita quindi la possibilità d'introdurre ulteriori variabili; comprendo comunque che qualcosa devi fare.
Voglio essere sincero: non mi è ben chiara l'illustrazione che hai fatto nel tuo ultimo Post (a prescindere dal livello dell'interrupt) ma qui ci può stare anche un mio limite nel comprendere a fondo il tuo proposito (se poi ti andasse di spiegarlo diversamente o in maniera più estesa, presupposta una tua disponibilità per farlo, mi farebbe piacere leggerlo).
Da parte mia, o comunque contestualmente ad un intervento "invasivo" sul codice (qualunque tipo tu abbia deciso di applicare, o potrebbe essere applicato), cercherei di capire (ricordare) cosa effettivamente è cambiato "da una certa versione in poi", come avevo riportato nel Post [6] del quale riprendo il principio confermando il dubbio che il "passaggio" di versione possa aver comportato una esecuzione di una parte di programma che prima non veniva eseguita, o una modalità di programma che, pur essendo eseguita, ora viene processata magari in modo differente o con variabili che "partono" da valori differenti rispetto a quelli che sino ad ora sono stati considerati (scrivo questo, a costo d'essere noioso, non sapendo appunto cosa contempli il passaggio di versione "incriminato").

Saluti

Rispondo di corsa, scusate la fretta.

Grazie mille del supporto. La possibilità di predisporre un datalogger seriale è poco percorribile: il bug si presenta ogni molte ore, non è possibile fissare un PC sulla macchina per via dell'ambiente di lavoro. L'unica via percorribile è che io sia fisicamente presente sulla macchina collegato in debug (aggrappato alla macchina) ma la dislocazione geografica delle macchine e la rarità del bug rende questa via non possibile.

Per ciò è necessario predisporre un sistema di autodiagnostica in modo tale che possa far lavorare la macchina e poi aver la possibilità di elaborare i dati offline.

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. Presumibilmente è perché il blocco si ha nell' ISR principale del codice, che ha priorità più alta (condizione necessaria per questione di strettissime esigenze real time).

Edit: il passaggio di versione è stato esaminato e riesaminato ma purtroppo con scarsi risultati, forse il problema è che son sempre quei due occhi che controllano...

Appena ho un attimo di calma spiego meglio cosa ho inteso far aggiungendo un WDT software fittizio.

Vi tengo aggiornati.

Grazie mille per il supporto, anche perché mi rendo conto dei pochi dati messi a disposizione per poter formulare consigli e idee.

Ad ogni modo per qualsiasi altra idea io son qua!