Uso del watchdog nei PIC

[EcoTan]

(ISR) dove avviene il blocco ed è la routine che viene servita con il livello di priorità più alto.

Hai la possibilità di lasciare tutti i livelli di priorità standard di default e riprovare il tutto? Lo dico perché mi è capitato qualcosa di simile. In che linguaggio è scritta la ISR? Ha calcoli floating point?

[grandegiove]

Ciao ragazzi,

scrivo veloce per un triste update.

Ho avuto modo di parlare con un cliente che sta usando la macchina. Gli ho chiesto di accedere alle pagine del touchscreen dove vengono visualizzati i dati relativi alla diagnostica del problema.

Dai dati emerge che il sistema si è bloccato spesso (fortunatamente grazie al wdt si riavvia e dopo un ripristino delle impostazioni iniziali si rimette prontamente a funzionare e quindi di fatto lui non si accorge del blocco ed è molto contento della macchina ) però.....

non ci sono dati salvati in eeprom relativi al punto del programma dove è avvenuto il blocco

Sostanzialmente il wdt fittizio non funziona: credo che questo fatto non abbia altra risposta che un overflow o uno sconfinamento di un array che causa il completo smarrimento del program counter. Quindi alla fine interviene il WDT vero proprio. Almeno questa è la prima ipotesi che mi viene in mente.

[Paolino]

Eh, allora cerca di riproporre in laboratorio, il più fedelmente possibile, le condizioni operative del campo. Collega quanti più strumenti puoi ritenere adatti alla tua applicazione e poi spera che si blocchi anche lì da te.

Al momento, non ho molte altre idee in testa...

Ciao.

Paolo.

[grandegiove]

Grazie Paolino,

al momento anche a me non vengono molte altre idee se non riguardare per l'ennesima il codice alla luce del nuovo scenario.

[grandegiove]

Trovato!!!!

Almeno credo e spero. Senza entrare troppo nel dettaglio: sostanzialmente un controllo prevedeva l'accesso ad un array con un indice che, in una particolare situazione, usciva dalla dimensione dell'array.

tipo:

Codice: Seleziona tutto

unsigned int arrayValori[100];

[...]
k=150;
if(arrayvalori[k]==1)
a=b;


Poco da dire: erroraccio mio. A mio discapito posso solo dire che la condizione che dava origine allo sforamento era molto molto subdola. Ma ciò non toglie che mi fosse sfuggita in stesura e in rilettura. Torna anche il fatto che questa situazione sia possibile solo da una certa versione in poi. E dire che gli indici degli array li avevo controllati più e più volte così come le novità nella nuova versione. A volte è vero che se gli occhi son sempre quei due..

Quando ho avuto l'informazione relativa al fatto che il wdt interveniva senza dar modo al wdt fittizio di salvare il punto del programma mi sono concentrato sulle situazioni in cui si potevano avere degli "sforamenti in memoria". Ho quindi messo un accesso ad un array con un indice volutamente più grande della dimensione dell'array nel main. Quando attivavo l'acceso il micro si pianta del tutto, ISR incluse, a prescindere da dove avvenisse l'accesso. Ho quindi riesaminato ancora una volta gli indici fino a trovare l'errore. Non so se questo comportamento valga in generale o se esistano compilatori che generano un codice che previene il blocco totale in caso di accesso "fuori range" ad un array. Nel mio caso no. Approfondirò sicuramente la questione.

Esco dall'esperienza stremato ma credo di aver comunque imparato qualcosa. Fortunatamente esiste anche il modo di disabilitare quella parte di codice con l'HMI a disposizione dell'operatore sulla macchina, quindi nell'attesa di poter aggiornare il tutto il problema può essere aggirato da remoto.

Vi ringrazio per il sostegno e per le idee! Spero che il mio errore sia stato almeno utile a dar vita ad una discussione costruttiva. Meglio pensarla così

Buon pomeriggio!!

[Paolino]

Bene, grandegiove!
Sono contento.

Ciao.

Paolo.

[WALTERmwp]

Ho quindi riesaminato ancora una volta gli indici fino a trovare l'errore.

... se così è, e te lo auguro, mi fa piacere perché hai risolto il problema e forse forse ... nei Post precedenti ci avevamo preso.
Sarebbe interessante (e per te potrebbe costituire la conferma) scoprire come mai, prima, l'erroneo accesso all'array non avveniva (mi riferisco alla questione del prima/dopo).
Per questo ...

Non so se questo comportamento valga in generale o se esistano compilatori che generano un codice che previene il blocco totale in caso di accesso "fuori range" ad un array. Nel mio caso no. Approfondirò sicuramente la questione.

... potrei non essere "aggiornato" ma non credo faccia parte della genetica del "C"; e, a maggior ragione, se si sforano gli indici, per esempio, in un loop (non credo ci sia in fase di compilazione un controllo preventivo).
Buona continuazione.

Saluti

[grandegiove]

Dopo il considerevole numero di ore di lavoro di diverse macchine dove gira il firmware aggiornato possiamo finalmente confermare che l'errore era proprio quello!

Solved

Buona giornata!

[Paolino]

Bene!