LAUNCHXL2-570LC43: Debugging call stack using CCS after exception vector is encountered

Peter Lu said:

It'd be so nice if CCS had facilities to do this, in the same way the normal stack frame is displayed for analysis. 

While CCS currently doesn't have any in-built support for this, with Cortex-M4F devices have previously used a custom GEL script to unwind the stack to get CCS to display the context of the exception. See CCS/TM4C1294KCPDT: How do I get the stack unwound in exception handlers?

Some changes would be required to the GEL script to handle any differences in the exception stack frame between a Cortex-M4F and Cortex-R5F, but could maybe form a starting point.

At least with a GEL script it just runs on the PC in CCS, rather than needing target-side code.

Hi,

I need serious help on debugging.  A couple of days ago, I was seeing the problem above as described, with a combination of "spontaneous" resets, undefEntry, or prefetchEntry errors, with running times as long as 8 or 10 hours before the error is encountered.

As of yesterday, the problem has morphed to one of spontaneous resets or dataEntry errors that can happen from 10 minutes to hours.  This may be "better or worse" depending on whether the ability to run longer is desirable or hitting some error more quickly would allow more experimentation or analysis.  When the dataEntry error occurs, the fault address, R14_ABT, is not (necessarily) at the same place (as somewhat expected).  I believe R14_ABT - 0x8 is the faulting PC, based on some forum article.  I'm not even sure whether chasing the dataEntry error would lead to my actual cause, but it's a start, and it's happening consistently/often enough.

For one thing, I have no idea how the symptoms have changed so much (from undefEntry and prefetchEntry, to dataEntry, and having running times of 6+ hours to minutes), since I haven't changed my source code in any real way.  In some sense, the seeming "stability" has vaporized overnight.

In any case, I don't know what steps to take to decipher the dataEntry fault.  I'm not quite certain what processor mode I'm in (I think User, or maybe Interrupt).  I've tried looking at other data abort forum articles and the Technical Reference Manual, but have not gotten a solid handle on what steps need to be performed.  Several of the articles elude to debugging steps, but seemed to have reached solutions without really having to use the results of the debugging to get to fixes.  One thing that I'm struggling with is the number of Registers and what particular ones does exactly what (sometimes not even sure where to find the register mentioned in particular articles).

Thank you very, very, much in helping me figure out the necessary debugging steps with the Cortex-R5F, or directing me to the right information.

So, in one failure case, I see R14_ABT to be 0x112cc, which leads to a PC of 0x112c4.  I look at the assembler and it seems r0 is being loaded with 0 (core register value) from [r13] (link/frame register??).  The value of r13 is 0x8002800 (which contains 0), which is supposedly my Undefined Stack Base (I doubled the size of my stacks from default, just in case I was hitting some stack overflow issues).  The C code is supposed to be playing with some CAN message boxes, AFAICT.  Don't know what the Undefined Stack is used for, or even if I'm looking at the right r13.

I don't know how I got here.  Any help appreciated highly.

000112b0: E59DC00C ldr r12, [r13, #0xc]
000112b4: E35C0008 cmp r12, #8
000112b8: 3AFFFFEE blo $C$L107
2603 node->IF1NO = (uint8) messageBox;
$C$L108:
000112bc: E59D0000 ldr r0, [r13]
000112c0: E5DDC007 ldrb r12, [r13, #7]
000112c4: E5C0C103 strb r12, [r0, #0x103]
2605 success = 1U;
000112c8: E3A0C001 mov r12, #1
000112cc: E58DC010 str r12, [r13, #0x10]
2614 return success;

Actually, 0x8002800 is the Undefined Stack Base, so it seems the code is reading beyond the stack to get the 0 value.  Don't know why r13 holds that value.

I tried to take the GEL project and port it for the XL2-570LC43, but can't figure out how it's supposed to work.  With a few tweaks, I was able to build and load it, but don't know how the code is supposed to run (if it is running).  Most/all my previous projects will start-up stopped at main() in HL_sys_main.c, but this one does not (don't know where to put breakpoint, if needed).

I probably need to tweak more things.

Thanks.

Hi Peter,

Have you resolved your issue?

I did "solve" my problem (the one that seemed to require the need to trace the stack across exception vectors), in a totally different way.  I would really love to be able to get the GEL project, which presumably does the stack trace across exception vectors without target code support, going on the TMS570-LC43.  This would help me both debug future oddball problems, as well as maybe understand better how this particular ARM processor runs contexts and stacks/registers.  Right now, I'm still often guessing how the processor does things (using transferred experience from other older-generation processors that are more simplistic).

Do you think getting the GEL project ported is a viable goal, or should I abandon this desire?  In reality, most cases of (catastrophic) exception vectors are due to faulty memory scribbling that happened some time earlier, and stack tracing won't help that much anyway.

Thank you very much.