# configASSERT when configMAX\_SYSCALL\_INTERRUPT\_PRIORITY = 1 with 8 priority bits

**URL:** <https://forums.freertos.org/t/configassert-when-configmax-syscall-interrupt-priority-1-with-8-priority-bits/22792>\
**Category:** Kernel\
**Created:** [March 20, 2025, 1:31pm UTC](https://forums.freertos.org/t/configassert-when-configmax-syscall-interrupt-priority-1-with-8-priority-bits/22792 "2025-03-20T13:31:35Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![junkangler](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/junkangler/32/5482_2.png) [@junkangler](https://forums.freertos.org/u/junkangler)\
**Post date:** [March 20, 2025, 1:31pm UTC](https://forums.freertos.org/t/configassert-when-configmax-syscall-interrupt-priority-1-with-8-priority-bits/22792/1 "2025-03-20T13:31:35Z")

</div>

Hello,  
I am using ARM Cortex-M85 with FreeRTOS v11.1.0.  
In system, we are using 8 priority bits and configured configMAX\_SYSCALL\_INTERRUPT\_PRIORITY to 1.  
And it seems this raises below configASSERT in function xPortStartScheduler() of port.c file.

```auto
        if( ulImplementedPrioBits == 8 )
        {
            /* When the hardware implements 8 priority bits, there is no way for
             * the software to configure PRIGROUP to not have sub-priorities. As
             * a result, the least significant bit is always used for sub-priority
             * and there are 128 preemption priorities and 2 sub-priorities.
             *
             * This may cause some confusion in some cases - for example, if
             * configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 5, both 5 and 4
             * priority interrupts will be masked in Critical Sections as those
             * are at the same preemption priority. This may appear confusing as
             * 4 is higher (numerically lower) priority than
             * configMAX_SYSCALL_INTERRUPT_PRIORITY and therefore, should not
             * have been masked. Instead, if we set configMAX_SYSCALL_INTERRUPT_PRIORITY
             * to 4, this confusion does not happen and the behaviour remains the same.
             *
             * The following assert ensures that the sub-priority bit in the
             * configMAX_SYSCALL_INTERRUPT_PRIORITY is clear to avoid the above mentioned
             * confusion. */
            configASSERT( ( configMAX_SYSCALL_INTERRUPT_PRIORITY & 0x1U ) == 0U );
            ulMaxPRIGROUPValue = 0;
        }

```

Does this mean if the number of implemented priority bits is 8 then we can only set the configMAX\_SYSCALL\_INTERRUPT\_PRIORITY to an **even** number(2, 4, 6, …)?

---

<div class="post-metadata">

**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:** [March 20, 2025, 2:22pm UTC](https://forums.freertos.org/t/configassert-when-configmax-syscall-interrupt-priority-1-with-8-priority-bits/22792/2 "2025-03-20T14:22:50Z")

</div>

> [@junkangler](#):
>
> Does this mean if the number of implemented priority bits is 8 then we can only set the configMAX\_SYSCALL\_INTERRUPT\_PRIORITY to an **even** number(2, 4, 6, …)?

Yes, you are exactly right. The explanation is given in the comments. Please change `configMAX_SYSCALL_INTERRUPT_PRIORITY` to 2.

---

<div class="post-metadata">

**Author:** ![junkangler](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/junkangler/32/5482_2.png) [@junkangler](https://forums.freertos.org/u/junkangler)\
**Post date:** [March 21, 2025, 12:44am UTC](https://forums.freertos.org/t/configassert-when-configmax-syscall-interrupt-priority-1-with-8-priority-bits/22792/3 "2025-03-21T00:44:30Z")

</div>

OK, Thanks for the information!