Critical sections and interrupt disabling in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of nested critical sections in FreeRTOS

Consider the following FreeRTOS code snippet. What will be the output printed to the console?

FreeRTOS

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

void exampleFunction() {
    taskENTER_CRITICAL();
    printf("Inside first critical section\n");
    taskENTER_CRITICAL();
    printf("Inside nested critical section\n");
    taskEXIT_CRITICAL();
    printf("Exited nested critical section\n");
    taskEXIT_CRITICAL();
    printf("Exited first critical section\n");
}

int main() {
    exampleFunction();
    return 0;
}

A

Inside first critical section
Inside nested critical section
Exited first critical section
Exited nested critical section

B

Inside first critical section
Exited nested critical section
Inside nested critical section
Exited first critical section

C

Inside first critical section
Inside nested critical section
Exited nested critical section
Exited first critical section

D

Inside nested critical section
Inside first critical section
Exited nested critical section
Exited first critical section

💡 Hint

Remember that nested critical sections in FreeRTOS use a counter to track entry and exit.

FreeRTOS allows nested critical sections by incrementing a nesting count on each taskENTER_CRITICAL call and decrementing it on taskEXIT_CRITICAL. The output follows the order of the print statements inside and after each critical section.

❓ Predict Output

intermediate

Effect of interrupt disabling on task switching

What will happen if interrupts are disabled globally in FreeRTOS for a long time inside a task?

FreeRTOS

void vTaskFunction(void *pvParameters) {
    portDISABLE_INTERRUPTS();
    // Simulate long processing
    for (volatile int i = 0; i < 1000000; i++) {}
    portENABLE_INTERRUPTS();
    vTaskDelete(NULL);
}

A The system will block all interrupts, causing no task switching and possible system freeze.

B The task will yield automatically despite interrupts being disabled.

C Only software interrupts will be blocked, hardware interrupts continue normally.

D The system will continue running normally with task switching unaffected.

💡 Hint

Think about what disabling interrupts globally means for the scheduler.

Disabling interrupts globally prevents the FreeRTOS scheduler from running, so no context switches occur. This can cause the system to freeze if interrupts are disabled for too long.

🔧 Debug

advanced

Identify the error in critical section usage

What error will the following FreeRTOS code cause when run on a Cortex-M microcontroller?

FreeRTOS

void faultyFunction() {
    taskENTER_CRITICAL();
    // Critical code
    taskEXIT_CRITICAL();
    taskEXIT_CRITICAL(); // Extra exit
}

A Undefined behavior due to decrementing critical nesting count below zero.

B Stack overflow due to unbalanced critical section exit calls.

C No error, code runs normally.

D Compile-time error due to extra taskEXIT_CRITICAL call.

💡 Hint

Check how FreeRTOS tracks critical section nesting internally.

Calling taskEXIT_CRITICAL more times than taskENTER_CRITICAL causes the nesting count to go below zero, leading to undefined behavior and possible system instability.

🧠 Conceptual

advanced

Why use portENTER_CRITICAL instead of taskENTER_CRITICAL?

In FreeRTOS, what is the main difference between portENTER_CRITICAL() and taskENTER_CRITICAL(), and when should portENTER_CRITICAL be used?

A portENTER_CRITICAL disables interrupts globally and is used in ISR context; taskENTER_CRITICAL disables scheduler only and is used in tasks.

B portENTER_CRITICAL disables interrupts at the port level and is used in low-level code; taskENTER_CRITICAL is a wrapper used in tasks.

C portENTER_CRITICAL enables interrupts; taskENTER_CRITICAL disables interrupts.

D There is no difference; both are aliases and can be used interchangeably.

💡 Hint

Consider the abstraction layers in FreeRTOS and hardware-specific code.

portENTER_CRITICAL is a macro that disables interrupts at the hardware port level and is used in low-level or ISR code. taskENTER_CRITICAL is a higher-level macro that calls portENTER_CRITICAL and manages nesting for tasks.

❓ Predict Output

expert

Output of interrupt priority masking in critical section

Given the following FreeRTOS code on a Cortex-M with configMAX_SYSCALL_INTERRUPT_PRIORITY set to 5, what is the value of variable x after the critical section?

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "cmsis_os.h"

volatile int x = 0;

void vTask(void *pvParameters) {
    taskENTER_CRITICAL();
    x = 10;
    taskEXIT_CRITICAL();
}

int main() {
    NVIC_SetPriorityGrouping(3); // Priority grouping
    NVIC_SetPriority(SysTick_IRQn, 6); // Lower priority than max syscall
    NVIC_SetPriority(USART1_IRQn, 4); // Higher priority than max syscall

    x = 0;
    vTask(NULL);
    return x;
}

A Undefined, depends on interrupt timing

B 0

C 1

D 10

💡 Hint

Recall that taskENTER_CRITICAL disables interrupts up to configMAX_SYSCALL_INTERRUPT_PRIORITY.

taskENTER_CRITICAL disables interrupts with priority equal or lower than configMAX_SYSCALL_INTERRUPT_PRIORITY (5). Since SysTick_IRQn is priority 6 (lower priority), it is masked. USART1_IRQn with priority 4 (higher priority) is not masked but does not affect x here. So x is set to 10 safely.

Practice

1. What is the main purpose of using taskENTER_CRITICAL() and taskEXIT_CRITICAL() in FreeRTOS?

easy

A. To prevent interrupts during a critical section of code

B. To start and stop a task scheduler

C. To allocate memory dynamically

D. To create a new task

Solution

1. Step 1: Understand critical sections in FreeRTOS

   Critical sections are used to protect code that must not be interrupted to avoid data corruption or race conditions.

2. Step 2: Role of taskENTER_CRITICAL() and taskEXIT_CRITICAL()

   These functions disable and enable interrupts respectively, marking the start and end of a critical section.

3. Final Answer:

   To prevent interrupts during a critical section of code -> Option A

4. Quick Check:

   Critical sections stop interrupts = A [OK]

Hint: Critical sections disable interrupts to protect code [OK]

Common Mistakes:

• Confusing critical sections with task creation
• Thinking they manage memory
• Assuming they start the scheduler

2. Which of the following is the correct syntax to mark the start of a critical section in FreeRTOS?

easy

A. taskEXIT_CRITICAL();

B. vTaskStartCritical();

C. taskENTER_CRITICAL();

D. xTaskDisableInterrupts();

Solution

1. Step 1: Identify the function to enter critical section

   The correct FreeRTOS API to disable interrupts and enter a critical section is taskENTER_CRITICAL().

2. Step 2: Check other options for correctness

   taskEXIT_CRITICAL() exits the critical section, others are not valid FreeRTOS functions.

3. Final Answer:

   taskENTER_CRITICAL(); -> Option C

4. Quick Check:

   Enter critical section = taskENTER_CRITICAL() [OK]

Hint: Enter critical section with taskENTER_CRITICAL() [OK]

Common Mistakes:

• Using taskEXIT_CRITICAL() to start critical section
• Inventing non-existent functions
• Confusing function names

3. Consider the following FreeRTOS code snippet:

taskENTER_CRITICAL();
sharedVariable++;
taskEXIT_CRITICAL();

What is the effect of this code on sharedVariable?

medium

A. It increments sharedVariable safely without interruption

B. It causes a syntax error due to missing semicolons

C. It increments sharedVariable but allows interrupts during increment

D. It resets sharedVariable to zero

Solution

1. Step 1: Analyze the critical section usage

   The code disables interrupts before incrementing sharedVariable and re-enables them after, protecting the increment operation.

2. Step 2: Understand the effect on sharedVariable

   This ensures the increment is atomic and safe from concurrent access or interrupts.

3. Final Answer:

   It increments sharedVariable safely without interruption -> Option A

4. Quick Check:

   Critical section protects increment = D [OK]

Hint: Critical section makes increment safe from interrupts [OK]

Common Mistakes:

• Thinking interrupts are allowed during increment
• Assuming syntax errors where none exist
• Believing variable resets to zero

4. Identify the problem in this FreeRTOS code snippet:

taskENTER_CRITICAL();
sharedCounter++;
// Missing taskEXIT_CRITICAL();

medium

A. No problem, code is correct

B. sharedCounter is not incremented

C. Syntax error due to missing semicolon

D. Interrupts remain disabled causing system issues

Solution

1. Step 1: Check for matching critical section calls

   The code calls taskENTER_CRITICAL() but does not call taskEXIT_CRITICAL() to re-enable interrupts.

2. Step 2: Understand consequences of missing exit

   Interrupts remain disabled indefinitely, which can cause system to freeze or miss important events.

3. Final Answer:

   Interrupts remain disabled causing system issues -> Option D

4. Quick Check:

   Missing taskEXIT_CRITICAL() disables interrupts forever = A [OK]

Hint: Always pair taskENTER_CRITICAL() with taskEXIT_CRITICAL() [OK]

Common Mistakes:

• Ignoring missing exit call
• Assuming increment fails
• Thinking code has syntax errors

5. You have a shared resource accessed by multiple tasks and interrupts. Which approach best protects the resource while keeping system responsiveness high?

hard

A. Use long critical sections with taskENTER_CRITICAL() and taskEXIT_CRITICAL() around all resource access

B. Use short critical sections only around the minimal code that accesses the resource

C. Disable all interrupts globally for the entire program runtime

D. Avoid using critical sections and rely on task delays

Solution

1. Step 1: Understand impact of critical section length

   Long critical sections block interrupts for too long, reducing system responsiveness.

2. Step 2: Best practice for protecting shared resources

   Short critical sections minimize interrupt blocking while protecting shared data safely.

3. Final Answer:

   Use short critical sections only around the minimal code that accesses the resource -> Option B

4. Quick Check:

   Short critical sections = better responsiveness [OK]

Hint: Keep critical sections short for best performance [OK]

Common Mistakes:

• Using long critical sections unnecessarily
• Disabling interrupts globally
• Ignoring synchronization needs