#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
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
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.