Odd WDT behavior

[eyalasko]

Hi, 

We have an freertos based app (SDK14.2).

Recently we have added a WDT support in the following manner:

1. The init code initializes the WDT reload value to T+3 seconds (currently 13 sec), run in Sleep, pause in Halt. This is done in main() BEFORE the freertos kernel is started
2. Each task's handler requests WD channel just prior to entering the task's while(true) loop
3. The last task that gets WDT channel (channel num == # of tasks (==6)) also enables the WDT
4. Each task loop is tuned to run every (up to) T seconds (currently 10 sec due to power constraints)
5. It is planned that if any of the tasks hangs/asserts, it will not feed its respective channel and the system will WD reset within 13 sec at most.

Occasionally we encounter an odd behavior that the WDT fires with no apparent reason in the first few seconds from system boot.

I tried to single step the WDT initialization code and noticed that some registers are NOT zero upon startup as if they remain set from last debug session:

e.g. - these are the values after device startup just BEFORE calling nrf_drv_wdt_init() (see screen cap attached)

- REQSTATUS = 0x0000000F   <<< What this register is used for ???

- RUNSTATUS = 0x00000001

- RREN = 0x0000003F (6 channels enabled)

- INENSET/INTENCLR = 0x00000001

- CRV = 0x00068000 (13 sec)

It seems that the WDT module retains values from prev debug session.

Can it explain the premature firing? Is it reasonable that the WD counter keeps running from the last value it was at before the reset and hence firing prematurely ???

Thanks

[Kenneth]

Yes, likely there is a soft reset during debug mode in this case to re-start the application, a soft reset will not reset WDT. A pin reset, power on reset, brown out reset, and watchdog reset will reset the WDT.

[eyalasko]

Thanks.

So if I understand you correctly the WDT keeps running after soft reset even if its not (re) configured?

If so, is there a way to stop-restart it programmaticly so it will not interfer with debugging ?

Also, 

What REQSTATUS flags are used for?

Thanks again

[eyalasko]

eyalasko said:

What REQSTATUS flags are used for?

I think I figured it out - 

If any of the enabled channels REQSTATUS bits is '1' when the timer elapses, WD reset will fire ???

Hence looking at the '1's on (watchdog) startup may suggest on the hanged task .

(Alternatively when channels is 'fed', it turns '0'. When all (enabled) flags are 0, the timer's count  resets to CRV)

Can you confirm?

[Kenneth]

It is not possible to stop-restart it programmaticly, however you can in the CONFIG register configure "Pause watchdog while the CPU is halted by the debugger". This may help? 

eyalasko said:

Hence looking at the '1's on (watchdog) startup may suggest on the hanged task .

That is my understanding also yes. 

[eyalasko]

Kenneth said:

however you can in the CONFIG register configure "Pause watchdog while the CPU is halted by the debugger"

I'm doing this, however upon startup it takes several seconds until all tasks are initialized and their task loop begin to run (and feed the WD RR channels)

If for some reason the WD counter does not start from CRV=13 sec (e.g.if being stopped-restarted by the debugger), the system will experience WD reset as not all of the tasks WD feeding kicked in