# STM32F4 Interrupt Priority Issue Calling xQueueReceiveFromISR

**URL:** <https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529>\
**Category:** Libraries\
**Tags:** debug\
**Created:** [January 13, 2021, 6:24pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529 "2021-01-13T18:24:08Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jhausle](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jhausle](https://forums.freertos.org/u/jhausle)\
**Post date:** [January 13, 2021, 6:24pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529/1 "2021-01-13T18:24:08Z")

</div>

Hello, I am using STM32F4 with FreeRTOS. I have read through all the documentation multiple times and believe I have the interrupt priorities set correctly in my FreeRTOSConfig.h but am still getting an assert failure on priorities when calling xQueueReceiveFromISR in a CAN Rx ISR on rare occassions. The following is my FreeRTOSConfig.h snippet:

```
#define configPRIO_BITS 4
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5
#define configKERNEL_INTERRUPT_PRIORITY (configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS))
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS))

```

The PriorityGrouping is set to NVIC\_PRIORITYGROUP\_4 as advised. The CAN Rx ISR priority is set to 5 at bootup before the scheduler is started and the following is what the ISR looks like:

```
void HAL_CAN_TxMailbox0CompleteCallback(CAN_HandleTypeDef* hcan) {
  can_frame_t message;
  if (xQueueReceiveFromISR(can_rx_queue, &message, NULL) == pdPASS) {
    (CAN_transmit_frame(hcan1, message.header.StdId, message.data, message.header.DLC);
  }
}

```

Sometimes I will get a fault due to an assert hitting from the function: `portASSERT_IF_INTERRUPT_PRIORITY_INVALID()` in queue.c which then calls `configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );` in port.c

---

<div class="post-metadata">

**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\
**Post date:** [January 13, 2021, 7:12pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529/2 "2021-01-13T19:12:31Z")

</div>

Can you see in the debugger what is the value of `ulMaxPRIGROUPValue` when the assertion fails? I’m guessing that field is corrupted or not yet established by FreeRTOS startup code.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [January 13, 2021, 7:17pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529/3 "2021-01-13T19:17:56Z")

</div>

Also, can you check the value of current priority grouping in addition to `ulMaxPRIGROUPValue` in the debugger? You can update the code to the following to get the current priority grouping:

```auto
volatile uint32_t ulCurrentInterruptGrouping;
ulCurrentInterruptGrouping = ( portAIRCR_REG & portPRIORITY_GROUP_MASK );
configASSERT( ulCurrentInterruptGrouping <= ulMaxPRIGROUPValue );

```

Thanks.

---

<div class="post-metadata">

**Author:** ![jhausle](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jhausle](https://forums.freertos.org/u/jhausle)\
**Post date:** [January 13, 2021, 9:21pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529/4 "2021-01-13T21:21:27Z")

</div>

I was able to recreate and you are correct, it looks like `ulMaxPRIGROUPValue` is corrupted and set to 0 in this case.  
Do you have any idea how/why this would happen? There are definitely interrupts triggering before the tasks are created and scheduler is started, could this be contributing?

---

<div class="post-metadata">

**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\
**Post date:** [January 13, 2021, 9:49pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529/5 "2021-01-13T21:49:58Z")

</div>

> [@jhausle](#):
>
> There are definitely interrupts triggering before the tasks are created and scheduler is started, could this be contributing?

Yes, I think you’re onto it there. If your ISRs make API calls to FreeRTOS, best to make sure FreeRTOS is up and running before enabling those interrupts.

---

<div class="post-metadata">

**Author:** ![jhausle](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jhausle](https://forums.freertos.org/u/jhausle)\
**Post date:** [January 13, 2021, 10:24pm UTC](https://forums.freertos.org/t/stm32f4-interrupt-priority-issue-calling-xqueuereceivefromisr/11529/6 "2021-01-13T22:24:58Z")

</div>

That was it! I was able to move the interrupt enable after the scheduler was started and this fixed it.  
Root cause was that this interrupt was firing before `ulMaxPRIGROUPValue` could get set to a non-zero value and was causing an assert.  
Takeaway - Any ISR that has an RTOS function call with FromISR must be enabled after the scheduler has been started.  
Thanks for the help!