sloren wrote on Wednesday, May 26, 2010:
Hi,
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 configKERNEL_INTERRUPT_PRIORITY 255
#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 -
see http://www.freertos.org/Stacks-and-stack-overflow-checking.html
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
configMAX_SYSCALL_INTERRUPT_PRIORITY on http://www.freertos.org/a00110.html
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 http://www.freertos.org/FAQHelp.html 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?