MKV4x Watchdog refresh problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MKV4x Watchdog refresh problem

Jump to solution
2,533 Views
agostinofacotti
Contributor III

Hi,

I'm trying to add the watchdog on a MKV42F128VLH16 but i noticed the following issue:

- when the refresh happens too frequently the watchdog causes reset.

Trying more I see that adding a small for loop that eat time resolves the problem.

Someone has an idea on why this happens?

I'm attaching a sample project that shows the two behaviour; in main():

- with the "#if 0" the MCU reset after the timeout period;

- changing "#if 0" to "#if 1" the refresh is correct.

1 Solution
2,054 Views
mjbcswitzerland
Specialist V

Hi

I think that what you are experiencing is a general characteristic of the watchdog.

pastedImage_1.png

It may be that the refresh mechanism is not being fully respected (first point) but it may also be that the window mode is enabled (second point).

However I believe that triggering very quickly also triggers a reset since this has been reported a number of times and it happens on all chips with this watchdog type.

My assumption is that even when the window mode is disabled there is still something that doesn't allow two writes within (possibly) the 20 bus cycle window that a trigger uses. Adding a small delay solves it. good should not usually be an issue because if there is a watchdog mechanism (eg. low priority task) doing it at a periodic rate it will never trigger it quickly

To conclude - as long as the rules as above are being respected, what you see looks to be "typical" but not un-documented behavior.

Regards

Mark

uTasker developer and supporter (+5'000 hours experience on +60 Kinetis derivatives in +80 product developments)
Kinetis: http://www.utasker.com/kinetis.html

View solution in original post

4 Replies
538 Views
Lav30307
Contributor I

Hi,

I am using MKV11Z64 MCU. I have configured the watchdog as follows.

SIM->WDOGC = SIM_WDOGC_WDOGCLKS(0); //clock LPO
WDOG->UNLOCK = WDOG_UNLOCK_WDOGUNLOCK(0xC520); /* Key 1 */
WDOG->UNLOCK = WDOG_UNLOCK_WDOGUNLOCK(0xD928); /* Key 2 */
WDOG->STCTRLH = WDOG_STCTRLH_ALLOWUPDATE_MASK | 0x0100;

/*clk 1kHz for 100msec */
WDOG->TOVALL = 100;
WDOG->STCTRLH |= WDOG_STCTRLH_WDOGEN_MASK;

If the refresh register updates every 7msec it works fine no reset. But the problem is when the refresh register updates every 101msec it works fine without resetting after crossing the set time limit. 

Thanks & Regards,

Lavanya

0 Kudos
2,054 Views
lenshustek
Contributor II

I independently discovered the same bug (a watchdog refresh that is too frequent is ignored and causes a reset) with the MK64FX512VMD12 processor. A similar issue for Silicon Lab processors, with some proposed workarounds, is discussed here: WDT_E101 - Restrictions on Watchdog Timer Refresh Interval .

I came up with a different workaround that doesn't require the addition of delays: check the watchdog timer counter, and if it hasn't incremented by more than 2 since the last refresh, don't do another refresh. Here's the code snippet (modified to avoid compiler promotion to 32 bits), which seems to fix the problem:

static uint16_t last_timerlow = 0;
noInterrupts();
uint16_t current_timerlow = WDOG_TMROUTL;
if ((uint16_t)(current_timerlow - last_timerlow) > 2) { // don't refresh too frequently
   last_timerlow = current_timerlow;
   WDOG_REFRESH = 0xa602; // this two-part refresh sequence must complete within 20 cycles
   WDOG_REFRESH = 0xb480; }
interrupts();

2,055 Views
mjbcswitzerland
Specialist V

Hi

I think that what you are experiencing is a general characteristic of the watchdog.

pastedImage_1.png

It may be that the refresh mechanism is not being fully respected (first point) but it may also be that the window mode is enabled (second point).

However I believe that triggering very quickly also triggers a reset since this has been reported a number of times and it happens on all chips with this watchdog type.

My assumption is that even when the window mode is disabled there is still something that doesn't allow two writes within (possibly) the 20 bus cycle window that a trigger uses. Adding a small delay solves it. good should not usually be an issue because if there is a watchdog mechanism (eg. low priority task) doing it at a periodic rate it will never trigger it quickly

To conclude - as long as the rules as above are being respected, what you see looks to be "typical" but not un-documented behavior.

Regards

Mark

uTasker developer and supporter (+5'000 hours experience on +60 Kinetis derivatives in +80 product developments)
Kinetis: http://www.utasker.com/kinetis.html

2,054 Views
agostinofacotti
Contributor III

Hi Mark,

thanks for the answer: i agree with you!

Doing some other test i see that:

- if the WDOG_Refresh() is placed into a 1ms interrupt the MCU still reset, while

- if in the same interrupt the WDOG_Refresh is divided in frequency by 2 or more (one yes, one no) all is ok.

Perhaps it could be related to the clock frequency of the watchdog (in my case it is the LPO oscillator, 1kHz) in addition to what you correctly say about the 20-bus-cycle triggering window.

Regards,

agostino

0 Kudos