# Adding additional asserts for valid priority levels to cortex m4 port **URL:** \ **Category:** Kernel\ **Created:** [December 15, 2022, 7:06am UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393 "2022-12-15T07:06:41Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![chrisnc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/chrisnc/32/3101_2.png) [@chrisnc](https://forums.freertos.org/u/chrisnc)\ **Post date:** [December 15, 2022, 7:06am UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/1 "2022-12-15T07:06:41Z")
I realized the `configKERNEL_INTERRUPT_PRIORITY` and `configMAX_SYSCALL_INTERRUPT_PRIORITY` macros in my example configuration were incorrect; I assumed it would be shifted into the available `configPRIO_BITS` internally, but this is not the case. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [December 15, 2022, 10:45am UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/2 "2022-12-15T10:45:05Z")
Glad that you figured it. ---
**Author:** ![chrisnc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/chrisnc/32/3101_2.png) [@chrisnc](https://forums.freertos.org/u/chrisnc)\ **Post date:** [December 15, 2022, 4:16pm UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/3 "2022-12-15T16:16:05Z")
Yeah, though I am a little surprised there isn’t an assert in the port to catch this kind of issue; there are several asserts in the port already related to the priority masks, but none that confirm that the chosen priorities are nonzero _with respect to_ the `configPRIO_BITS` parameter or the hardware. Maybe these could be added? ---
**Author:** ![chrisnc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/chrisnc/32/3101_2.png) [@chrisnc](https://forums.freertos.org/u/chrisnc)\ **Post date:** [December 15, 2022, 5:31pm UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/4 "2022-12-15T17:31:18Z")
Here is a patch that accomplishes this. (The existing assert on the unmasked `configMAX_SYSCALL_INTERRUPT_PRIORITY` is obviated by the masked check.) I tested it on my board and it catches my original problem. ```diff diff --git a/portable/GCC/ARM_CM4F/port.c b/portable/GCC/ARM_CM4F/port.c index b946e6e94..bd0a37ad3 100644 --- a/portable/GCC/ARM_CM4F/port.c +++ b/portable/GCC/ARM_CM4F/port.c @@ -295,10 +295,6 @@ static void prvPortStartFirstTask( void ) */ BaseType_t xPortStartScheduler( void ) { - /* configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to 0. - * See https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html */ - configASSERT( configMAX_SYSCALL_INTERRUPT_PRIORITY ); - /* This port can be used on all revisions of the Cortex-M7 core other than * the r0p1 parts. r0p1 parts should use the port from the * /source/portable/GCC/ARM_CM7/r0p1 directory. */ @@ -329,6 +325,15 @@ BaseType_t xPortStartScheduler( void ) /* Use the same mask on the maximum system call priority. */ ucMaxSysCallPriority = configMAX_SYSCALL_INTERRUPT_PRIORITY & ucMaxPriorityValue; + /* Check that the maximum system call priority and the kernel interrupt + * priority are valid (nonzero) after accounting for the number of + * priority bits supported by the hardware. A priority of 0 is invalid + * for either, because setting the BASEPRI register to 0 unmasks all + * interrupts, and interrupts with priority 0 cannot be masked using + * BASEPRI. See https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html */ + configASSERT( ucMaxSysCallPriority ); + configASSERT( configKERNEL_INTERRUPT_PRIORITY & ucMaxPriorityValue ); + /* Calculate the maximum acceptable priority group value for the number * of bits read back. */ ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS; ``` ---
**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\ **Post date:** [December 15, 2022, 8:09pm UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/5 "2022-12-15T20:09:37Z")
The change from `configMAX_SYSCALL_INTERRUPT_PRIORITY` to `ucMaxSysCallPriority` is a nice improvement. 👍 However, if we add a check on `configKERNEL_INTERRUPT_PRIORITY`, it may be better to check that it is set to the lowest priority as required by this port. `configASSERT( ( configKERNEL_INTERRUPT_PRIORITY & ucMaxPriorityValue ) == ucMaxPriorityValue );` ---
**Author:** ![chrisnc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/chrisnc/32/3101_2.png) [@chrisnc](https://forums.freertos.org/u/chrisnc)\ **Post date:** [December 15, 2022, 8:24pm UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/6 "2022-12-15T20:24:23Z")
Yeah, that makes sense. I will make a PR for this later and get more feedback there. ---
**Author:** ![chrisnc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/chrisnc/32/3101_2.png) [@chrisnc](https://forums.freertos.org/u/chrisnc)\ **Post date:** [December 16, 2022, 4:00am UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/7 "2022-12-16T04:00:47Z")
PR here: [Add more interrupt priority asserts for ARM\_CM3, ARM\_CM4, and ARM\_CM7 by chrisnc · Pull Request #602 · FreeRTOS/FreeRTOS-Kernel · GitHub](https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/602) ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [December 16, 2022, 9:24am UTC](https://forums.freertos.org/t/adding-additional-asserts-for-valid-priority-levels-to-cortex-m4-port/16393/8 "2022-12-16T09:24:37Z")
Thank you for your contribution. I left some comments on the PR.