Assert fired when starting FreeRTOS scheduler

[Noeël Moeskops]

Hi,

When starting FreeRTOS port for STM32f103c8 an assert is fired in BaseType_t xPortStartScheduler( void )
(Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c:310 if generated with STM32CubeMX).

code that breaks:

defined somewhere else:

#define portTOP_BIT_OF_BYTE			( ( uint8_t ) 0x80 )
#define portMAX_PRIGROUP_BITS			( ( uint8_t ) 7 )

// begin value
ucMaxPriorityValue = 255 '\377' // on qemu_stm32
ucMaxPriorityValue = 240 '\360' // on real bluepill board

port.c:289:

ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS;
while( ( ucMaxPriorityValue & portTOP_BIT_OF_BYTE ) == portTOP_BIT_OF_BYTE )
{
	ulMaxPRIGROUPValue--;
	ucMaxPriorityValue <<= ( uint8_t ) 0x01;
}

#ifdef configPRIO_BITS
{
	/* Check the FreeRTOS configuration that defines the number of
	priority bits matches the number of priority bits actually queried
	from the hardware. */
	configASSERT( ( portMAX_PRIGROUP_BITS - ulMaxPRIGROUPValue ) == configPRIO_BITS );
// ulMaxPRIGROUPValue = 4294967295 on qemu_stm32
// ulMaxPRIGROUPValue = 3 on real bluepill board
}
#endif

Seems like a overflow of some kind, not sure why it is happening yet. Commenting out the configASSERT() makes the code run without any (noticeable) issues.

[Denis Feklushkin]

QEMU upstream also affected by this issue.

Seems like pucFirstUserPriorityRegister what filled in at slightly upper in port.c works by wrong way on QEMU.
"Read the value back to see how many bits stuck" returns 8 bits instead of 4.

[Andre Beckus]

Sorry for the long delay. Thanks for the comment @denizzzka, and I hope you were able to resolve the issue @NoeelMoeskops.