CCS/LAUNCHXL-CC1310: CCS won't apply changes to PC/SP/LR core registers

Hello,

Michael Moon said:

I'm apparently supposed to manually copy SP/LR/PC from Hwi/Exception info into Core Registers to get CCS to give me the backtrace.

Are you following some document of some sort? If so, can you point me to it?

Michael Moon said:

The problem is, quite frequently CCS flatly refuses to update the registers - It accepts the new address in edit mode, but returns to the old one when I press enter, and the backtrace doesn't work.

I assume you are using the Register view to attempt this. I'm able to have my changes accepted there using the same CCS version on my CC1310 LaunchPad on Ubuntu. I assume I am missing some step to reproduce the issue. Can you provide some reproducible test case (perhaps the document mentioned above)?

Thanks

ki

The documentation for this process is here.

I don't think I'm doing anything special to cause the issue, simply encounter (or trigger) a Hw exception in firmware, pause debugging, then try to copy the three listed register values into the core registers pane as described in the documentation linked above.

I'd vastly prefer that CCS would simply recognise the error flag and backtrace past it without these shenanigans of course, but this seems to be what we're stuck with for now.

Quick followup, that documentation says that those steps aren't required in newer CCS versions because backtrace is available in ROV Task viewer, however that doesn't allow me to examine variables within the stack frame like I can when I highlight a stack frame in the primary backtrace viewer, so examining variables within a stack frame still requires manually copying those values.

Michael Moon said:

Quick followup, that documentation says that those steps aren't required in newer CCS versions because backtrace is available in ROV Task viewer, however that doesn't allow me to examine variables within the stack frame like I can when I highlight a stack frame in the primary backtrace viewer, so examining variables within a stack frame still requires manually copying those values.

I had previously reported a similar problem in Is it possible for CCS 6.1.2 to switch the debug context to a blocked TI-RTOS task?, but didn't get an answer.

Michael Moon said:

If I go to edit the field again, the new address is displayed in edit mode, so CCS apparently knows what I want it to be. Upon pressing enter, the address will however return to the old one.

I was trying to repeat the problem using CCS 7.1.0.00016 running under Ubuntu 16.04 LTS. Used a CC1310 connected with a Segger J-Link, running a TI-RTOS program which generated an exception (to test the exception handling).

After an exception occurred repeated the problem in that sometimes after pressing enter when attempted to change the PC, SP or LR registers the address returned to the old one. However, this appears to be just a display issue since if the "Refresh" button was then used on the Register window the address then showed the updated value, and the backtrace in the CCS debug window changed according to the modified PC, SP and LR registers.

I think the problem of the register value reverting to the original value after pressing enter may only occur with CCS 7.1.0.00016 running under Linux, since with CCS 7.1.0.00016 running under Windows 10 didn't see the problem.

Michael Moon said:

Since CCS can't backtrace past Hwi exception interrupts (it mistakes the exception word as a return address and chokes), I'm apparently supposed to manually copy SP/LR/PC from Hwi/Exception info into Core Registers to get CCS to give me the backtrace.

In case it helps, I found that when an example for a CC1310 is imported from either simplelink_cc13x0_sdk_1_30_00_06 or tirtos_cc13xx_cc26xx_2_21_00_06 the hardware exception behaviour in the .cfg file is configured as:

/*
 * The following options alter the system's behavior when a hardware exception
 * is detected.
 *
 * Pick one:
 *  - Hwi.enableException = true
 *      This option causes the default m3Hwi.excHandlerFunc function to fully
 *      decode an exception and dump the registers to the system console.
 *      This option raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.enableException = false
 *      This option reduces code footprint by not decoding or printing the
 *      exception to the system console.
 *      It however still raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.excHandlerFunc = null
 *      This is the most aggressive option for code footprint savings; but it
 *      can difficult to debug exceptions. It reduces flash footprint by
 *      plugging in a default while(1) trap when exception occur. This option
 *      does not raise an error with the Error module.
 */
//m3Hwi.enableException = true;
//m3Hwi.enableException = false;
m3Hwi.excHandlerFunc = null;

Found that the (default) option of m3Hwi.excHandlerFunc = null is causing the SP reported in the ROV Hwi/Exception info to be incorrect; the SP is reported as 0x30 bytes less than the actual value at the point of the exception. The incorrect SP captured for the exception causes the stack trace in the ROV view to be incorrect, such that only the leaf and penultimate functions are reported in the stack trace. When the PC / LR / SP registers are copied from the ROV exception view to the CCS registers the stack backtrace in the CCS debugger is then also incorrect.

Changing to use either the m3Hwi.enableException = true or m3Hwi.enableException = false options then meant that the SP register reported in the ROV exception view such that the stack backtrace in the ROV exception view was complete, and that the stack backtrace in the CCS debugger was also complete when the PC / LR / SP registers were copied from the the ROV exception view to the CCS registers.

Thanks Chester for confirming, glad it's not just me!

Good to know the refresh button can help, I'll try that next time - it triggers my advertising blindspot so didn't see it at first.

The m3Hwi stuff is set to true in my application since I want to see detailed messages printed or at least logged, although knowing that null breaks CCS's stack view is useful