Task stuck in ready state on cortex-M33

Kernel
22

I check the code of portSET_INTERRUPT_MASK_FROM_ISR(), it seems to have disabled all interrupt… That’s an interesting question and I need to rethink about the reason.

23

This does not seem correct. You need to shift this value according to the number of priority bits implemented by your hardware. You can looks at this for an example -

#ifdef __NVIC_PRIO_BITS
	#define configPRIO_BITS						__NVIC_PRIO_BITS
#else
	#define configPRIO_BITS						4
#endif

#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

#define configMAX_SYSCALL_INTERRUPT_PRIORITY		( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << ( 8 - configPRIO_BITS ) )

Also, what interrupts do you have in your system and what are their priorities?

24

Yes @aggarg that seems to be the issue. For perspective, the interrupt-priority checks in the CM33 port were not present in v10.5.1. Those checks would have caught this issue.

@zexalistic For the moment I am assuming your MCU implements only 3 bits of interrupt priority. As a result, the value of 16 for configMAX_SYSCALL_INTERRUPT_PRIORITY is effectively zero (16 is 00010000b, and the top three bits are 000). The value zero doesn’t mask any interrupts, so all of your critical sections throughout your application are broken. That in turn allows the exact case you described above to explain your observations.

See here for help setting configMAX_SYSCALL_INTERRUPT_PRIORITY:

25

I checked stm32h563xx.h

#define __NVIC_PRIO_BITS 4U /* Number of Bits used for Priority Levels */

So this should be correct

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 16

26

Are there any calls to NVIC_SetPriorityGrouping() in your codebase? If so what is the value of the parameter passed to that function? When the error occurs, what is the value in
SCB->AIRCR? Maybe only 3 (or fewer) of the 4 bits are being used as preemption-priority bits.

27

16 can’t be expressed i 4 bits, but needs 5. The bottom 4 bits of 16 is 0000.

28

NVIC_PRIORITYGROUP_4 was passed to NVIC_SetPriorityGrouping()

#define NVIC_PRIORITYGROUP_4 0x3U /*!< 4 bits for pre-emption priority,
0 bit for subpriority */

29

@zexalistic this question may lead to the real solution. Do you have an interrupt that uses the default priority of zero? If so, that is the source of your issue. Zero is the highest priority, too high to make calls to the FreeRTOS API.

30

True, but in this case it’s the upper 4 bits that matter. :slightly_smiling_face: So the max interrupt priority safe for API calls in this case is priority 1. Only priority zero would cause a problem.