WDT Callback didn`t execute when the system reset

Hello,

I am using nRF Connect SDK v2.9.0, and nRF54l15 board. I enabled the watchdog timer and used its driver in zephyr/drivers/watchdog.h

It seems to work fine. The reset happens after the WDT fires. But my problem is that the WDT callback seems to be not executed. Here is my WDT callback 

static void wdt_callback(const struct device *wdt_dev, int channel_id)
{

    __asm volatile (
        "mov r0, sp\n"            // Load SP into r0
        "str r0, %0\n"            // Store SP in gstr_wdt_fault_data_2.current_sp

        "mov r0, lr\n"            // Load LR into r0
        "str r0, %1\n"            // Store LR in gstr_wdt_fault_data_2.current_lr
        :
        : "m" (gstr_wdt_fault_data_2.current_sp),
          "m" (gstr_wdt_fault_data_2.current_lr)
        : "r0"
    );
)
gstr_wdt_fault_data_2 is stored in noinit section. So, I should get these values after resetting but I always got them with value zero.
I implemented the code of getting sp and lr in assembly as I read this note on the watchdog sample 
 * the reset occurs, which is too short for this sample to do anything
 * useful.  Explicitly disallow use of the callback.
 */
So, it should be fast and executed as it is assembly. How can I make sure the callback is executed.and how can I solve my issue

Parents Reply
  • It would have to be stored to NV memory (RRAM) to be retained through the reset, but you would have to stop the WD to have time to store the data to flash.  Alternatively you can consider using the task watchdog with the HW WD as fallback https://docs.zephyrproject.org/latest/services/task_wdt/index.html. I assume you will also need to rely on the low level nrfx APIs to store the data to RRAM to allow it to be performed from the ISR. 

    Nedaa_H_Ahmed said:

    I have another question please, how can I make sure that the callback is called 

    I added only this line in the WDT callback to indicate that the callback is executed but the LED didn`t turn on

    Even if the callback is invoked, the led glitch may be too short to notice. I suggest placing a breakpoint in the callback.

Children
Related