FreeRTOS and traditional Watchdog Timer funct

joconnor37 wrote on Monday, October 15, 2007:

Could I broach the general subject of Watchdog Timer functionality when using FreeRTOS? I have completed a few modest real-time embedded systems projects with PIC 18Fxxxx MCUs over the last few years, always without a RTOS. I used the traditional "super loop", switch statements controlled by system states etc, etc. I always implemented the Watchdog Timer "liberally" at portions of the code.

I think to similarly liberally implement the Watchdog Timer still in FreeRTOS based projects - e.g. start the Watchdog Timer at start of a "potentially problematic" function such as a read/write on the I2C bus, so that in event of "failure" the program gets kicked out of the function by a Watchdog Timer reset. This resets PC back to first executable. Any thoughts on the ramifications of this when using FreeRTOS? Should the Watchdog Timer functionality be at the "task level" or remain at the "C function level", for example?

Kind Regards,

John O’Connor

rtel wrote on Monday, October 15, 2007:

There are many different ways of using a watchdog timer in multi threaded applications.  Some are quite complex, but unless you have a safety critical system I would suggest keeping things simple. 

Unlike your previous single threaded applications your watchdog should look for hangs or errors within individual functions, and within the scheduler itself (not that the scheduler will ever go wrong of coarse :o).

One technique for this to have a watchdog variable within each task - this could be Boolean or a counter, I normally use the latter.  For example, each task increments a counter at strategic places within the code, then a higher priority task (or a tick hook) periodically checks that all the counters within the system are still incrementing.  If all counters are incrementing then the watchdog is kicked.  If any counters unexpectedly retain their value for a period of time then it is assumed that the task is bad in some way, and the watchdog is stopped (or the system [or just the task] manually reset in software, the watchdog then being a back for a total failure).  If a task finds an error in its function it simply stops incrementing its counter.  If a task hangs, then the counter will stop automatically.

This mechanism is implemented in a basic way by the demo applications that come with each port.  Most of these implement a ‘check’ task, or ‘check’ hook function.  This looks at all the other tasks to ensure they are running as expected.  In this case though, rather than using a watchdog to fix an error, the check task simply outputs some signal (LED or LCD) to indicate that an error has been found.

You could use the idle task to check the other task are still running.  This will then also ensure that the system is not overloaded.  If the idle task ever gets starved out then the watchdog will fire.

Hope this helps.


joconnor37 wrote on Monday, October 15, 2007:


Many many thanks. Most helpful.

Kind Regards,

John O’Connor

hanishmaghu wrote on Thursday, April 18, 2013:

I have implemented watchdog timer driver using freertos on LPC1114 (NGX Base Board). I have used the problem statement above and a task whose priority is set to be idle task priority is monitoring 4 tasks where a counter is incremented. If the counter in any of the tasks stops then the idle task doesn’t feed the watchdog timer and the system is reset by watchdog.We have implemented this as watchdog timer service as in the tasks which the developer thinks are very critical are the ones that feed idle task which further feeds watchdog timer counter.
We also wrote driver for watchdog and LCD also we measured**_ interrupt latency of freertos_** which came out to be 1.73 micro seconds. link to the source code is as follows(it contains a readme.txt which basically describes the working of source code).