Common RTOS bugs and debugging strategies in FreeRTOS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a FreeRTOS task that runs the function taskFunction.

FreeRTOS

xTaskCreate([1], "Task1", 1000, NULL, 1, NULL);

Drag options to blanks, or click blank then click option'

AtaskFunction

BvTaskStartScheduler

CxQueueCreate

DvTaskDelay

Attempts:

3 left

💡 Hint

Common Mistakes

Passing the scheduler start function instead of the task function.

The function taskFunction is passed to xTaskCreate to define the task's code.

2fill in blank

medium

Complete the code to delay a task for 500 milliseconds using FreeRTOS API.

FreeRTOS

vTaskDelay([1]);

Drag options to blanks, or click blank then click option'

ApdMS_TO_TICKS(500)

B500 * portTICK_PERIOD_MS

C500 / portTICK_PERIOD_MS

D500

Attempts:

3 left

💡 Hint

Common Mistakes

Passing raw milliseconds instead of ticks.

Use pdMS_TO_TICKS(500) to convert milliseconds to ticks for vTaskDelay.

3fill in blank

hard

Fix the error in the code that causes a deadlock when two tasks try to take the same mutex.

FreeRTOS

if(xSemaphoreTake([1], portMAX_DELAY) == pdTRUE) {
    // critical section
    xSemaphoreGive([1]);
}

Drag options to blanks, or click blank then click option'

AtaskHandle

Bqueue1

Cmutex1

Dtimer1

Attempts:

3 left

💡 Hint

Common Mistakes

Using different handles for take and give.

Using a queue handle instead of a mutex.

The mutex mutex1 must be taken and given properly to avoid deadlocks.

4fill in blank

hard

Fill both blanks to correctly check if a queue is full before sending data.

FreeRTOS

if(uxQueueSpacesAvailable([1]) [2] 0) {
    xQueueSend([1], &data, 0);
}

Drag options to blanks, or click blank then click option'

AqueueHandle

B>

C==

D<

Attempts:

3 left

💡 Hint

Common Mistakes

Using different queue handles.

Checking if spaces equal zero instead of greater than zero.

Check if the queue queueHandle has space available (greater than 0) before sending.

5fill in blank

hard

Fill all three blanks to create a dictionary comprehension that maps task names to their stack high water marks if the mark is less than 100.

FreeRTOS

{ [1]: [2] for [1] in tasks if uxTaskGetStackHighWaterMark([1]) [3] 100 }

Drag options to blanks, or click blank then click option'

Atask

BuxTaskGetStackHighWaterMark(task)

C<

Dtask.name

Attempts:

3 left

💡 Hint

Common Mistakes

Using different variable names for key and iteration.

Using wrong comparison operators.

This comprehension creates a dictionary with task handles as keys and their stack high water marks as values, filtering those below 100.

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