Confusing docs on interrupt priority on ARM CM3 trigger configAssert

Kernel
1

Hello,
I just upgraded from FreeRtos 10.4.3 to 11.1 while debugging some odd timer-task related issues.
After upgrading I ran into a configAssert in the port.c file line 340:

/* Check that the bits not implemented in hardware are zero in
  * configMAX_SYSCALL_INTERRUPT_PRIORITY. */
configASSERT( ( configMAX_SYSCALL_INTERRUPT_PRIORITY & ( ~ucMaxPriorityValue ) ) == 0U );

This seems to be contradicting the information provided in 04-Demos/ARM-Cortex/RTOS-Cortex-M3-M4:
(I am too new to post links, I hope this is enough to find the right page in the docs:
Documentation/02-Kernel/03-Supported-devices/04-Demos/ARM-Cortex/RTOS-Cortex-M3-M4)

Bits zero to four can take any value, although, for future proofing and maximum compatibility, they should be set to one.

I am running on SIlicon labs EFM32JG, basically ARM CM3 and I have an issue where on one of my devices in rare circumstances the timer task seems to crash, as in my timer callbacks are not executed anymore. I am not sure if it is due to a deadlock or what exactly happens, as I struggle to reproduce it on purpose. However I had a suspicion it could be interrupt config related, as the symptoms seem to match.
After scrutinizing the interrupt config for hours and hours I came to the conclusion that I was following all best practices but apparently FreeRtos V11 disagrees.
So I am wondering, do the values in the lower bits of the interrupt priority register actually matter? And if yes, could that lead to weird behavior in the timer task?
At least though the doc seems to need an update, as the current advice to set the lower bits to 1 creates a configAssert error

2

If you are referring to the port.c file in FreeRTOS-Kernel/portable/GCC/ARM_CM3, then I do not think you are on the right track. This assert is raised during xTaskStartScheduler, ie during system setup, not in a running system. I suspect interrupts enabled before you start the scheduler. In a “properly” constructed FreeRTOS system, there should not be any concurrency before the schduler starts, so no intermittent issues at that point.

3

The bits don’t affect the hardware, but I believe recent version of the code require them to be 0 as otherwise priorites that might be expected to not be affected by critical sections (as below the threshold priority) would be (since they match the mask when it ignores the bottom bits).

As RAc says, that shouldn’t cause your problems.

4

Thanks for the replies. I was mainly trying to point out that the docs for the ARM port need an update with regard to the new configAssert. As for my issue, the symptoms are pointing towards the timer queue being full and not serviced anymore for some reason. My timer task is the highest priority in the application, so it’s unlikely IMHO that it would not be able to service the queue if it was still running normally. I am running in a tickless idle low-power config, that sends the MCU to sleep during idle. We are currently trying to get on top of it by transforming periodically running tasks to just use waits instead of being timer-triggered, but it is still odd. I don’t get a task exit error either, so it points to a deadlock of the timer task somehow.
I a aware of the issue that you shouldn’t call timer functions from within timer callbacks and have scanned my code left right and center for such instances. I couldn’t find any. Are there any other scenarios you could think of that could deadlock the timer task?
ANy known bugs around tickless idle or in previous RTOS versions that anyone remembers?

5

Would you please point to the section of the doc that needs to be updated. I cannot find where we recommend to set the unused bits as 1.

None of the timer callback can block. Is there any timer callback in your application that can block ever (for example, an assert that may fail)?

Can you break the code in the debugger and see what it is doing when it appears stuck?

PS- you should be able to post links now.

6

The part in the docs is here: Running the RTOS on a ARM Cortex-M Core - FreeRTOS™

In the section “Cortex-M Internal Priority Representation” In the first paragraph and the example pictures it says/shows that the unused bits should be 1

7

That section talks about the hardware implementation and shows that unimplemented bits have no impact on the effective priority. We will see if we can update something here - Customization - FreeRTOS™.

8

The way I would debug this is to increment counters before and after each timer callback invocation (ie add debug code in the timer task logic), wait for the problem to occur and then check which pair (if at all) has a delta of 1 between in and out counters, then work your way down the affected timer. If all pairs should match when the problem occurrs, it is not an issue in the timer callbacks but in the timer task itself. I am fairly certain that there are no bugs in the timer task logic, with the possible exception that if there is a debug output redirected to, say, serial UARTs, there may be problems in the implementation of the output logic.