wdt best practice

[Vandita]

Hey,

I have been trying to set up wdt for my application which services some interrupts once in a while and advertises continuously. I put the nrf to sleep using sd_app_evt_wait() function. I am using a custom board with nrf51822.

I followed two different approaches and both work fine. So, I was wondering which one is a better practice for a good embedded application (low power and reliability are both important).

Approach 1-> Using a timer to reload: In this approach, I created a timer just to reload the WDT and start it just before initializing the WDT.

->In this approach, I was seeing a lot of unwanted resets around the time there was a BLE advert timoeout. I then added a line in the on_ble_evt(ble_evt_t * p_ble_evt) function to feed the dog. That helped.

->Sometimes, it would reset without reloading even once (just after start up). I then explicitly started the lfclk and haven't seen this issue in a bit.

Approach 2-> Reloading in main while loop: I reload the wdt in the loop in main but as I have sd_app_evt_wait() right after that, I have changed WDT_CONFIG_SLEEP_Run to WDT_CONFIG_SLEEP_Pause. So, as per my understanding, wdt is paused when the system goes to sleep and my main loop feeds it after any event. As there is no timer and the wdt is running and fed only when there's an event, it should save power as well.

Questions. 1) In approach 1, if any other events take long enough and casue reset, is it good practice to feed the wdt from inside such events/functions? 2) Which of these approaches is a good practice for a reliable and power efficient application?

Thanks, Vandita

The attachment shows both approaches: wdt.c

[Allen Foster]

Hi Nordic,

Do you have any plans to change the WDT so that it's period can be changed, or that it can be disabled once started?

Whilst I agree in principle that a WDT should always be well integrated and serviced in an embedded system there are cases when it would be extremely useful to be able to disable it. The reality of modern FOTA updated embedded systems is that HW and FW issues arise that often require careful workarounds in firmware. Having a WDT that is locked out from changes once enabled is poor and inflexible design in my opinion.

I say this as someone with 10+ years RTL and firmware design experience working on media entertainment SoC designs.

Please change this in future versions of the device!

[Allen Foster]

Yes, by writing to a specific WDT register. There are just as many other ways I could break a system with 'faulty software' by writing to specific memory or register locations, it should be noted that a WDT would not necessarily be able to recover from these.