• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 435 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2640R2F: Detecting a watchdog timeout as reset source

Hester Corne
Intellectual 790 points

Part Number: CC2640R2F

Hi,

I'm configuring the watchdog to reset my device after the desired timeout.  From reading the reference manual (rev. H), I can see that the PRCM:WARMRESET register will indicate whether the watchdog timeout or CPU lockup have occurred.  I can also see that TI strongly recommend to upgrade the warm reset triggered by the watchdog into a pin reset, using the WR_TO_PINRESET field.  

I have a basic project set up to test this which involves writing the reset source and warm reset registers to flash for later inspection.  If I don't set WR_TO_PINRESET, nothing gets into flash so I'm led to assume that the device isn't properly being reset.  Now I understand why TI recommend setting this bit. 

If I set WR_TO_PINRESET to 1, I get my flash entries so the reset must be working.  However, the WARMRESET register value is always 0. 

How can I detect whether it was the watchdog or the lockup that caused the warm reset?

Thanks,

Hester

  • 0
    Guru 86865 points

    Hi Hester,

    To conveniently convert the WARM Reset to System Reset, Just call HAL_SYSTEM_RESET() or SysCtrlSystemReset() at watchdog callback. Its good idea to put a led indicator on power up to know the device resets. Also make sure the CC2640R2F board is externally powered.

    -kel

  • 0 in reply to Markel Robregado
    Intellectual 790 points

    Hi Kel,

    Even if I did that, wouldn't the WDT_STAT bit still be cleared by the reset itself? I specifically would like to detect the cause of the warm reset at startup if that's possible.

    Thanks,

    Hester

  • 0 in reply to Hester Corne
    Guru 86865 points

    Hi Hester,

    Can you elaborate further. A watchdog reset will cause WARM RESET. But if you call HAL_SYSTEM_RESET() or SysCtrlSystemReset() at watchdog callback the reset cause will be SYSTEM RESET

    If you mean to know the cause of watchdog reset, maybe you can save information at watchdog callback and then prevent the watchdog device reset by calling Watchdog_clear().

    Another you can do is UART logging.

    -kel

  • 0 in reply to Markel Robregado
    Intellectual 790 points

    Hi Kel,

    I want to be able to detect at startup whether it was the watchdog that caused the warmreset - the reference manual implies you can use the WDT_STAT bit to determine this, but if I follow the recommendation in the manual, I promote the warmreset to a pin reset, and this bit is cleared.  I just wanted to find out whether there was an alternative register or something I could use to identify the watchdog as the source of reset as opposed to CPU lockup.

    There are ways to do this in application logic, but just wanted to rule out an in-built mechanism before going down that path.

    Thanks,

    Hester

  • 0 in reply to Hester Corne
    TI__Guru 58425 points

    Hi Hester,

    There is no way to carry over this information when the warm reset is routed over to a pin-reset (as this is expected to reset the whole device). You could possibly leave the "warm to system" option off and catch your warm resets and then make proper system resets after identifying the cause.