This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC2642R: Debugging Hardware Exceptions

Part Number: CC2642R
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

We are building an application on custom boards based on the ble5stack simple_peripheral example from the SimpleLink CC26X2 SDK version 2.30.00.34.

First, let me explain why I believe we have issues with hardware exceptions.  Our application frequently seems to freeze up.  Upon pausing execution, CCS says

Can't find a source file at "/db/vtree/ademars/git_trees/avala-B/src/ti/sysbios/family/arm/m3/Hwi.c"
Locate the file or edit the source lookup path to include its location.

Assuming the proper path should actually be simplelink_cc26x2_sdk_2_30_00_34\kernel\tirtos\packages\ti\sysbios\family\arm\m3\Hwi.c, we pointed CCS to that file.  This causes line 877 to be highlighted, which is a comment reading " *  ======== Hwi_getHookContext ========" before the function of the same name.  Figuring there's some kind of optimization going on that is causing the line trace to be off, we looked at the disassembly.  It still places the code in Hwi_getHookContext():

 877       *  ======== Hwi_getHookContext ========
1003ab7c:   4A06                ldr        r2, [pc, #0x18]
1003ab7e:   6810                ldr        r0, [r2]
1003ab80:   6814                ldr        r4, [r2]
1003ab82:   F8D00174            ldr.w      r0, [r0, #0x174]
          $C$L554:
1003ab86:   2800                cmp        r0, #0
1003ab88:   D0FD                beq        $C$L554
 881          return (hwi->hookEnv[id]);

But, seeing the infinite loop of branching after comparison with 0, the only corresponding code structure in this file is this function here:

/*
 *  ======== Hwi_excHandler ========
 */
Void Hwi_excHandler(UInt *excStack, UInt lr)
{
    Hwi_module->excActive[0] = TRUE;

    /* spin here if no exception handler is plugged */
    while (Hwi_excHandlerFunc == NULL) {
	;
    }

    Hwi_excHandlerFunc(excStack, lr);
}

It wasn't until we had done all of this that we saw that a similar name appears in the debug panel:

Texas Instruments XDS110 USB Debug Probe/Cortex_M4_0 (Suspended)
    ti_sysbios_family_arm_m3_Hwi_excHandler__l(unsigned int *, unsigned int)() at Hwi.c:877 0x1003AB88
    0xFFFFFFFC  (no symbols are defined)

So, I believe that our application is becoming trapped in that while loop.


Assuming all of the above is accurate, I'm wondering how we debug this, and how we "plug" an exception handler.  I was able to find very little about this topic in any of the documentation.  There are a few forum posts about other processors, but the process doesn't seem to be quite the same for this platform.  The best thing I've found so far is the ability to change the value of m3Hwi.enableException in the ble_release.cfg file.  Even with it set to true, however, the application then hangs in some Error.c file that CCS still can't find, and my best guess as to the actual path gets me nothing more than another infinite loop, namely Error_policySpin().  There are parameters that may have additional information, but I have no idea how to interpret it.

So, where do we go from here?

  • Hi Chris,

    Typically this can first come up if your board file is not setup appropriately when you are using a custom board. Do you see this issue with the TI provided board files for the launchpad? Can you re-examine to ensure that your custom board files are as they should be?
  • Hello Chris,

    TI RTOS gives you the ability to debug exceptions like this, the most common cause of hardware exceptions are memory leaks and stack overflows. I recommend you follow our debugging guide to find the root of the problem. I am sure you will be able to find te problem if you follow this:

    training.ti.com/.../TIRTOS_CCSDebugging.pdf

    dev.ti.com/.../

    dev.ti.com/.../

    Regards,
    AB
  • Well, I imagine it doesn't happen with the TI files on the TI board, but it doesn't happen on ours until we start doing things with the hardware, like pressing keys on our keypad and beeping with our piezo buzzer.  It's kinda hard to test that on the launchpad because it doesn't have our keypad or buzzer.  And it's not like we're running our custom board files with known errors; if they're not as they should be, it's because we don't know how they should be.

    We can maybe try to see if there are other tasks we could run, such as flash writes or PWM on the LEDs, something that the launchpad can mimic from our hardware.  But, ideally, it would be nice if TI could tell us how to figure out if our board file is not set up appropriately.

  • Perfect, I'll take a look at these and see where it gets us. Thank you!
    I'm already seeing that in the default cfg file (ble_release.cfg), the Error configuration is changed from what is labeled as the "default" to disable all of the error policy stuff. ble_debug.cfg has it enabled, so I guess we should switch to that for debugging. Seems obvious in retrospect, but we just started with whatever simple_peripheral was set to. So, let's see what this does...