Why runtime monitoring catches RTOS bugs in FreeRTOS - See It in Action

Why runtime monitoring catches RTOS bugs

📖 Scenario: You are working with a FreeRTOS-based embedded system. Sometimes, tasks behave unexpectedly or the system crashes. You want to understand how runtime monitoring helps catch these bugs early.

🎯 Goal: Build a simple FreeRTOS task setup and add runtime monitoring variables to detect task overruns and unexpected states.

📋 What You'll Learn

Create a FreeRTOS task list with exact task names and priorities

Add a runtime monitoring variable to track task execution time

Implement a check to detect if a task exceeds its allowed runtime

Print a warning message when a task overrun is detected

💡 Why This Matters

🌍 Real World

Embedded systems often run multiple tasks with strict timing requirements. Runtime monitoring helps detect when tasks take too long, preventing system crashes or unexpected behavior.

💼 Career

Understanding runtime monitoring in RTOS is essential for embedded developers and DevOps engineers working on real-time systems to ensure reliability and quick bug detection.

1

Create FreeRTOS tasks

Create two FreeRTOS tasks named TaskA and TaskB with priorities 2 and 1 respectively. Use xTaskCreate to create them.

FreeRTOS

int main(void) {
    // Create TaskA and TaskB with priorities 2 and 1
    // Your code here
    vTaskStartScheduler();
}

Hint

Use xTaskCreate with the exact task names and priorities given.

2

Add runtime monitoring variable

Add a global variable TaskA_RunTime initialized to 0 to track the execution time of TaskA.

FreeRTOS

// Add TaskA_RunTime variable here (global)
// Your code here

int main(void) {
    xTaskCreate(TaskA, "TaskA", 1000, NULL, 2, NULL);
    xTaskCreate(TaskB, "TaskB", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
}

Hint

Declare TaskA_RunTime as an unsigned int and initialize it to zero.

3

Check for task runtime overrun

Inside TaskA function, add code to increment TaskA_RunTime by 1 each cycle. Then add an if statement to check if TaskA_RunTime exceeds 100 and set a flag TaskA_Overrun to 1 if true.

FreeRTOS

unsigned int TaskA_RunTime = 0;
unsigned int TaskA_Overrun = 0;

void TaskA(void *pvParameters) {
    while(1) {
        // Increment runtime and check overrun
        // Your code here
    }
}

int main(void) {
    xTaskCreate(TaskA, "TaskA", 1000, NULL, 2, NULL);
    xTaskCreate(TaskB, "TaskB", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
}

Hint

Increment TaskA_RunTime inside the loop and check if it is greater than 100 to set TaskA_Overrun.

4

Print warning on overrun

In the TaskB function, add code to check if TaskA_Overrun is 1. If yes, print "Warning: TaskA overrun detected!" using printf and reset the flag to 0.

FreeRTOS

unsigned int TaskA_RunTime = 0;
unsigned int TaskA_Overrun = 0;

void TaskA(void *pvParameters) {
    while(1) {
        TaskA_RunTime++;
        if (TaskA_RunTime > 100) {
            TaskA_Overrun = 1;
        }
        vTaskDelay(1);
    }
}

void TaskB(void *pvParameters) {
    while(1) {
        // Check if TaskA_Overrun is 1 and print warning
        // Your code here
    }
}

int main(void) {
    xTaskCreate(TaskA, "TaskA", 1000, NULL, 2, NULL);
    xTaskCreate(TaskB, "TaskB", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
}

Hint

Use if (TaskA_Overrun == 1) inside TaskB to check and printf to print the warning message. Reset the flag after printing.

Practice

1. Why is runtime monitoring important in FreeRTOS for catching bugs?

easy

A. It observes the system while running to find timing and interaction issues

B. It compiles the code faster

C. It replaces the need for unit testing

D. It automatically fixes bugs in the code

Solution

1. Step 1: Understand runtime monitoring purpose

   Runtime monitoring watches the RTOS as it runs to detect hidden bugs that only appear during execution.

2. Step 2: Identify what kinds of bugs it catches

   It catches timing issues, resource conflicts, and task interaction problems that static analysis or compile-time checks miss.

3. Final Answer:

   It observes the system while running to find timing and interaction issues -> Option A

4. Quick Check:

   Runtime monitoring = watches running system [OK]

Hint: Runtime monitoring finds bugs only visible during execution [OK]

Common Mistakes:

• Thinking it speeds up compilation
• Believing it replaces testing
• Assuming it fixes bugs automatically

2. Which FreeRTOS configuration option enables runtime monitoring features?

easy

A. configUSE_TIMERS

B. configUSE_PREEMPTION

C. configMAX_PRIORITIES

D. configUSE_TRACE_FACILITY

Solution

1. Step 1: Identify runtime monitoring related config

   Runtime monitoring requires trace facilities to collect task and system event data.

2. Step 2: Match config option to trace feature

   configUSE_TRACE_FACILITY enables trace data collection needed for runtime monitoring.

3. Final Answer:

   configUSE_TRACE_FACILITY -> Option D

4. Quick Check:

   Trace facility config = runtime monitoring enabled [OK]

Hint: Trace facility config enables runtime monitoring [OK]

Common Mistakes:

• Choosing timer or priority configs unrelated to monitoring
• Confusing preemption with monitoring features

3. Given this FreeRTOS trace output snippet showing task switch times, what bug can runtime monitoring help detect?

TaskA switched out at 100ms
TaskB switched in at 100ms
TaskA switched in at 105ms
TaskB switched out at 110ms

medium

A. Task switch times overlap causing resource conflicts

B. TaskA is starving and never runs

C. TaskB runs longer than expected causing timing issues

D. No bug, tasks switch correctly

Solution

1. Step 1: Analyze task switch timing

   TaskB runs from 100ms to 110ms (10ms), TaskA runs from 105ms to 105ms (0ms), overlapping occurs.

2. Step 2: Identify timing issue

   TaskB runs longer than expected, overlapping TaskA's scheduled run, causing timing problems.

3. Final Answer:

   TaskB runs longer than expected causing timing issues -> Option C

4. Quick Check:

   Overlapping run times = timing bug [OK]

Hint: Look for overlapping task run times in trace output [OK]

Common Mistakes:

• Ignoring overlapping times
• Assuming no bug if tasks switch
• Confusing starvation with timing overlap

4. You enabled runtime monitoring but see no data collected. What is the most likely cause?

medium

A. configUSE_TRACE_FACILITY is set to 0

B. The FreeRTOS kernel is not running

C. The hardware timer is too fast

D. The tasks have no delays

Solution

1. Step 1: Check runtime monitoring prerequisites

   Runtime monitoring requires configUSE_TRACE_FACILITY enabled to collect trace data.

2. Step 2: Identify cause of no data

   If configUSE_TRACE_FACILITY is 0, no trace data is collected, so monitoring shows no data.

3. Final Answer:

   configUSE_TRACE_FACILITY is set to 0 -> Option A

4. Quick Check:

   Trace facility disabled = no monitoring data [OK]

Hint: Check trace facility config if no monitoring data appears [OK]

Common Mistakes:

• Assuming kernel not running without verifying
• Blaming timer speed incorrectly
• Thinking task delays affect monitoring data

5. How can runtime monitoring help detect a subtle deadlock caused by two tasks waiting on each other's resources in FreeRTOS?

hard

A. By automatically restarting the tasks to break the deadlock

B. By showing tasks stuck in blocked state with no progress over time

C. By increasing task priorities to force execution

D. By disabling interrupts to isolate the problem

Solution

1. Step 1: Understand deadlock symptoms in runtime

   Deadlock causes tasks to wait indefinitely, appearing as blocked with no state changes.

2. Step 2: Identify monitoring role

   Runtime monitoring tracks task states and timing, revealing tasks stuck without progress.

3. Final Answer:

   By showing tasks stuck in blocked state with no progress over time -> Option B

4. Quick Check:

   Blocked tasks with no progress = deadlock detected [OK]

Hint: Look for tasks blocked without state changes over time [OK]

Common Mistakes:

• Thinking monitoring fixes deadlocks automatically
• Confusing priority changes with monitoring
• Assuming disabling interrupts helps detect deadlocks