wdt best practice

RE: wdt best practice

Allen Foster — Thu, 07 Jan 2016 14:23:38 GMT

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.

RE: wdt best practice

awneil — Thu, 07 Jan 2016 14:09:45 GMT

The trouble, of course, with a WDT that can be stopped once started is that it gives a loophole for faulty software to stop the WDT when it shouldn't!

RE: wdt best practice

Allen Foster — Thu, 07 Jan 2016 13:44:41 GMT

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!

RE: wdt best practice

Hung Bui — Tue, 29 Dec 2015 08:57:32 GMT

@Vandita: Yes, I think it should be fine, watchdog should be feeded in the context with lowest priority (with the timeout longer than the max latency can be created by higher priority interrupts)

RE: wdt best practice

Vandita — Wed, 23 Dec 2015 15:46:39 GMT

Thanks Hung. As I was reading, feeding the dog inside of events/interrupts will also not be a good idea, right? like on_ble_evts. but feeding it from other functions called from main loop after an event has been serviced should be good?

RE: wdt best practice

Vandita — Wed, 23 Dec 2015 15:41:53 GMT

Good point raised. Few minutes after your comment, I even saw an example of where the system was stuck but no reset happened. Thanks for the links as well. Really helpful.

RE: wdt best practice

Hung Bui — Wed, 23 Dec 2015 11:38:29 GMT

Hi Vandita,

I would opt for option 2. I don't really like the idea of using timer to trigger watchdog. Note that the timer interrupt handle will be preempted by the softdevice events. Maybe that's why you see lots of reset before you feed the dog in the on_ble_evt.

I think putting the watchdog in the main loop (that will be returned everytime an event wakes the CPU up) and put the WDT to sleep when the CPU is sleeping is a good choice.

RE: wdt best practice

awneil — Tue, 22 Dec 2015 21:34:03 GMT

The whole point of a WDT is to prevent code execution getting "stuck" or "lost". So using a timer is a particularly bad idea, as the main code can get "stuck" or "lost" while the timer merrily ticks away in the background.

betterembsw.blogspot.co.uk/.../proper-watchdog-timer-use.html