STM32F475RC schedular start issue

Hi, I’m a long time user of FreeRTOS and have never had any issues brining it up on a new platform, but I’ve got a new platform here using the STM32L475RC chip and I can’t start the scheduler. When I break the code, it’s stuck in an assert in xPortStartScheduler
    #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 );
    }
    #endif
portMAXPRIGROUPBITS is 7 ulMaxPRIGROUPValue is 0xffffffff configPRIO_BITS = 4 First time I’ve ever had an issue bringing up a board and have used various STM32 processors in the past with no issues either. I’m using the GCC CM4F port. Any thoughts?

STM32F475RC schedular start issue

ucMaxPriorityValue = *pucFirstUserPriorityRegister; The value of this is 0xFF which it shouldn’t be?

STM32F475RC schedular start issue

The value of ulMaxPRIGROUPValue looks wrong. It comes from the code just above the lines you posted: ~~~ ulMaxPRIGROUPValue = portMAXPRIGROUPBITS; while( ( ucMaxPriorityValue & portTOPBITOFBYTE ) == portTOPBITOFBYTE ) { ulMaxPRIGROUPValue–; ucMaxPriorityValue <<= ( uint8_t ) 0x01; } ~~~ As it starts with the value 0x07 it must have underflowed to get to 0xffffffff, which presumably means uxMaxPriorityValue was wrong so it stayed in the while() loop too long. Can you step through this part of the code in the debugger to see if this theory is correct, and if so, how ucMaxPriorityValue came to be wrong in the first place. As this is an STM32, did you remember to call NVICPriorityGroupConfig( NVICPriorityGroup_4 ); before starting the scheduler?

STM32F475RC schedular start issue

I think our posts just crossed…

STM32F475RC schedular start issue

If you have four priority bits then ucMaxPriorityValue should be 0xf0 – as on the Cortex-M the most significant bits hold the priority. https://www.freertos.org/RTOS-Cortex-M3-M4.html

STM32F475RC schedular start issue

Thanks for the response Richard, I’ve called HALNVICSetPriorityGrouping(NVICPRIORITYGROUP4); before the start of the scheduler and it’s made no difference, the ucMaxPriorityValue still reads 0xff and the underflow still occurs. I cannot see any difference between my configuration and the one that the l475 demo in the amazon freertos repo.

STM32F475RC schedular start issue

This is just reading from a hardware register. Extremely unlikely, but could it just be bad hardware? Alternatively, could it be the start up code is setting the CPU into an unprivileged state so you are not able to read/write from the interrupt priority registers? (which is what this code is doing, to automatically determine the number of priority bits present in the hardware implementation).

STM32F475RC schedular start issue

I’ll have to check this in the morning, I’m using Crossworks V4, a quick cursory glance I can’t see anything about setting the privileged/unprivileged mode, so I assume it’s starting up in its default configuration, whatever that happens to be.

STM32F475RC schedular start issue

Boy do I feel stupid….. Didn’t notice, but instead of Crossworks connecting to the actual target it had connector to the “simulator device” they provide. Amazing what you think about overnight, I’d spotted this before but could have swore blind yesterday that I’d selected the jlink as the target. Oh well, the RTOS is up and running.

STM32F475RC schedular start issue

Thanks for taking the time to report back.