WDT causes reboot loop when underflow occurred once

Hello,

Thanks for reaching out Renesas Engineering Community!

Are you calling  in your code the Refresh API to refresh the timer and prevent the counter underflow to prevent the reset?

Please, check how this is done in the example provided in the documentation of the r_wdt module.

https://renesas.github.io/fsp/group___w_d_t.html#gad64d0778fd0ceccb13a7287bb0d1fca8

Could you please share with us some sample code to check?

Best Regards,

IK

Hello,

In my use case the watchdog has to b disabled until the user says that you can enable it.

I use R_WDT_Refresh to refresh the counter. When there has been an underflow due to e.g. an endless loop, the MCU restarts but the watchdog remains enabled. And it will constantly reboot, even if after restarting the MCU the watchdog in code was not started. Only solution for this is to unpower the mcu.

In case I enable the watchdog at startup of the MCU (without waiting for the user's command) I also end up in a reboot loop. While I regularly refresh the watchdog via R_WDT_Refresh.

static wdt_instance_ctrl_t g_wdt_ctrl;
static wdt_cfg_t g_wdt_cfg =
{
    .timeout = WDT_TIMEOUT_8192,//WDT_TIMEOUT_2048,
    .clock_division = WDT_CLOCK_DIVISION_128,
    .window_start = WDT_WINDOW_START_100,
    .window_end = WDT_WINDOW_END_0,
    .reset_control = WDT_RESET_CONTROL_RESET,
    .stop_control = WDT_STOP_CONTROL_ENABLE,
    .p_callback = NULL,
};

void SystemEnableWatchdog(void)
{
   R_SYSTEM->RSTSR1_b.WDTRF = 0; //Clear watchdog timer reset detected flag
   
   if(peripheral_b_clock_initialized == false)
   {
      return;
   }
  
   /* (Optional) Enable the WDT to count and generate NMI or reset when the
     * debugger is connected. */
   R_DEBUG->DBGSTOPCR_b.DBGSTOP_WDT = 0;

   R_WDT_Open(&g_wdt_ctrl, &g_wdt_cfg);

   R_WDT_StatusClear(&g_wdt_ctrl,WDT_STATUS_UNDERFLOW_AND_REFRESH_ERROR);
   
   System_KickDog();
} 

void System_KickDog(void)
{
    R_WDT_Refresh(&g_wdt_ctrl);
}

Kind regards

ND

Hello sir,

As far I can understand your request is to be able to choose in your application when the WDT timer will be enabled and a reset will occur. Am I right?

I am sorry but from the information you have provided me I cannot understand much to see what is going wrong in your project and the reset due to watchdog underflow occurs even though it is not enabled by the user.

However I have created a simple example for you which I think demonstrates what you want to achieve. The example is for RA8D1.

Let me provide some details about the example:

Here are the configurations for the r_wdt stack added in Stacks Tab:

The example uses other two stacks a GPT timer stack r_gpt and the r_icu stack to trigger an external interrupt every time button S2 is pressed.

The timer is configured to overflow every one second and I have set a callback function which occurs every second to refresh the WDT timer counter and prevent the underflow and reset event.

If the user presses button S2 an external interrupt will be triggered which will stop the timer, so it will stop refreshing the WDT Timer, which will have as a result the WDT timer to be counting down and as soon as the underflow event occurs a reset due to watchdog will occur.

Also in hal_entry function in the beginning of the application I am checking the RSTSR1_b.WDTRF  flag to check if it gets value 1 after the reset and see if the reset occurs due to WDT. Also  when the reset occurs the red led turns on for a while to indicate that the reset due to watchdog occurred.

Check also the printed messages on RTT Viewer for logging:

So every time I press button S2 the WDT is enabled and reset occurs, as you requested controlled by the user.

Something else I would like to mention here is that users generally must be very careful of  when they select to refresh the WDT counter to prevent underflow and reset.

Also if for example I set the timer GPT period to a period bigger than the time that it is required to the underflow event to occur on the WDT timer, I also get unexpected resets which are not enabled by the user.

Find the example below.

Hope it will help you proceed.

wdt_example_RA8D1.zip

Best Regards,

IK

Hello IK

Thanks for the reply

It is correct that the user determines if the WDT should be enabled or not.

I can't get your example project open, but looking at the code I don't immediately see a difference with my code in how the WDT is set.

What I observe is that as long as the user does not enable the WDT, the MCU operates normally and does not reset. The moment the WDT is switched on 1 time then the watchdog remains switched on because it enters a reset loop. Even if you did refresh on time.

I would expect that after the reset, the WDT remains switched off until the user switches it back on, which is not the case. Only by a power cycle can you stop the reboot loop.

Looking at the reason for reset in the registry, it was a software reset instead of a watchdog underflow reset.

Also, I note that in R_WDT_Open the values are not written into the registers R_WDT->WDTCR and R_WDT->WDTCSTPR, is there a protection bit or power bit that I am overlooking? The WDT is in register start mode.

What I also noticed is that when the user didn't enable the WDT and next the debugging is stopped, we also get in a reset loop.

Kind regards

ND

Hello ND,

I tested again the project I have sent you. And it opens properly in e2studio. Have you checked the register values after calling the Open API while being in Debug mode?

Basically as explained before the project I have sent you  has a timer which every 1 seconds refreshes the WDT timer to prevent underflow and reset.

And the user can enable the WDT by pressing button S2 where an interrupt is triggered and inside this interrupt the GPT timer stops, so the code does not enter  the timer's callback and the WDT counter does not refresh no more periodically which has as a result a WDT reset to occur.

Please share with me your configuration.xml file to check your settings in BSP tab and r_wdt stack.

Thanks.

Best Regards,

IK

Hello IK

Thanks for the reply

I reinstaled e2studio and now i can open your project (I normally use IAR).

We found the problem and the WDT now works as we wanted it to.

A bug in our code caused the wdt timer to always refresh on start-up, with the result that we could no longer write to the WDT configuration registers.

As long as the user did not give the command to start the WDT then the WDT was off. But as soon as the user started the WDT then it kept running. This was because if an underflow happened and a reset occurred. The WDT stays on but waits to run again until the first time you perform a refresh. By doing this refresh on startup (even before you call the WDT open API) the WDT started running (we don't want this) and that caused another reset due to an underflow and so we got into a loop.

Setting the define WDT_CFG_PARAM_CHECKING_ENABLE to 1 helps revealing the problem.

Thanks for helping me investigate the problem

Kind regards

ND

Hello IK

Thanks for the reply

I reinstaled e2studio and now i can open your project (I normally use IAR).

We found the problem and the WDT now works as we wanted it to.

A bug in our code caused the wdt timer to always refresh on start-up, with the result that we could no longer write to the WDT configuration registers.

As long as the user did not give the command to start the WDT then the WDT was off. But as soon as the user started the WDT then it kept running. This was because if an underflow happened and a reset occurred. The WDT stays on but waits to run again until the first time you perform a refresh. By doing this refresh on startup (even before you call the WDT open API) the WDT started running (we don't want this) and that caused another reset due to an underflow and so we got into a loop.

Setting the define WDT_CFG_PARAM_CHECKING_ENABLE to 1 helps revealing the problem.

Thanks for helping me investigate the problem

Kind regards

ND

Hello ND,

We are glad to hear that your issue is solved! And thank you for providing the solution with us, since your reply can be useful for someone else facing similar problem with you.

Best Regards,

IK