Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
4  
Not an answer to your question, but I suffered with those kinds of symptoms on dsPIC & PIC24 systems a little while ago. In my case the traps resulted from bits of code where I was de-referencing pointers to 16-bit values and these pointers themselves had odd (not-even) values, since they were pointing into a circular comms buffer - and I had no prior way of knowing whether the 16-bit value would start on an odd or even boundary. The XC16 compiler doesn't protect you from the hardware's hangups here. I ended up writing a wrapper macro for these functions which forced 2 8-bit pointer de-refs. – brhans Feb 22 at 15:23
up vote 13 down vote accepted

My informal rule is:

  1. If an interrupt is enabled, then you should have code that handles it.
  2. If you don't write code for an interrupt, disable it.
  3. 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 RESET instruction.

share|improve this answer
    
Yup. I have a standard module with targets for all traps. – Olin Lathrop Feb 22 at 22:09

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)

share|improve this answer
4  
I usually just have the processor run in a infinite NOP/GOTO loop. That way the stack hasn't been corrupted from the trap, and when debugging I have a chance to unravel it and figure out what happened. I don't get traps often, but 80% of the time its a odd address trap, usually because garbage got loaded as a pointer. Sometimes the stack pointer gets corrupted and produces odd address traps. Those are harder to debug since the stack is no longer there. Fortunately, that's really rare. – Olin Lathrop Feb 22 at 22:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.