Usage of configMAX_SYSCALL_INTERRUPT_PRIORITY on STM32 Cortex M3

gourmetsel wrote on Friday, August 05, 2016:

I’m using an STM32F10 microcontroller with FreeRTOS V8.2.3 port for the Cortex M3. The microcontroller has four priority bits implemented. I understood that the highest priority of any interrupt using system calls is defined by configMAX_SYSCALL_INTERRUPT_PRIORITY. FreeRTOS expects this priority to be stored in the upper nibble of configMAX_SYSCALL_INTERRUPT_PRIORITY for this specific core.

configMAX_SYSCALL_INTERRUPT_PRIORITY will be written to the BASEPRI register to enter a critical section and zero will be written to it when exiting the critical section (basically this disables the function of BASEPRI). This is the reason why configMAX_SYSCALL_INTERRUPT_PRIORITY shall never be set to zero.

I saw in xPortStartScheduler in port.c that configMAX_SYSCALL_INTERRUPT_PRIORITY is explicitly asserted to being non-zero:
configASSERT( configMAX_SYSCALL_INTERRUPT_PRIORITY );

I just wanted to share that it might make sense to include the position of the priority bits of the particular core into this assertion. For the microcontroller I’m using in this case, I could set configMAX_SYSCALL_INTERRUPT_PRIORITY to 0x0F, not get the assertion to fail, but still break the critical section mechanism.

In this case the assert could look like:

configASSERT( configMAX_SYSCALL_INTERRUPT_PRIORITY & CM3_PRIORITY_MASK );

where CM3_PRIORITY_MASK is 0xF0.

Matthias

rtel wrote on Friday, August 05, 2016:

Thank you for the interesting input.

There is no real portable way of achieving this without adding in
additional dependencies on the FreeRTOSConfig.h values, as currently
only configMAX_SYSCALL_INTERRUPT_PRIORITY and
configKERNEL_INTERRUPT_PRIORITY are mandated. However, the code does
manually check the number of priority bits implemented by testing the
hardware directly - so the assert could then be moved to that part of
the code (where the number of bits is known).