Common RTOS bugs and debugging strategies in FreeRTOS - Step-by-Step Execution

Concept Flow - Common RTOS bugs and debugging strategies

Start RTOS Application

↓

Task Creation

↓

Scheduler Start

↓

Tasks Run Concurrently

↓

Possible Bugs?

Yes→Identify Bug Type

↓

Apply Debugging Strategy

↓

Normal

↓

End

This flow shows how an RTOS application starts, runs tasks, checks for bugs, and applies debugging strategies to fix them.

Execution Sample

FreeRTOS

void vTask1(void *pvParameters) {
  for(;;) {
    // Task code
    vTaskDelay(100 / portTICK_PERIOD_MS);
  }
}

This code runs a FreeRTOS task that loops forever, delaying itself to allow other tasks to run.

Execution Table

Step	Action	Condition/Check	Result/Effect
1	Create Task vTask1	Task parameters valid?	Task created successfully
2	Start Scheduler	Scheduler started?	Scheduler running, tasks scheduled
3	vTask1 runs	Infinite loop	Task executes code, then delays
4	vTask1 calls vTaskDelay	Delay time valid?	Task blocked for 100 ticks
5	Other tasks run	Scheduler switches context	CPU time shared fairly
6	Check for deadlock	Any task waiting forever?	No deadlock detected
7	Check for stack overflow	Stack usage within limits?	No overflow detected
8	Check for priority inversion	Lower priority task blocking?	Priority inheritance applied
9	Bug detected: Task starvation	High priority task never yields?	Debug: Add vTaskDelay or yield
10	Bug detected: Memory leak	Dynamic allocation failure?	Debug: Check malloc/free balance
11	Bug detected: Race condition	Shared resource accessed unsafely?	Debug: Use mutex/semaphore
12	Apply debugging strategy	Use trace tools, logs, breakpoints	Bug identified and fixed
13	End	All tasks stable?	System running correctly

💡 Execution stops when all tasks run stably without bugs or after bugs are fixed.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	After Step 12	Final
Task State	Created	Running	Blocked (delay)	Running (other tasks)	Debugged	Running (stable)
Scheduler State	Not started	Running	Running	Running	Running	Running
CPU Usage	0%	Task1 active	Task1 blocked	Other tasks active	Balanced	Balanced
Bug Status	None	None	None	Detected	Fixed	None

Key Moments - 3 Insights

Why does the task call vTaskDelay inside an infinite loop?

Calling vTaskDelay lets the task pause and allows other tasks to run, preventing CPU hogging. See execution_table step 4 where the task blocks for 100 ticks.

What causes priority inversion and how is it fixed?

Priority inversion happens when a low priority task holds a resource needed by a high priority task. FreeRTOS uses priority inheritance to temporarily raise the low priority task's priority. See execution_table step 8.

How can race conditions be detected and prevented?

Race conditions occur when multiple tasks access shared data without protection. Using mutexes or semaphores prevents this. See execution_table step 11 where debugging suggests using synchronization.

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what happens to the task?

A The task continues running without pause

B The task blocks for a delay period

C The task ends

D The task crashes

💡 Hint

Check the 'Result/Effect' column at step 4 in the execution_table.

At which step is priority inversion detected and handled?

A Step 6

B Step 10

C Step 8

D Step 12

💡 Hint

Look for 'priority inversion' in the 'Action' column in the execution_table.

If the task never calls vTaskDelay, what bug is most likely to appear?

A Task starvation

B Deadlock

C Memory leak

D Race condition

💡 Hint

Refer to the 'Bug detected: Task starvation' row in the execution_table.

Concept Snapshot

Common RTOS bugs include deadlocks, priority inversion, race conditions, and memory leaks.
Use vTaskDelay or yield to avoid task starvation.
Use mutexes/semaphores to protect shared resources.
Use priority inheritance to fix priority inversion.
Debug with trace tools, logs, and breakpoints.
Check stack usage and dynamic memory carefully.

Full Transcript

This visual execution shows how a FreeRTOS application runs tasks and how common bugs appear and are fixed. The task runs an infinite loop with vTaskDelay to share CPU time. The scheduler manages task switching. Bugs like deadlocks, priority inversion, and race conditions are detected by checking task states and resource usage. Debugging strategies include using synchronization tools and priority inheritance. The execution table traces each step, showing task states and bug detection. Variable tracking shows how task state and scheduler state change over time. Key moments clarify why delays are needed, how priority inversion is handled, and how race conditions are prevented. The quiz tests understanding of task blocking, priority inversion, and task starvation. The snapshot summarizes key bugs and fixes in RTOS programming.

Practice

1. Which of the following is a common cause of deadlocks in FreeRTOS applications?

easy

A. Not enabling the FreeRTOS scheduler

B. Using too much heap memory for dynamic allocation

C. Incorrect task priority assignment causing starvation

D. Two tasks waiting indefinitely for each other's resource

Solution

1. Step 1: Understand deadlock concept in RTOS

   Deadlock happens when two or more tasks wait forever for resources held by each other.

2. Step 2: Identify the scenario causing deadlock

   Two tasks waiting indefinitely for each other's resource is the classic deadlock cause.

3. Final Answer:

   Two tasks waiting indefinitely for each other's resource -> Option D

4. Quick Check:

   Deadlock = Mutual waiting [OK]

Hint: Deadlock means tasks wait forever for each other's resource [OK]

Common Mistakes:

• Confusing deadlock with priority inversion
• Thinking heap size causes deadlock
• Assuming scheduler not started causes deadlock

2. Which FreeRTOS API call correctly creates a task?

easy

A. xTaskCreate(TaskFunction, "Task1", 1000, NULL, 2, NULL);

B. vTaskCreate(TaskFunction, "Task1", 1000, NULL, 2, NULL);

C. xTaskCreate(TaskFunction, 1000, "Task1", NULL, 2, NULL);

D. xTaskCreate(TaskFunction, "Task1", NULL, 1000, 2, NULL);

Solution

1. Step 1: Recall FreeRTOS task creation syntax

   The correct syntax is xTaskCreate(TaskFunction, "Name", stackSize, parameters, priority, taskHandle).

2. Step 2: Match options with correct parameter order

   xTaskCreate(TaskFunction, "Task1", 1000, NULL, 2, NULL); matches the correct order and types.

3. Final Answer:

   xTaskCreate(TaskFunction, "Task1", 1000, NULL, 2, NULL); -> Option A

4. Quick Check:

   Correct API call = xTaskCreate(TaskFunction, "Task1", 1000, NULL, 2, NULL); [OK]

Hint: xTaskCreate returns status; remember parameter order [OK]

Common Mistakes:

• Mixing up parameter order
• Using void return type function instead of xTaskCreate
• Passing NULL for stack size

3. Given the code snippet:

void vTask1(void *pvParameters) {
  for(;;) {
    xSemaphoreTake(xMutex, portMAX_DELAY);
    // Critical section
    xSemaphoreGive(xMutex);
    vTaskDelay(10);
  }
}

What is the likely effect if xSemaphoreGive(xMutex); is accidentally omitted?

medium

A. The mutex will be automatically released after timeout

B. The task will run normally without issues

C. Other tasks waiting for the mutex will block indefinitely

D. The system will reset due to stack overflow

Solution

1. Step 1: Understand semaphore usage in FreeRTOS

   Mutex must be given back after taking it to allow other tasks to access the resource.

2. Step 2: Analyze effect of missing xSemaphoreGive

   If xSemaphoreGive is omitted, the mutex stays taken, blocking other tasks indefinitely.

3. Final Answer:

   Other tasks waiting for the mutex will block indefinitely -> Option C

4. Quick Check:

   Missing give = Blocked tasks [OK]

Hint: Always pair xSemaphoreTake with xSemaphoreGive [OK]

Common Mistakes:

• Assuming mutex auto-releases
• Confusing blocking with stack overflow
• Ignoring semaphore usage rules

4. You observe that a FreeRTOS task sometimes stops running unexpectedly. Which debugging strategy is best to identify if a stack overflow caused this?

medium

A. Enable configCHECK_FOR_STACK_OVERFLOW and use configASSERT

B. Increase task priority to highest level

C. Disable all interrupts temporarily

D. Use vTaskDelay to slow down the task

Solution

1. Step 1: Identify debugging features for stack overflow

   FreeRTOS provides configCHECK_FOR_STACK_OVERFLOW and configASSERT to detect stack overflow at runtime.

2. Step 2: Choose the best debugging method

   Enabling these features helps catch stack overflow errors causing task failure.

3. Final Answer:

   Enable configCHECK_FOR_STACK_OVERFLOW and use configASSERT -> Option A

4. Quick Check:

   Stack overflow debug = configCHECK_FOR_STACK_OVERFLOW [OK]

Hint: Use FreeRTOS built-in stack overflow checks [OK]

Common Mistakes:

• Thinking priority change fixes stack overflow
• Disabling interrupts hides bugs
• Using delay does not detect stack issues

5. In a FreeRTOS system, priority inversion occurs when a low priority task holds a resource needed by a high priority task. Which strategy helps to solve this problem?

hard

A. Increase the stack size of the low priority task

B. Use priority inheritance protocol on mutexes

C. Disable preemption in the scheduler

D. Use vTaskDelay in the high priority task

Solution

1. Step 1: Understand priority inversion problem

   Priority inversion happens when a low priority task blocks a high priority task by holding a resource.

2. Step 2: Identify solution using FreeRTOS features

   Priority inheritance protocol temporarily raises the low priority task's priority to prevent inversion.

3. Final Answer:

   Use priority inheritance protocol on mutexes -> Option B

4. Quick Check:

   Priority inversion fix = Priority inheritance [OK]

Hint: Enable priority inheritance on mutexes to fix inversion [OK]

Common Mistakes:

• Thinking stack size affects priority inversion
• Disabling preemption causes system issues
• Using delay does not solve inversion