I'm using an MK10MK10DN512LVQ10 with the SDK v2.2.0 in Mcuxpresso 11.3.0
I'm having problems with the watchdog module. I don't know if it is the configuration or what is really happening. I added the watchdog peripheral driver and I have the following configuration for it:
The generated code for initializing it looks like this:
const wdog_config_t Watchdog_config = {
.clockSource = kWDOG_LpoClockSource,
.prescaler = kWDOG_ClockPrescalerDivide1,
.timeoutValue = 1000UL,
.enableWindowMode = false,
.windowValue = 0UL,
.enableUpdate = true,
.enableWdog = true,
.workMode = {
.enableWait = true,
.enableStop = false,
.enableDebug = false
},
.enableInterrupt = false
};
static void Watchdog_init(void) {
/* WDOG peripheral initialization */
WDOG_Init(WATCHDOG_PERIPHERAL, &Watchdog_config);
}
The code is executing that initialization correctly.
I have the following in main:
int main(void)
{
if (RCM_GetPreviousResetSources(RCM) & kRCM_SourceWdog)
{
while (1);
}
/* Init board hardware. */
BOARD_InitBootPins ();
BOARD_InitBootClocks ();
BOARD_InitBootPeripherals ();
#ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL
/* Init FSL debug console. */
BOARD_InitDebugConsole ();
#endif
PRINTF ("Hello World\n");
/* Force the counter to be placed into memory. */
volatile static int i = 0;
/* Enter an infinite loop, just incrementing a counter. */
while (1)
{
WDOG_Refresh(WATCHDOG_PERIPHERAL);
i++;
/* 'Dummy' NOP to allow source level single stepping of
tight while() loop */
__asm volatile ("nop");
}
return 0;
}
I let the code run and put a breakpoint inside the if (RCM_GetPreviousResetSources(RCM) & kRCM_SourceWdog) then after 1 second, which is my watchdog timeout, the execution hits my breakpoint despite calling WDOG_Refresh(WATCHDOG_PERIPHERAL); inside the while loop.
Also, I can verify that the watchdog timed out by looking at the peripheral view:
I also noticed that the watchdog value is not changing when running the code. It stays at 0x3e8 (1000) all the time.
But that doesn't make sense, shouldn't it be decrementing and then resetting the board when it reaches 0? Or does that register only holds the value that the watchdog timer references to?
What am I missing?
Solved! Go to Solution.
@kerryzhou thanks for helping.
Your comment helped me make one important change. You said:
Please add some delay after WDOG_Refresh, as I know, refresh very quickly will also cause the watchdog reset.
So I added a PRINTF and a simple for loop to add time between wdog refreshes. Now the loop looks like this:
while (1)
{
WDOG_Refresh(WATCHDOG_PERIPHERAL);
PRINTF ("wdog refreshed %lu times\n", (uint32_t)i);
for (uint32_t j = 0; j < 1000; j++){}
i++;
/* 'Dummy' NOP to allow source level single stepping of
tight while() loop */
__asm volatile ("nop");
}
And now it's working properly. The execution doesn't get reset by the wdog.
You are welcome!
Any new question in the future, welcome to create the new question post in the kinetis community.
Our Kinetis engineer will help you!
Best Regards,
Kerry
Hi m4l490n,
Really thanks for your cooperation.
1. Change your timeout data to be longer, eg, 5s.
Just make sure your WDOG is long enough for the first time WDOG_Refresh.
2. in your while(1)
while (1)
{
WDOG_Refresh(WATCHDOG_PERIPHERAL);
i++;
/* 'Dummy' NOP to allow source level single stepping of
tight while() loop */
__asm volatile ("nop");
}
Please add some delay after WDOG_Refresh, as I know, refresh very quickly will also cause the watchdog reset.
3. About your checking with WDOG_TOVAL, that is not correct, this is used to define the timeout value, it will never count down, I think you need to check TMROUT register.
4. BTW, you also can check the SDK watchdog code, compare with your generated code, just make sure the watchdog configuration is the same.
From your test result, seems the first timeout is before the successful calling of WDOG_Refresh, although your breakpoint runs to WDOG_Refresh, So, I suggest you use long timeout, and test it again, if the WDOG_Refresh is not valid, no matter how long timeout, it will get the watchdog timeout.
Any updated information from your side, just kindly let me know.
Best Regards,
Kerry
@kerryzhou thanks for helping.
Your comment helped me make one important change. You said:
Please add some delay after WDOG_Refresh, as I know, refresh very quickly will also cause the watchdog reset.
So I added a PRINTF and a simple for loop to add time between wdog refreshes. Now the loop looks like this:
while (1)
{
WDOG_Refresh(WATCHDOG_PERIPHERAL);
PRINTF ("wdog refreshed %lu times\n", (uint32_t)i);
for (uint32_t j = 0; j < 1000; j++){}
i++;
/* 'Dummy' NOP to allow source level single stepping of
tight while() loop */
__asm volatile ("nop");
}
And now it's working properly. The execution doesn't get reset by the wdog.