Trap Conflict Reset on dsPIC33

soundscu · Joined: 29 Jun 2007 Posts: 62 Location: Raleigh, NC

Hi everyone. I'm embarrassed to have to ask this, but...

What is a Trap Conflict Reset?

I've been developing an application on the DSPIC33FJ128MC804 using CCS C 4.103. A Trap Conflict Reset reliably occurs when either of the 2 MSBs are set in the 5th, 9th, 13th, or 17th data byte of a 22-byte incoming usart message. The reset occurs after normal completion of the usart receive interrupt routine. I've confirmed the cause of reset by checking the RCON register. Honestly, this makes no sense to me. If I modify the data to prevent those bits from being set in those bytes, everything proceeds reliably with no unexpected resets. Setting those bits in other bytes does not cause the reset. The receive routine does nothing but save the incoming values into an array. There are no special exceptions for the bytes that cause the reset. A packet start is identified by a value of zero, and no other bytes are ever zero. The last two bytes are always 0x55, and the packet length is always 22 bytes. All of that seems to be working fine, provided I don't set bits as desctibed above.

I'm pulling my hair out. Any ideas?

tia,
Jim

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

You may want to show to code details to make the particular issue understandable.

Generally, a trap conflict means, that one of the existing hardware traps, that hasn't be handled by a trap interrupt,
is triggered a second time. To know which trap it is, you have setup trap interrupt handlers.

The topic has be discussed previously related to error trap and stack overflow trap, which are the most
"popular" traps.
http://www.ccsinfo.com/forum/viewtopic.php?t=36479
http://www.ccsinfo.com/forum/viewtopic.php?t=40083

Apart from these two, also a math error and an oscillator failure trap exist, but I didn't yet manage to
bring them up.