Watchdog task pattern in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Watchdog Task Notification Behavior

Consider a FreeRTOS system with a watchdog task waiting for notifications from multiple worker tasks. What will be the output of the watchdog task if it uses xTaskNotifyWait with ulBitsToClearOnEntry = 0 and ulBitsToClearOnExit = 0xFFFFFFFF, and two worker tasks notify it with bits 0x01 and 0x02 respectively before the watchdog calls xTaskNotifyWait?

FreeRTOS

/* Watchdog task snippet */
uint32_t ulNotificationValue = 0;
BaseType_t xResult = xTaskNotifyWait(
    0,          // ulBitsToClearOnEntry
    0xFFFFFFFF, // ulBitsToClearOnExit
    &ulNotificationValue,
    0           // xTicksToWait
);
// Print notification value
printf("Notification value: 0x%02X\n", ulNotificationValue);

A Notification value: 0x01

B Notification value: 0x00

C Notification value: 0x02

D Notification value: 0x03

💡 Hint

Remember that xTaskNotifyWait accumulates bits set by multiple notifications if ulBitsToClearOnEntry is zero.

Since ulBitsToClearOnEntry is zero, the notification value is not cleared before waiting. Both notifications set bits 0x01 and 0x02, so the accumulated value is 0x03. After reading, ulBitsToClearOnExit clears all bits.

🧠 Conceptual

intermediate

Purpose of Watchdog Task in FreeRTOS

What is the main purpose of implementing a watchdog task pattern in a FreeRTOS-based embedded system?

A To increase the CPU clock speed dynamically based on workload.

B To handle all hardware interrupts in the system centrally.

C To monitor other tasks and detect if any task has stopped responding or is stuck.

D To allocate memory dynamically to tasks at runtime.

💡 Hint

Think about system reliability and fault detection.

The watchdog task monitors the health of other tasks by expecting periodic signals. If a task fails to signal, the watchdog can take corrective action like resetting the system.

🔧 Debug

advanced

Debugging Watchdog Task Starvation

A watchdog task in FreeRTOS is supposed to run every 100ms to check system health. However, it never runs and the system hangs. Which of the following is the most likely cause?

FreeRTOS

void WatchdogTask(void *pvParameters) {
    for (;;) {
        // Check health
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

// System initialization
xTaskCreate(WatchdogTask, "Watchdog", 128, NULL, 1, NULL);
// Other tasks with priority 2 running continuously without delay

A Other higher priority tasks are starving the watchdog task by never yielding or delaying.

B The watchdog task stack size is too large causing memory overflow.

C The watchdog task priority is higher than other tasks causing deadlock.

D The watchdog task is missing a call to vTaskStartScheduler().

💡 Hint

Consider task priorities and CPU time allocation.

If higher priority tasks never block or yield, the lower priority watchdog task will never get CPU time, causing it to starve and never run.

📝 Syntax

advanced

Correct Use of Task Notifications for Watchdog

Which of the following code snippets correctly sends a notification bit to a watchdog task from a worker task in FreeRTOS?

A xTaskNotify(watchdogHandle, 0x01, eSetBits);

B xTaskNotify(watchdogHandle, 0x01, eNoAction);

C xTaskNotify(watchdogHandle, 1, eSetValueWithOverwrite);

D xTaskNotify(watchdogHandle, 0x01);

💡 Hint

Check the notification action parameter to set bits.

Using eSetBits sets the specified bits in the notification value, which is the correct way to signal a watchdog task bit.

🚀 Application

expert

Designing a Watchdog Task for Multiple Worker Tasks

You need to design a watchdog task that monitors 4 worker tasks. Each worker task must notify the watchdog every 500ms by setting a unique bit (bit 0 to bit 3). The watchdog task runs every 1 second and checks if all bits are set. If any bit is missing, it triggers a system reset.

Which of the following watchdog task code snippets correctly implements this logic?

FreeRTOS

void WatchdogTask(void *pvParameters) {
    uint32_t ulNotificationValue;
    for (;;) {
        if (xTaskNotifyWait(0xFFFFFFFF, 0xFFFFFFFF, &ulNotificationValue, pdMS_TO_TICKS(1000)) == pdTRUE) {
            if ((ulNotificationValue & 0x0F) != 0x0F) {
                // Missing notification from some worker
                SystemReset();
            }
        } else {
            // No notification received
            SystemReset();
        }
    }
}

A The code should use ulBitsToClearOnEntry = 0 to accumulate bits instead of clearing them before wait.

B The code correctly waits for notifications, clears bits on entry and exit, and checks all 4 bits are set.

C The code should not clear bits on exit to preserve notification bits for next cycle.

D The code should use a timeout of 500ms instead of 1000ms in xTaskNotifyWait.

💡 Hint

Think about clearing bits before and after waiting to detect missing notifications each cycle.

Clearing bits on entry ensures only new notifications count each cycle. Clearing on exit resets bits for next cycle. Checking bits 0-3 ensures all workers notified.

Practice

1. What is the main purpose of a watchdog task in FreeRTOS?

easy

A. To create new tasks dynamically during runtime

B. To monitor other tasks and reset the system if a task fails

C. To handle user input events

D. To manage memory allocation for tasks

Solution

1. Step 1: Understand the watchdog task role

   The watchdog task monitors the health of other tasks to ensure they are running correctly.

2. Step 2: Identify the action taken on failure

   If a task fails or stops responding, the watchdog task can reset the system or take corrective action.

3. Final Answer:

   To monitor other tasks and reset the system if a task fails -> Option B

4. Quick Check:

   Watchdog monitors and resets = A [OK]

Hint: Watchdog watches tasks and resets on failure [OK]

Common Mistakes:

• Confusing watchdog with task creation
• Thinking watchdog handles user input
• Assuming watchdog manages memory

2. Which of the following is the correct way to reset a watchdog timer in a FreeRTOS task?

easy

A. Call watchdog_reset() periodically from monitored tasks

B. Use xTaskCreate() to reset the timer

C. Call vTaskDelay() inside the watchdog task

D. Call vTaskDelete() on the watchdog task

Solution

1. Step 1: Identify how watchdog timers are reset

   Monitored tasks must periodically signal the watchdog by calling a reset function like watchdog_reset().

2. Step 2: Eliminate incorrect options

   vTaskDelay() delays a task but does not reset the watchdog timer. xTaskCreate() creates tasks, not reset timers. vTaskDelete() deletes tasks, not reset timers.

3. Final Answer:

   Call watchdog_reset() periodically from monitored tasks -> Option A

4. Quick Check:

   Reset watchdog by calling reset function = C [OK]

Hint: Reset watchdog by calling its reset function in tasks [OK]

Common Mistakes:

• Using delay functions to reset watchdog
• Trying to reset watchdog by creating or deleting tasks
• Confusing task management functions with watchdog reset

3. Consider this simplified watchdog task code snippet in FreeRTOS:

void WatchdogTask(void *pvParameters) {
    for (;;) {
        if (xSemaphoreTake(watchdogSemaphore, pdMS_TO_TICKS(1000)) == pdFALSE) {
            // No reset signal received
            vTaskDelay(pdMS_TO_TICKS(500));
            // Take recovery action
        } else {
            // Reset signal received
            vTaskDelay(pdMS_TO_TICKS(100));
        }
    }
}

What happens if the monitored task never calls xSemaphoreGive(watchdogSemaphore)?

medium

A. The watchdog task will detect no reset signal and take recovery action repeatedly

B. The watchdog task will keep waiting forever without action

C. The watchdog task will crash due to semaphore misuse

D. The watchdog task will reset the semaphore automatically

Solution

1. Step 1: Analyze semaphore wait behavior

   The watchdog task waits 1000 ms for a semaphore signal. If none arrives, xSemaphoreTake returns pdFALSE.

2. Step 2: Understand the consequence of no signal

   When no signal is received, the watchdog delays 500 ms and then takes recovery action repeatedly in the loop.

3. Final Answer:

   The watchdog task will detect no reset signal and take recovery action repeatedly -> Option A

4. Quick Check:

   No semaphore signal triggers recovery = A [OK]

Hint: No semaphore signal means watchdog triggers recovery [OK]

Common Mistakes:

• Assuming watchdog waits forever without action
• Thinking semaphore misuse causes crash here
• Believing semaphore resets automatically

4. Given this watchdog task snippet:

void WatchdogTask(void *pvParameters) {
    for (;;) {
        if (xSemaphoreTake(watchdogSemaphore, 0) == pdTRUE) {
            // Reset received
        } else {
            // No reset, take action
        }
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

What is the main problem with this code?

medium

A. The task deletes itself after one loop

B. The task delays too long after receiving a reset signal

C. The semaphore wait time is zero, so it never blocks to wait for reset signals

D. The semaphore is given incorrectly in the monitored task

Solution

1. Step 1: Examine semaphore wait time parameter

   The call xSemaphoreTake(watchdogSemaphore, 0) means it does not wait and returns immediately.

2. Step 2: Understand impact on watchdog behavior

   Because it never blocks, the watchdog may miss reset signals if they arrive after the check, causing false recovery actions.

3. Final Answer:

   The semaphore wait time is zero, so it never blocks to wait for reset signals -> Option C

4. Quick Check:

   Zero wait means no blocking = D [OK]

Hint: Semaphore wait time zero means no blocking, causing missed signals [OK]

Common Mistakes:

• Thinking delay length is the problem
• Assuming semaphore is given incorrectly without evidence
• Believing task deletes itself here

5. You want to implement a watchdog task that monitors three tasks: TaskA, TaskB, and TaskC. Each task must send a heartbeat signal every 500 ms. Which approach best ensures the watchdog detects a failure in any task within 2 seconds?

hard

A. Use one binary semaphore shared by all tasks; each task gives it every 500 ms

B. Use a single counting semaphore incremented by all tasks; watchdog resets counter every 2 seconds

C. Use three separate semaphores; watchdog waits up to 2 seconds for each semaphore in sequence

D. Use three separate semaphores; watchdog checks each semaphore with a 700 ms timeout and flags failure if any miss

Solution

1. Step 1: Understand heartbeat timing requirements

   Each task sends a heartbeat every 500 ms. The watchdog must detect failure within 2 seconds.

2. Step 2: Evaluate semaphore usage options

   Using separate semaphores allows independent monitoring. Checking each with a 700 ms timeout ensures missing any heartbeat triggers failure detection quickly.

3. Step 3: Compare with other options

   One shared semaphore (Use one binary semaphore shared by all tasks; each task gives it every 500 ms) cannot distinguish which task failed. Waiting 2 seconds per semaphore (Use three separate semaphores; watchdog waits up to 2 seconds for each semaphore in sequence) delays detection. Counting semaphore (Use a single counting semaphore incremented by all tasks; watchdog resets counter every 2 seconds) loses individual task info.

4. Final Answer:

   Use three separate semaphores; watchdog checks each semaphore with a 700 ms timeout and flags failure if any miss -> Option D

5. Quick Check:

   Separate semaphores + short timeout = fast failure detection = B [OK]

Hint: Separate semaphores with short timeout catch failures fast [OK]

Common Mistakes:

• Using one semaphore for all tasks losing failure detail
• Waiting too long per semaphore delaying detection
• Using counting semaphore losing individual task info