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.

CC2640: Is it possible to initiate a reboot of the CC2640 from inside the execHandlerHook function

Part Number: CC2640

I am having a rare and seemingly random processor hang in my CC2640 Project Zero based project.

The only hang point that I can see in my code could be in the below 'while(2);' loop:

void execHandlerHook(Hwi_ExcContext *ctx)
{
excPC = ctx->pc; // Program counter where exception occurred
excCaller = ctx->lr; // Link Register when exception occurred

while(2);
}

I have not been able to get the program to hang when connected to a Code Composer Studio Debug session in order to debug this hang.

Is there a way to force a CC2640 'reboot' from inside this while(2) loop or function?

If I could force a reboot, then at least my battery would not die when it gets stuck and the reboot should make the device begin working again.

Are there other options for me to consider to get out of this 'hang'?

Thanks,

Dale

  • Hi Dale,

    You can use SysCtrlSystemReset.

    Regards,
    Ryan

  • Thanks Ryan and sorry as I should have found that myself.

    Now I just have to remember to put a breakpoint on that command every time I debug with CCS since debugging sessions don't recover from a reboot (darn I loose one of my few available breakpoints for debugging sessions, maybe I will just put the while(2) loop back in for debugging).

    Dale 

  • Ryan,

    I just realized that likely with this will reset the real time clock counter.

    Do you think that before I call the reset that I could reliably call a function which I use to save the current real time clock counter to some flash memory that we have connected to our CC2640 and then add that saved 'prereset' counter value to the new RTC counter after reboot to keep a continuous RTC counter through the reset?

    I am not sure what state of operating the processor has when execHandlerHook is called...

    Dale

  • You can use the Simple NV for flash storage, this feature is already included inside Project Zero and can be customized to your application's needs.

    Regards,
    Ryan

  • We already have the 8mb flash attached and working for many years.

    My question was more with reference to whether the processor is reliably in a state that we can call my 'saveRTCtoflash' function when it gets into the execHandlerHook function.

    Dale

  • My apologies for not fully understanding what was being asked.  You are correct, there are no guarantees about the state of the device once you are in the exception handler.  It would not be reliable to depend on the "saveRTCtoflash" function to execute correctly each time.  Since the RTC counter is not retained during a reset, you will either need to save its status consistently or use external devices to monitor when and for how long the CC2640 is inactive.

    Regards,
    Ryan

  • So I think if I save my rtc counter to my flash every minute (until I exceed my flashes max number of write cycles :( ) while the processor operates correctly before it gets sent to execHandlerHook function, then on a reboot I just read my flash rtc counter value and add it to the current rtc counter value to make my SysCtrlSystemReset reboot allow uninterrupted rtc within 1 minute resolution per hangup (at least until the next time an iPhone connects over BLE when the rtc counter is converted to a gps time with another flash variable and my times are back in sync for me).

    Thanks again,

    Dale

  • Ryan,

    Any idea how long the Simple NV flash would last before it 'wears out' when continually over-writing the same 32 bits every minute?

    Thanks,

    Dale

  • According to the Datasheet, there are a minimum of 100k flash erase cycles before failure but no information about write cycles.  The NV driver is written in a way to avoid erasing the flash as much as possible. To do this, the driver duplicates the data instead of overwriting them.  

    https://e2e.ti.com/f/1/t/986155 
    https://e2e.ti.com/f/1/t/840383 

    Regards,
    Ryan