Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem



Posted by mbedded on November 9, 2017

Is there recommended way to have all or most tasks inhibit the watchdog kick ? So if anyone task hangs, the watchdog will reset the system


Posted by richard_damon on November 9, 2017

What I typically do is have every task that should be executing periodically set a different bit in a word (guard the setting with a critical section), and a low priority (maybe even in the idlehook) check the word for all the bits set, and if so clear them and kick the watchdog. If any task doesn't run, or something hogs the processor, the watchdog will reset the system.

Not every task in the system will get a bit, as some tasks might not be expected to run periodically, but you can also add a check that there isn't a pending request for those tasks.


Posted by rtel on November 10, 2017

Taking Richard D's suggestion further - most of the important tasks in the FreeRTOS demos increment a counter, then a central 'check' task ensures that all the expected counters are counting at the expected state before kicking the dog.


Posted by mbedded on November 10, 2017

Thanks and appriciated.


Posted by ayazar on November 10, 2017

I think this could be an alternative: The monitor task has the highest priority and tasks that are expected to run periodically send an event or put a message in a "monitor queue" in each period. Then the monitor task periodically (possibly with a wider period) check messages. If a task fails, it can even restart it using task API functions or inform the user or logs it.

This approach may have an advantage over Richard's suggestion because when monitor task has the lowest priority (like idlehook), it can't run if another task is stuck in while() loop due to scheduler algorithm. The only way to reset processor is hardware watchdog as Richard's mentioned. But this may not be informative for developer.

The best way may be a monitor task with the highest priority + watchdog timer reset in case of scheduler crash due to coding error.

Best, Alper


Posted by richard_damon on November 10, 2017

I would rarely find the highest priority proper for the watchdog task. I often have a couple of operations with very tight time budgets that need to be made topmost priorities, and making them compete with the watchdog task, which does NOT have that sort of tight time line. Placing it below the very time critical tasks but above the tasks with human scale timing, does give you the ability to try to detect the problem and report it before the watchdog resets you, but then I would want to add a chek that the idle hook does get some time to catch the case that some low priority task that maybe can't be directly monitored, because it isn't regularly active doesn't lock up the system.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner