ISR-safe API functions (FromISR suffix) in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of xQueueSendFromISR usage

What is the output of this code snippet when called inside an ISR?

BaseType_t xHigherPriorityTaskWoken = pdFALSE;
QueueHandle_t xQueue = xQueueCreate(1, sizeof(int));
int value = 10;
BaseType_t result = xQueueSendFromISR(xQueue, &value, &xHigherPriorityTaskWoken);
printf("Result: %d, Woken: %d\n", result, xHigherPriorityTaskWoken);

FreeRTOS

BaseType_t xHigherPriorityTaskWoken = pdFALSE;
QueueHandle_t xQueue = xQueueCreate(1, sizeof(int));
int value = 10;
BaseType_t result = xQueueSendFromISR(xQueue, &value, &xHigherPriorityTaskWoken);
printf("Result: %d, Woken: %d\n", result, xHigherPriorityTaskWoken);

A Result: 1, Woken: 1

B Result: 0, Woken: 1

C Result: 1, Woken: 0

D Result: 0, Woken: 0

💡 Hint

Remember that xQueueSendFromISR returns pdTRUE (1) on success and pdFALSE (0) on failure. The Woken flag is set only if a higher priority task was unblocked.

The queue is empty and has space, so xQueueSendFromISR returns pdTRUE (1). Since no higher priority task was waiting, xHigherPriorityTaskWoken remains pdFALSE (0).

🧠 Conceptual

intermediate

Purpose of the FromISR suffix in FreeRTOS API

What is the main reason FreeRTOS provides API functions with the FromISR suffix?

A They allow blocking calls inside ISRs.

B They are optimized for use in interrupt service routines and do not block.

C They disable all interrupts globally.

D They automatically create tasks from ISRs.

💡 Hint

Think about what restrictions exist inside ISRs.

Functions with the FromISR suffix are designed to be safe to call from ISRs. They do not block and handle critical sections differently to avoid issues in interrupt context.

🔧 Debug

advanced

Identify the error in this ISR-safe queue send code

What error will occur when running this code inside an ISR?

BaseType_t xHigherPriorityTaskWoken = pdFALSE;
int value = 5;
xQueueSend(xQueue, &value, 0);

A Compile error: Missing FromISR suffix function.

B No error; code runs correctly.

C Queue overflow error.

D Runtime error: Blocking call inside ISR.

💡 Hint

Consider what happens if you call a normal API function inside an ISR.

xQueueSend is not safe to call inside an ISR because it may block. Calling it inside an ISR can cause runtime errors or unpredictable behavior.

📝 Syntax

advanced

Correct usage of xSemaphoreGiveFromISR

Which option correctly uses xSemaphoreGiveFromISR to give a semaphore inside an ISR?

A xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);

B xSemaphoreGiveFromISR(&xSemaphore, &xHigherPriorityTaskWoken);

C xSemaphoreGiveFromISR(xSemaphore);

D xSemaphoreGiveFromISR(xSemaphore, NULL);

💡 Hint

Check the function signature and parameters carefully.

xSemaphoreGiveFromISR requires a pointer to the semaphore handle and a pointer to a BaseType_t variable to indicate if a higher priority task was woken.

🚀 Application

expert

Determining task switch necessity after ISR

Inside an ISR, you call xQueueSendFromISR and the xHigherPriorityTaskWoken flag is set to pdTRUE. What should you do next to ensure the higher priority task runs immediately after the ISR?

A Call portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

B Call vTaskDelay(1);

C Do nothing; the scheduler will switch tasks automatically.

D Call xTaskResumeAll();

💡 Hint

Think about how to request a context switch from an ISR.

When xHigherPriorityTaskWoken is pdTRUE, you must call portYIELD_FROM_ISR to request a context switch immediately after the ISR ends.

Practice

1.

What is the main reason to use FreeRTOS API functions with the FromISR suffix inside an interrupt service routine (ISR)?

easy

A. They disable all interrupts during execution.

B. They are safe to call from ISRs and handle interrupt context correctly.

C. They run tasks faster than normal API functions.

D. They automatically create new tasks inside the ISR.

Solution

1. Step 1: Understand ISR context constraints

   Inside an ISR, normal FreeRTOS API functions are unsafe because they may block or cause race conditions.

2. Step 2: Role of FromISR functions

   Functions with the FromISR suffix are designed to be safe in interrupt context by avoiding blocking and managing critical sections properly.

3. Final Answer:

   They are safe to call from ISRs and handle interrupt context correctly. -> Option B

4. Quick Check:

   FromISR functions = ISR safe calls [OK]

Hint: Use FromISR functions only inside interrupts for safety [OK]

Common Mistakes:

• Calling normal API functions inside ISR causing crashes
• Assuming FromISR functions disable interrupts
• Thinking FromISR creates tasks automatically

2.

Which of the following is the correct way to declare a variable to track if a higher priority task was woken inside an ISR?

?

easy

A. int higherPriorityTaskWoken = 0;

B. bool higherPriorityTaskWoken = false;

C. BaseType_t higherPriorityTaskWoken = pdFALSE;

D. volatile int higherPriorityTaskWoken = 1;

Solution

1. Step 1: Identify FreeRTOS type for ISR task wake flag

   FreeRTOS uses BaseType_t for portability and defines pdFALSE and pdTRUE for boolean values.

2. Step 2: Correct initialization

   The variable must start as pdFALSE to indicate no task was woken yet.

3. Final Answer:

   BaseType_t higherPriorityTaskWoken = pdFALSE; -> Option C

4. Quick Check:

   Use BaseType_t and pdFALSE for ISR flags [OK]

Hint: Use BaseType_t and pdFALSE to track task wake in ISR [OK]

Common Mistakes:

• Using plain int instead of BaseType_t
• Initializing flag to 1 instead of pdFALSE
• Using bool which may not be portable

3.

Consider this ISR code snippet:

BaseType_t higherPriorityTaskWoken = pdFALSE;
xQueueSendFromISR(queue, &data, &higherPriorityTaskWoken);
if (higherPriorityTaskWoken) {
    portYIELD_FROM_ISR();
}

What happens if higherPriorityTaskWoken is set to pdTRUE after xQueueSendFromISR?

medium

A. The ISR requests a context switch to the higher priority task immediately after ISR.

B. The ISR disables all interrupts until the higher priority task runs.

C. The queue send operation fails silently.

D. The higher priority task is blocked until the ISR finishes.

Solution

1. Step 1: Understand higherPriorityTaskWoken flag

   This flag indicates if a task with higher priority than the current one was made ready by the ISR.

2. Step 2: Role of portYIELD_FROM_ISR()

   If the flag is true, calling portYIELD_FROM_ISR() requests a context switch to that higher priority task immediately after ISR exit.

3. Final Answer:

   The ISR requests a context switch to the higher priority task immediately after ISR. -> Option A

4. Quick Check:

   higherPriorityTaskWoken true triggers context switch [OK]

Hint: If higherPriorityTaskWoken true, call portYIELD_FROM_ISR() [OK]

Common Mistakes:

• Thinking interrupts are disabled by portYIELD_FROM_ISR()
• Assuming queue send fails if flag is true
• Believing higher priority task waits for ISR to finish

4.

Identify the error in this ISR code snippet:

void ISR_Handler(void) {
    BaseType_t higherPriorityTaskWoken = pdFALSE;
    xSemaphoreGive(semaphore);
    if (higherPriorityTaskWoken) {
        portYIELD_FROM_ISR();
    }
}

What is the problem here?

medium

A. The variable higherPriorityTaskWoken should be global.

B. The semaphore is given twice causing overflow.

C. The portYIELD_FROM_ISR() call is outside the ISR.

D. The higherPriorityTaskWoken variable is not passed to xSemaphoreGiveFromISR.

Solution

1. Step 1: Check function used for semaphore give

   The code uses xSemaphoreGive, which is not safe inside ISR context.

2. Step 2: Correct ISR-safe function usage

   Inside ISR, xSemaphoreGiveFromISR must be used with higherPriorityTaskWoken passed by reference to track task wake.

3. Final Answer:

   The higherPriorityTaskWoken variable is not passed to xSemaphoreGiveFromISR. -> Option D

4. Quick Check:

   Use FromISR functions with higherPriorityTaskWoken [OK]

Hint: Always pass higherPriorityTaskWoken to FromISR functions [OK]

Common Mistakes:

• Using normal API functions inside ISR
• Not passing higherPriorityTaskWoken pointer
• Declaring higherPriorityTaskWoken as global unnecessarily

5.

You want to send data from an ISR to a task using a queue. Which sequence correctly uses FreeRTOS ISR-safe API functions to do this and ensure the higher priority task runs immediately if woken?

?

hard

A. BaseType_t higherPriorityTaskWoken = pdFALSE;
xQueueSendFromISR(queue, &data, &higherPriorityTaskWoken);
if (higherPriorityTaskWoken) portYIELD_FROM_ISR();

B. xQueueSend(queue, &data, 0);
BaseType_t higherPriorityTaskWoken = pdFALSE;
if (higherPriorityTaskWoken) portYIELD_FROM_ISR();

C. BaseType_t higherPriorityTaskWoken = pdTRUE;
xQueueSendFromISR(queue, &data, NULL);
portYIELD_FROM_ISR();

D. BaseType_t higherPriorityTaskWoken = pdFALSE;
xQueueSend(queue, &data, 0);
portYIELD_FROM_ISR();

Solution

1. Step 1: Use ISR-safe queue send function

   Inside ISR, xQueueSendFromISR must be used with a pointer to higherPriorityTaskWoken.

2. Step 2: Check higherPriorityTaskWoken and yield

   If higherPriorityTaskWoken is set to pdTRUE, call portYIELD_FROM_ISR() to request immediate context switch.

3. Final Answer:

   BaseType_t higherPriorityTaskWoken = pdFALSE; xQueueSendFromISR(queue, &data, &higherPriorityTaskWoken); if (higherPriorityTaskWoken) portYIELD_FROM_ISR(); -> Option A

4. Quick Check:

   Use FromISR + check flag + yield [OK]

Hint: Use xQueueSendFromISR with flag and yield if true [OK]

Common Mistakes:

• Using normal xQueueSend inside ISR
• Not passing higherPriorityTaskWoken pointer
• Calling portYIELD_FROM_ISR unconditionally