Common RTOS bugs and debugging strategies in FreeRTOS - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a common cause of priority inversion in RTOS?

Priority inversion happens when a low-priority task holds a resource needed by a higher-priority task, causing the high-priority task to wait and potentially miss deadlines.

beginner

How can deadlocks occur in an RTOS environment?

Deadlocks occur when two or more tasks wait indefinitely for resources held by each other, creating a cycle of dependencies that stops all involved tasks.

intermediate

What debugging strategy helps identify stack overflow in FreeRTOS tasks?

Using FreeRTOS's stack overflow hook function allows detection when a task exceeds its stack size, helping to catch stack overflow bugs early.

intermediate

Why is using trace tools important in debugging RTOS applications?

Trace tools record task switches, interrupts, and events in real-time, helping developers understand system behavior and find timing or synchronization bugs.

beginner

What is a common symptom of race conditions in RTOS tasks?

Race conditions cause unpredictable behavior like corrupted data or crashes because multiple tasks access shared data without proper synchronization.

Which of the following is a typical cause of deadlock in RTOS?

A A task with too high priority

B A task running out of stack space

C A task that never yields

D Two tasks waiting on each other's resources

Deadlock happens when tasks wait on each other’s resources, creating a cycle that stops progress.

What does FreeRTOS's stack overflow hook function do?

A Detects when a task uses more stack than allocated

B Prevents priority inversion automatically

C Logs all task switches

D Resets the system on error

The stack overflow hook is called when a task exceeds its stack size, helping catch stack overflow bugs.

Priority inversion can be avoided by:

A Increasing all task priorities

B Using priority inheritance protocols

C Disabling interrupts

D Using larger stack sizes

Priority inheritance temporarily raises the priority of the low-priority task holding a resource to avoid blocking high-priority tasks.

Which tool helps visualize task execution and timing in FreeRTOS?

A Tracealyzer

B GDB

C Valgrind

D Wireshark

Tracealyzer is a trace tool that shows task switches and timing, useful for debugging RTOS behavior.

Race conditions occur when:

A The scheduler is disabled

B A task runs out of stack

C Multiple tasks access shared data without synchronization

D A task has too low priority

Race conditions happen when tasks access shared data at the same time without proper locks or synchronization.

Explain what causes priority inversion in an RTOS and how it can be mitigated.

Think about tasks waiting for resources and how priorities can change temporarily.

Describe common debugging strategies to find and fix deadlocks in FreeRTOS applications.

Consider how tasks wait for resources and how to detect cycles.

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