I've seen two cases now with dsPIC 30F4013 where the controller was resetting due to an undefined trap. Why these traps were getting raised in the first place is still a mystery, but that's not my immediate question. I'm starting to think it would be a good programming practice to always define all traps, even if traps should never occur, so I get at least a clear error message instead of a random reset. Is this a standard practice that I'm unaware of? Are there disadvantages to this practice I should consider?
My informal rule is:
Even without that rule, though, the data sheet explicitly answers your question:
(Source, section 8.3, first note)
Given that you cannot mask traps, then you must handle them. If you do not desire to deal with the trap in a particular fashion, the appropriate method is to execute a
Yes, it's a good idea - the only downside is a bit of extra code size, and you have to decide what to do with the trap (emit a message on the serial port? turn on a "FAILED" light? Silently reboot? etc)