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:
- If an interrupt is enabled, then you should have code that handles it.
- If you don't write code for an interrupt, disable it.
- If you can't disable it, write code for it.
Even without that rule, though, the data sheet explicitly answers your question:
If the user does not intend to take corrective action in the event of a trap error condition, these vectors must be loaded with the address of a default handler that simply contains the RESET instruction. If, on the other hand, one of the vectors containing an invalid address is called, an address error trap is generated.
(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