Maximum Reload time for WDT

[Shagan]

Hi Guys, 

We have a need to send data every 4 hours. 

In order to do this, we sleep 1 hour at a time (1-hour timer - single shot) and increment counter, and when the count is 4 we send the data. This is working well. 

Due to unknown reasons the device sometimes can get hung when trying to send the data. 

Our plan was to set the WDT_CONFIG_RELOAD_VALUE to 120000000, to make sure we reset the device after 1 hour if it got stuck. 

But we are unable to provide values more than 600000 (which triggers at 100 seconds). 

Can u suggest a way to configure such a large interval? 

regards

Shankar

[Shagan]

Good catch! yes, that is exactly I think what's happening. 

Is this a bug? How do we handle this then?

[RK]

I'd call that a bug, yes. Possibly never noticed as people tend to run the watchdog for seconds or possibly minutes and not hours. 

well .. me I'd just not use the driver and program the registers directly, it's not a very complex peripheral. The hardware abstraction is nice but honestly for what you want it's what .. 20 lines of code? 

I'm sure one of the Nordic guys on this thread .. well Kenneth :) will report it as a bug but I don't know if you're likely to see it fixed before you need it so I would just roll my own. 

[Shagan]

Gotcha, 
Is there an official place to see how to program the registers directly to achieve this? 

[RK]

well no not really. You should read the nRF datasheet which documents the registers, if you want to set them directly it'll be something like WDT->CRV = 0x12345678. Alternatively if you check through the code for the current watchdog module, the one I took that line above from, you can take that as an example, it's short, and it uses the hardware abstraction functions like nrf_wdt_reload_value_set() to actually write the registers. This should be simple enough that just looking at that code should be enough. 

[Kenneth]

Thanks for the details RK! I have reported the WDT overflow calculation internally now. It will take some time to fix this as always, so directly writing to WDT registers as you suggest is the way to go for now.

Best regards,
Kenneth