Common RTOS bugs and debugging strategies in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this FreeRTOS task scheduling code?

Consider two tasks with different priorities. What will be printed when both tasks run?

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include <stdio.h>

void Task1(void *pvParameters) {
    printf("Task1 start\n");
    vTaskDelay(pdMS_TO_TICKS(100));
    printf("Task1 end\n");
    vTaskDelete(NULL);
}

void Task2(void *pvParameters) {
    printf("Task2 start\n");
    vTaskDelay(pdMS_TO_TICKS(50));
    printf("Task2 end\n");
    vTaskDelete(NULL);
}

int main() {
    xTaskCreate(Task1, "Task1", 1000, NULL, 2, NULL);
    xTaskCreate(Task2, "Task2", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
    return 0;
}

A Task1 start\nTask1 end\nTask2 start\nTask2 end\n

B Task1 start\nTask2 start\nTask2 end\nTask1 end\n

C Task2 start\nTask1 start\nTask1 end\nTask2 end\n

D Task2 start\nTask2 end\nTask1 start\nTask1 end\n

💡 Hint

Remember that higher priority tasks preempt lower priority ones, and vTaskDelay causes the task to block for the specified time.

Task1 has higher priority (2) than Task2 (1). Task1 runs first and prints "Task1 start". Then it delays for 100ms, allowing Task2 to run and print its messages. Task2 delays for 50ms, so it finishes before Task1 resumes and prints "Task1 end".

🧠 Conceptual

intermediate

Which common RTOS bug causes a system to freeze due to tasks waiting forever?

In FreeRTOS, what is the typical cause of a system freeze when tasks never resume?

A Incorrect task notification value

B Priority inversion without priority inheritance

C Stack overflow in a task

D Deadlock caused by improper mutex usage

💡 Hint

Think about tasks waiting on each other indefinitely.

Deadlock happens when two or more tasks wait for resources held by each other, causing all to block forever. This freezes the system.

🔧 Debug

advanced

Identify the bug causing stack overflow in this FreeRTOS task

Examine the task code below. What causes the stack overflow?

FreeRTOS

void TaskExample(void *pvParameters) {
    char buffer[1024];
    while(1) {
        // Do some work
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

A vTaskDelay is called inside the loop causing stack to grow

B Missing vTaskDelete causes stack overflow

C The large local buffer uses too much stack space causing overflow

D Infinite loop without break causes stack overflow

💡 Hint

Consider how much memory the stack has and what local variables consume.

The large local array 'buffer' (1024 bytes) consumes a lot of stack memory. If the task stack size is not large enough, this causes stack overflow.

📝 Syntax

advanced

What error does this FreeRTOS queue code produce?

What error occurs when running this code snippet?

FreeRTOS

QueueHandle_t queue = xQueueCreate(5, sizeof(int));
int value = 10;
xQueueSend(queue, &value, 0);
xQueueSend(queue, NULL, 0);

A Runtime error due to NULL pointer passed to xQueueSend

B Compile-time error due to wrong argument type

C No error, both sends succeed

D Deadlock because queue is full

💡 Hint

Check the parameters passed to xQueueSend carefully.

xQueueSend expects a valid pointer to data. Passing NULL causes undefined behavior and likely runtime error.

🚀 Application

expert

How many items are in the queue after this sequence?

Given a FreeRTOS queue created with length 3, what is the number of items in the queue after these operations?

QueueHandle_t q = xQueueCreate(3, sizeof(int));
int a=1,b=2,c=3,d=4;
xQueueSend(q, &a, 0);
xQueueSend(q, &b, 0);
xQueueSend(q, &c, 0);
xQueueSend(q, &d, 0);

A 3 items, last send fails because queue is full

B 4 items, queue expands automatically

C 2 items, first send overwritten

D 0 items, all sends fail

💡 Hint

Remember the fixed size of FreeRTOS queues and behavior when full.

The queue has fixed length 3. The first three sends succeed. The fourth send fails because the queue is full, so only 3 items remain.

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