STM32F475RC schedular start issue

Kernel
1

fizzyaid wrote on Monday, October 29, 2018:

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

portMAX_PRIGROUP_BITS 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?

2

fizzyaid wrote on Monday, October 29, 2018:

ucMaxPriorityValue = *pucFirstUserPriorityRegister;

The value of this is 0xFF which it shouldn’t be?

3

rtel wrote on Monday, October 29, 2018:

The value of ulMaxPRIGROUPValue looks wrong. It comes from the code just above the lines you posted:

ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS;
while( ( ucMaxPriorityValue & portTOP_BIT_OF_BYTE ) == portTOP_BIT_OF_BYTE )
{
    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 NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ); before starting the scheduler?

4

rtel wrote on Monday, October 29, 2018:

I think our posts just crossed…

5

rtel wrote on Monday, October 29, 2018:

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

6

fizzyaid wrote on Monday, October 29, 2018:

Thanks for the response Richard,

I’ve called HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4); 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.

7

rtel wrote on Monday, October 29, 2018:

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

8

fizzyaid wrote on Monday, October 29, 2018:

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.

9

fizzyaid wrote on Tuesday, October 30, 2018:

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.

10

rtel wrote on Tuesday, October 30, 2018:

Thanks for taking the time to report back.