S12X: Does Reset Change the Stack Pointer?

cancel
Showing results for 
Search instead for 
Did you mean: 

S12X: Does Reset Change the Stack Pointer?

Jump to solution
478 Views
davekellogg
Contributor II

Using S12XE processor, and trying to track down the source of an infrequent COP time-out.

 

I know that the COP timeout forces a reset.  What I'd like to do in the COP ISR is look back at the stack frame when the COP occured, particularly the PC.  Of course, this will work only if the SP 's value is not changed by the reset.

 

So, is the stack pointer unchanged across a COP-induced reset?

 

Thanks!!

Dave Kellogg

Labels (1)
0 Kudos
1 Solution
209 Views
GordonD
Contributor IV

Dave,

I checked with design and unfortunately, the stack pointer is reset (cleared) for any reset. This it a difficult problem and one that can generally only be solved with the use of a full in-circuit Emulator with external trace memory. However, the on-chip debug module (S12XDBG) could help you. It can be set up for "Pure PC mode" where all program counter addresses are stored in the trace buffer. Since a reset, other than a POR, does not affect the contents of the trace buffer or the DBGCNT register, the COP reset routine could look at the DBGCNT register and read the appropriate number of entries from the trace buffer.

This should allow you to determine where the code was executing when the COP reset occurred.

Best Regards,

Gordon

View solution in original post

0 Kudos
2 Replies
210 Views
GordonD
Contributor IV

Dave,

I checked with design and unfortunately, the stack pointer is reset (cleared) for any reset. This it a difficult problem and one that can generally only be solved with the use of a full in-circuit Emulator with external trace memory. However, the on-chip debug module (S12XDBG) could help you. It can be set up for "Pure PC mode" where all program counter addresses are stored in the trace buffer. Since a reset, other than a POR, does not affect the contents of the trace buffer or the DBGCNT register, the COP reset routine could look at the DBGCNT register and read the appropriate number of entries from the trace buffer.

This should allow you to determine where the code was executing when the COP reset occurred.

Best Regards,

Gordon

View solution in original post

0 Kudos
209 Views
davekellogg
Contributor II

Hi Gordon,

Thanks for your response and insight.  I had totally forgotten about the trace buffer.  The approach makes sense.  When I dragged out my old hard copy of the manual, I found a note I had written several years ago about this possiblity.

Dave Kellogg

0 Kudos