2019-06-04 07:41 PM
I using hte RTOS middlewares within CubeMX but I have an ISR routine that can't be interrupted by the RTOS how can I do this?
Many Thanks,
Glenn
2019-06-04 09:38 PM
There is probably some way to configure the BASEPRI value. Higher priority interrupts (lower number) are not nested, lower priority interrupts are.
In FreeRTOS that's the configMAX_API_CALL_INTERRUPT_PRIORITY.
2019-06-04 10:42 PM
Interrupt nesting is done by NVIC, not RTOS!
https://www.freertos.org/a00110.html
configMAX_SYSCALL_INTERRUPT_PRIORITY sets the highest interrupt priority from which interrupt safe FreeRTOS API functions can be called.
Therefore You can make higher priority interrupts, but You must not use FreeRTOS API from these. Set that real-time ISR at priority 0 and all other interrupts at lower priorities.
2019-06-05 09:10 AM
FreeRTOS does it setting NVIC BASEPRI. And one shouldn't change that without the OS knowing.
From the ARMv7-M ARM:
"BASEPRI
The base priority mask, an 8-bit register. BASEPRI changes the priority level required for exception
preemption. It has an effect only when BASEPRI has a lower value than the unmasked priority level
of the currently executing software.
The number of implemented bits in BASEPRI is the same as the number of implemented bits in each
field of the priority registers, and BASEPRI has the same format as those fields. For more
information see Maximum supported priority value on page B1-526.
A value of zero disables masking by BASEPRI.
Unprivileged accesses are RAZ/WI."
2019-06-14 07:12 AM
BASEPRI is core register, not NVIC. Anyway I'm not suggesting to touch it at all. What I'm saying is - it's perfectly legal to set NVIC interrupts to priorities higher than configMAX_SYSCALL_INTERRUPT_PRIORITY if those doesn't use FreeRTOS APIs.
2019-06-14 09:19 AM
You are right in that using higher priority than configMAX_SYSCALL_INTERRUPT_PRIORITY is perfectly legal and quite simple way. And I didn't recommend changing BASEPRI just like that. FreeRTOS may start acting very weird if that is done.