kernal and syscall interrupt priority

sloren wrote on Wednesday, May 26, 2010:


I have a problem with configKERNEL_INTERRUPT_PRIORITY and configMAX. I’m using port for Cortex-M3 architecture. I’m using following set of configuration parameters:

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 191 /* equivalent to 0xb0, or priority 11. */

which is the standard configuration of the kernel. I have an interrupt that uses “fromISR” API calls and I have configured this interrupt to have priority of 12 (0x0c). I found the kernel stucked in ‘list.c’ where there is following comment note (line: 134):

/* *** NOTE ***********************************************************
If you find your application is crashing here then likely causes are:
1) Stack overflow -
2) Incorrect interrupt priority assignment, especially on Cortex M3
   parts where numerically high priority values denote low actual
   interrupt priories, which can seem counter intuitive.  See
3) Calling an API function from within a critical section or when
   the scheduler is suspended.
4) Using a queue or semaphore before it has been initialised or
   before the scheduler has been started (are interrupts firing
   before vTaskStartScheduler() has been called?).
See for more tips.

I have no kernel problems if I use that interrupt priority of 15 which is acutally equal to configKERNEL_INTERRUPT_PRIORITY in my case. As far as documentation concerned (More Advanced -> Customization) it is possible to use interrupts that can interrupt kernel-related interrupts as long as priority of those preemptive interrupts are kept lower (in Cortex-M3 arch higher) than configMAX_SYSCALL_INTERRUPT_PRIORITY. I did so in the first case but my application tends to crash anyway.
Has anybody had similar problem?

rtel wrote on Friday, May 28, 2010:

Also be very careful with the function that you use to set the interrupt priority.  Some require the priority to be shifted up into the most significant bits, while others don’t.  For example, if you are using a Stellaris Cortex-M3 then there will be three bits implemented, but these are to most significant three bits.  To set a priority to 5 using the StellarisWare functions you would have to actually pass in (5<<5), whereas using a CMSIS function you would just pass in (5).


sloren wrote on Monday, May 31, 2010:

I’m using STM32 uC with ST drivers. I have checked if I set the interrupt priority ok in my application and everything seems to be OK. My question is: Is it possible to use interrupts priorities between configMAX_SYSCALL_INTERRUPT_PRIORITY and configKERNEL_INTERRUPT_PRIORITY for interrupts calling FreeRTOS API (as stated in documentation) or it is just not safe? My application doesn’t crash immediately but after some time which is totally random. I know that it could be caused by some other ‘mistakes’ but I have tripple checked and simplified my code just to be sure I don’t cross any of hints mentioned among those 4 points. When I look into the serial example of FreeRTOS distribution I find serial interrupt priority set at configKERNEL_INTERRUPT_PRIORITY level.

davedoors wrote on Monday, May 31, 2010:

Only API functions that have FromISR in their name can be called in an ISR, but these can be called in all interrupts that have a priority equal to or between the KERNEL_INTERRUPT_PRIORITY and MAX_SYSCALL_INTERRUPT_PRIORITY constants.