using FreeRTOS API in ISRs ( Cortex M3)

bodev wrote on Thursday, November 13, 2008:

Hi all,
   In my project i am using FreeRTOS 5.1.0 with Ride/GCC

Utilizing Queues and Semaphores within ISRs (DMA and USART) I have noticed that sometimes FreeRTOS "hang" in vListInsert, line 130. Unfortunately seems to be not predicatable and so it is hard to reproduce.

i am pretty sure that i am using the right APIs and interrupt priorities.

I have seen a similar problem in an old thread and one user was experiencing the same exact behavior:
Object: “Queue Problem (solved’ish)”
Author: DaWorm
Date: 2008-08-14 14:36

I was wondering if you guys can have an idea of what is happening.


rtel wrote on Friday, November 14, 2008:

The most common cause of a hang on this line is a stack overflow.  However, on the Cortex in particular another common cause is incorrect interrupt priority assignments (note interrupt priorities, not task priorities).

See the notes in red at the bottom of this section

Basically - because the Cortex uses low numeric values to denote high priorities it is very easy to get assignments the wrong way around, and the diagram on the above referenced page would be the other way up (for the Cortex only).

Another think that can cause this is calling a blocking function from within a critical section.


bodev wrote on Saturday, November 15, 2008:

Hi Richard and thank you very much.
Actually I am aware of the Cortex assigments of ISR priorities and i do not notice any stack overflow with the FreeRTOS "stack check" functionalities turned on.

Anyway, i will try some more testing. thanks for the hints.

However, i have another question probably of general interest regarding Interrupt priorities:
i am a little bit confused on two config lines in FreeRTOS:

#define configKERNEL_INTERRUPT_PRIORITY         255
#define configMAX_SYSCALL_INTERRUPT_PRIORITY     191 /* equivalent to 0xa0, or priority 5. */

how is the mapping from 0-15 in STM32 and FreeRTOS priorities?


rlagace wrote on Monday, November 17, 2008:


The last it happened to me, it was because I had forgotten to initialize the priority group of the NVIC. You can use the following line on a STM32:

NVIC_PriorityGroupConfig (NVIC_PriorityGroup_4);