jmaygarden wrote on Tuesday, March 23, 2010:
I though that the priority could be equal to configMAX_SYSCALL_INTERRUPT_PRIORITY or lower (higher number for Cortex-M3). That worked just fine for me with an STM32, but the SAM3U is having issue with it. I set configMAX_SYSCALL_INTERRUPT_PRIORITY to configKERNEL_INTERRUPT_PRIORITY (as shown below) and it alleviated my problem. So, I know it is definitely related to interrupt priorities.
#define configKERNEL_INTERRUPT_PRIORITY (0x0F << 4) /* Priority 15, or 255 as only the top four bits are implemented. This is the lowest priority. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (0x05 << 4) /* Priority 5, or 80 as only the top four bits are implemented. */
#define configKERNEL_INTERRUPT_PRIORITY (255)
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (255)
I’m pretty sure I even tried using configKERNEL_INTERRUPT_PRIORITY for all of my interrupts and that didn’t do the trick either.
Also, the problem is occurring with a xQueueSendFromISR from the real-time timer (RTT) alarm at 100 Hz. That module is very quirky. You have to poll the alarm status for 2 slow-clock cycles before exiting the interrupt. That makes the ISR take about 60 microseconds. I don’t like that one bit and perhaps it could mess up the kernel if its interrupts are blocked during that time?