configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this FreeRTOS priority check?

Consider the following FreeRTOS configuration snippet and interrupt priority check:

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 5
void ISR_Handler(void) {
    uint8_t priority = get_interrupt_priority();
    if(priority >= configMAX_SYSCALL_INTERRUPT_PRIORITY) {
        printf("Safe to call FreeRTOS API\n");
    } else {
        printf("Unsafe to call FreeRTOS API\n");
    }
}

// Assume get_interrupt_priority() returns 4

What will be printed when ISR_Handler() runs?

FreeRTOS

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 5
void ISR_Handler(void) {
    uint8_t priority = get_interrupt_priority();
    if(priority >= configMAX_SYSCALL_INTERRUPT_PRIORITY) {
        printf("Safe to call FreeRTOS API\n");
    } else {
        printf("Unsafe to call FreeRTOS API\n");
    }
}

// get_interrupt_priority() returns 4

A Unsafe to call FreeRTOS API

B Compilation error due to missing function

C Safe to call FreeRTOS API

D Runtime error due to invalid priority

💡 Hint

Remember lower numeric priority values mean higher urgency in FreeRTOS.

Since the interrupt priority (4) is less than configMAX_SYSCALL_INTERRUPT_PRIORITY (5), it is unsafe to call FreeRTOS API functions from this interrupt.

🧠 Conceptual

intermediate

What does configMAX_SYSCALL_INTERRUPT_PRIORITY control?

In FreeRTOS, what is the role of configMAX_SYSCALL_INTERRUPT_PRIORITY?

A It configures the maximum number of system calls allowed per interrupt.

B It sets the highest interrupt priority from which FreeRTOS API calls are allowed.

C It defines the lowest interrupt priority in the system.

D It disables all interrupts above a certain priority level.

💡 Hint

Think about which interrupts can safely use FreeRTOS API functions.

configMAX_SYSCALL_INTERRUPT_PRIORITY sets the highest (numerically lowest) interrupt priority that can safely call FreeRTOS API functions. Interrupts with higher priority (numerically lower) must not call FreeRTOS API.

🔧 Debug

advanced

Why does this ISR cause a crash when calling FreeRTOS API?

Given this ISR code snippet:

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 3
void ISR_Handler(void) {
    uint8_t priority = get_interrupt_priority(); // returns 2
    vTaskNotifyGiveFromISR(taskHandle, NULL);
}

Why might this cause a system crash?

A The configMAX_SYSCALL_INTERRUPT_PRIORITY value must be set to 0.

B The taskHandle is NULL causing a null pointer dereference.

C vTaskNotifyGiveFromISR requires a different API call for this priority level.

D The interrupt priority (2) is higher than configMAX_SYSCALL_INTERRUPT_PRIORITY (3), so calling FreeRTOS API is unsafe.

💡 Hint

Check the priority comparison rules for calling FreeRTOS API from interrupts.

Interrupts with priority numerically less than configMAX_SYSCALL_INTERRUPT_PRIORITY (meaning higher urgency) must not call FreeRTOS API functions. Here priority 2 is higher than 3, so the call is unsafe and causes a crash.

📝 Syntax

advanced

Which option correctly defines configMAX_SYSCALL_INTERRUPT_PRIORITY for Cortex-M3?

For a Cortex-M3 microcontroller with 4 bits of priority, which definition correctly sets configMAX_SYSCALL_INTERRUPT_PRIORITY to priority level 5?

A #define configMAX_SYSCALL_INTERRUPT_PRIORITY (5 << (8 - 4))

B #define configMAX_SYSCALL_INTERRUPT_PRIORITY 5

C #define configMAX_SYSCALL_INTERRUPT_PRIORITY (5 >> (8 - 4))

D #define configMAX_SYSCALL_INTERRUPT_PRIORITY (5 << 4)

💡 Hint

Remember Cortex-M uses the top bits of the priority byte for priority levels.

Cortex-M3 uses 4 bits for priority, stored in the high bits of an 8-bit register. Shifting 5 left by (8 - 4) = 4 bits correctly positions the priority.

🚀 Application

expert

How many interrupt priorities can safely call FreeRTOS API if configMAX_SYSCALL_INTERRUPT_PRIORITY is 10?

Assuming a system with 256 interrupt priority levels (0 highest, 255 lowest), and configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 10, how many interrupt priority levels can safely call FreeRTOS API functions?

A 245 priority levels (11 through 255 inclusive)

B 10 priority levels (1 through 10 inclusive)

C 246 priority levels (10 through 255 inclusive)

D 256 priority levels (all priorities)

💡 Hint

Count all priorities numerically greater than or equal to configMAX_SYSCALL_INTERRUPT_PRIORITY.

Interrupt priorities from 10 up to 255 inclusive can safely call FreeRTOS API. That is 246 levels total.

Practice

1.

What is the main purpose of configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOS?

easy

A. To set the highest interrupt priority that can safely call FreeRTOS API functions

B. To define the lowest priority for all interrupts

C. To disable all interrupts during task switching

D. To set the priority of the idle task

Solution

1. Step 1: Understand the role of interrupt priorities in FreeRTOS

   FreeRTOS requires controlling which interrupts can call its API to maintain system stability.

2. Step 2: Identify what configMAX_SYSCALL_INTERRUPT_PRIORITY controls

   This setting defines the highest priority an interrupt can have to safely call FreeRTOS API functions.

3. Final Answer:

   To set the highest interrupt priority that can safely call FreeRTOS API functions -> Option A

4. Quick Check:

   configMAX_SYSCALL_INTERRUPT_PRIORITY = highest safe interrupt priority [OK]

Hint: It limits which interrupts can use FreeRTOS API safely [OK]

Common Mistakes:

• Confusing it with lowest interrupt priority
• Thinking it disables interrupts
• Assuming it sets task priorities

2.

Which of the following is the correct way to define configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h for Cortex-M with 4 priority bits?

#define configMAX_SYSCALL_INTERRUPT_PRIORITY  ( ??? )

easy

A. 0x10

B. 0xF0

C. 0x01

D. 0xFF

Solution

1. Step 1: Understand Cortex-M priority encoding

   With 4 priority bits, priorities range from 0x00 (highest) to 0xF0 (lowest) in 8-bit registers.

2. Step 2: Identify correct value for configMAX_SYSCALL_INTERRUPT_PRIORITY

   This value must be set to a priority level that masks interrupts above it; commonly 0xF0 is used to allow lower priority interrupts to call FreeRTOS API.

3. Final Answer:

   0xF0 -> Option B

4. Quick Check:

   4 bits priority max syscall = 0xF0 [OK]

Hint: Use 0xF0 for 4-bit priority Cortex-M systems [OK]

Common Mistakes:

• Using 0xFF which is invalid for 4 bits
• Using 0x10 which is too high priority
• Confusing priority bits with interrupt numbers

3.

Given the following FreeRTOS configuration snippet for a Cortex-M processor with 3 priority bits:

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 0x20

void ISR_Handler(void) {
    /* This interrupt calls FreeRTOS API */
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xSemaphoreGiveFromISR(&xSemaphore, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

What will happen if this ISR runs at priority 0x10?

medium

A. System may crash or behave unpredictably due to priority violation

B. ISR runs normally and FreeRTOS API calls succeed

C. ISR is masked and never runs

D. FreeRTOS disables all interrupts during ISR

Solution

1. Step 1: Compare ISR priority with configMAX_SYSCALL_INTERRUPT_PRIORITY

   ISR priority 0x10 is higher (numerically lower) than 0x20, which is the max allowed to call FreeRTOS API.

2. Step 2: Understand consequences of calling API at too high priority

   Calling FreeRTOS API from an interrupt with priority above configMAX_SYSCALL_INTERRUPT_PRIORITY can cause system instability or crashes.

3. Final Answer:

   System may crash or behave unpredictably due to priority violation -> Option A

4. Quick Check:

   ISR priority < max syscall priority = crash risk [OK]

Hint: ISR priority must be equal or lower than max syscall priority [OK]

Common Mistakes:

• Assuming ISR always runs safely
• Confusing higher priority with higher numeric value
• Thinking ISR is masked automatically

4.

In a FreeRTOS project, the system crashes intermittently. The configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x40. An ISR running at priority 0x20 calls FreeRTOS API functions. What is the likely cause and how to fix it?

medium

A. ISR should not call FreeRTOS API; remove API calls from ISR

B. configMAX_SYSCALL_INTERRUPT_PRIORITY is too low; increase it to 0x10

C. ISR priority is too high; lower ISR priority to 0x40 or higher

D. No issue; crash caused by unrelated code

Solution

1. Step 1: Analyze priority levels

   ISR priority 0x20 is higher (numerically lower) than configMAX_SYSCALL_INTERRUPT_PRIORITY 0x40, violating the allowed priority range for API calls.

2. Step 2: Fix by adjusting ISR priority

   Lower ISR priority number to 0x40 or numerically higher (meaning lower priority) so it complies with configMAX_SYSCALL_INTERRUPT_PRIORITY.

3. Final Answer:

   ISR priority is too high; lower ISR priority to 0x40 or higher -> Option C

4. Quick Check:

   ISR priority must be >= configMAX_SYSCALL_INTERRUPT_PRIORITY [OK]

Hint: ISR priority must not exceed max syscall priority [OK]

Common Mistakes:

• Increasing max syscall priority instead of lowering ISR priority
• Removing API calls unnecessarily
• Ignoring priority number direction (lower number = higher priority)

5.

You have a FreeRTOS system on a Cortex-M7 with 5 priority bits. You want to allow interrupts with priority 16 and lower (numerically higher) to call FreeRTOS API safely. What should configMAX_SYSCALL_INTERRUPT_PRIORITY be set to?

Note: Priority values are shifted left to fill the 8-bit priority register.

hard

A. 0x40

B. 0x10

C. 0x20

D. 0x80

Solution

1. Step 1: Calculate shifted priority value

   With 5 priority bits, priorities are left-shifted by (8 - 5) = 3 bits. Priority 16 decimal = 0x10 hex. Shift left by 3 bits: 0x10 << 3 = 0x80.

2. Step 2: Match shifted value to options

   0x80 matches 0x80, confirming the correct shifted priority value.

3. Final Answer:

   0x80 -> Option D

4. Quick Check:

   Priority 16 << 3 bits = 0x80 [OK]

Hint: Shift priority left by (8 - priority bits) to get config value [OK]

Common Mistakes:

• Not shifting priority bits correctly
• Confusing decimal and hex values
• Choosing unshifted priority values