I’m using an The Texas Instruments CC3200 (ARM Cortex M4 microprocessor) with FreeRTOS 10.0.1
I’ve been reading and reading about interrupt priorities, but am left very confused. I’d like to explain what I’ve managed to get working for me and then use that as a starting point for asking questions.
My working setup:
-configMAX_PRIORITIES = 10
-configKERNEL_INTERRUPT_PRIORITY = 7 << 5
-configMAX_SYSCALL_INTERRUPT_PRIORITY = 1 << 5
-I have a 4 tasks with priorities 2, 3, 4, 5
-The Texas Instruments Simplelink task has priority of 9 (configMAX_PRIORITIES - 1)
-I have one hardware/peripheral interrupt set to priority level 3.
Questions:
-Can configMAX_PRIORITIES actually go up to 15?
-For hardware/peripheral interrupts on this MCU, lower numerical value is a higher priority. But, in regards to FreeRTOS tasks created with the xTaskCreate() function, numerically higher values have a priority. Are these statements accurate?
-I thought it would best/safest to set configMAX_SYSCALL_INTERRUPT_PRIORITY to 6, but when doing that the system hangs at xQueueSemaphoreTake() within a few minutes after starting. So, my understanding of configMAX_SYSCALL_INTERRUPT_PRIORITY must be incorrect. Can you please help me understand how this value works specifically related to my setup?
The Cortex-M does make this complex, as per our attempt at describing here RTOS for ARM Cortex-M
This implies there are three priority bits implemented. Is that correct? The CC3200 datasheet I just downloaded says “Bits of priority configurable from 3 to 8” but I’ve never used a Cortex-M where the number of bits was configurable. FreeRTOS V10.2.1 and up will check the number of configuration bits if you have configASSERT() defined.
If there are three priority bits then 7<<5 would seem correct as it will have all three bits set, which in turn means the kernel priority is the lowest possible (which is recommended).
Again assuming there are three priority bits, that defines the maximum system call interrupt priority to (in effect ignoring shifting) be 1. That means you can call interrupt safe FreeRTOS API functions from all interrupt priorities other than 0, 0 rather confusingly being the highest interrupt priority so ‘above’ 1.
Which is below configMAX_SYSCALL_INTERRUPT_PRIORITY as higher numbers denote lower interrupt priority values.
These settings have nothing to do with interrupt priorities as they are task priorities - tasks being controlled by software and only running when there are no interrupts executing.
Yes - this is totally unrelated to hardware. If configUSE_PORT_OPTIMISED_TASK_SELECTION is set to 1 then its maximum value is 32 because the optimized algorithm uses a bitmap stored in a 32-bit variable, otherwise it can be any value you like within reason but for efficiency we recommend to make it no bigger than necessary.
Yes. We try and keep things logical - higher means higher - ARM on the other hand…
Again assuming there are three priority bits (you really need to check that - is __NVIC_PRIO_BITS defined anywhere? If so that will most likely hold the right value.) then the value would be 6<<5, not just 6. If you set it to just 6 then the effect would be to actually set it to 0 as only the top (most significant) bits are implemented - writing to any other bit is ignored.
When it hangs, is it in an assert(). Do you have configASSERT() defined? If not would definitely recommend doing so - would also recommend updating your FreeRTOS version as newer versions have more configASSERT() points.
The Cortex-M does make this complex, as per our attempt at describing here