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 configMAXSYSCALLINTERRUPTPRIORITY. FreeRTOS expects this priority to be stored in the upper nibble of configMAXSYSCALLINTERRUPTPRIORITY for this specific core.

configMAXSYSCALLINTERRUPTPRIORITY 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 configMAXSYSCALLINTERRUPTPRIORITY shall never be set to zero.

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

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 configMAXSYSCALLINTERRUPT_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( configMAXSYSCALLINTERRUPTPRIORITY & CM3PRIORITY_MASK );

where CM3PRIORITYMASK is 0xF0.

Matthias

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 configMAXSYSCALLINTERRUPTPRIORITY and configKERNELINTERRUPT_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).