Tutte le trappole dovrebbero essere sempre definite?

18

Ho visto due casi ora con dsPIC 30F4013 in cui il controller si ripristinava a causa di una trap non definita. Perché queste trappole siano state sollevate in primo luogo è ancora un mistero, ma non è la mia domanda immediata. Sto iniziando a pensare che sarebbe una buona pratica di programmazione definire sempre tutte le trap, anche se le trap non dovrebbero mai verificarsi, quindi ricevo almeno un chiaro messaggio di errore invece di un reset casuale. È una pratica standard di cui non sono a conoscenza? Ci sono svantaggi di questa pratica che dovrei considerare?

— Stephen Collings
fonte

4

Non è una risposta alla tua domanda, ma qualche tempo fa ho sofferto di questo tipo di sintomi sui sistemi dsPIC e PIC24. Nel mio caso le trap sono risultate da bit di codice in cui stavo rimandando i puntatori a valori a 16 bit e questi stessi puntatori avevano valori dispari (non pari), poiché puntavano in un buffer di comunicazioni circolare - e non avevo precedenti modo di sapere se il valore a 16 bit inizierebbe su un limite pari o dispari. Il compilatore XC16 non ti protegge dai blocchi dell'hardware qui. Ho finito per scrivere una macro wrapper per queste funzioni che ha costretto 2 de-ref puntatore a 8 bit.

— brhans,

13

La mia regola informale è:

Se un interrupt è abilitato, allora dovresti avere il codice che lo gestisce.
Se non scrivi il codice per un interrupt, disabilitalo.
Se non è possibile disabilitarlo, scrivere il codice per esso.

Anche senza quella regola, tuttavia, la scheda tecnica risponde esplicitamente alla tua domanda:

Se l'utente non intende intraprendere azioni correttive in caso di una condizione di errore trap, questi vettori devono essere caricati con l'indirizzo di un gestore predefinito che contenga semplicemente l'istruzione RESET. Se, d'altra parte, viene chiamato uno dei vettori che contengono un indirizzo non valido, viene generata una trappola dell'errore di indirizzo.

( Fonte , sezione 8.3, prima nota)

Dato che non è possibile mascherare le trappole, è necessario gestirle. Se non si desidera gestire la trappola in un modo particolare, il metodo appropriato è eseguire RESETun'istruzione.

— Adam Davis
fonte

Sì. Ho un modulo standard con obiettivi per tutte le trappole.

— Olin Lathrop,

16

Sì, è una buona idea - l'unico aspetto negativo è un po 'di dimensione del codice extra e devi decidere cosa fare con la trap (emettere un messaggio sulla porta seriale? Accendere una luce "FAILED"? Riavviare silenziosamente? Ecc. )

— pjc50
fonte

4

Di solito ho solo il processore in esecuzione in un ciclo infinito NOP / GOTO. In questo modo lo stack non è stato danneggiato dalla trappola e durante il debug ho la possibilità di svelarlo e capire cosa è successo. Non ricevo spesso trappole, ma l'80% delle volte è una trappola per indirizzo strano, di solito perché la spazzatura è stata caricata come puntatore. A volte il puntatore dello stack viene danneggiato e produce trap di indirizzi dispari. È più difficile eseguire il debug poiché lo stack non è più presente. Fortunatamente, è davvero raro.

— Olin Lathrop,