CubeMX and SysTick

[adrian]

Posted on February 02, 2018 at 16:09

Why does CubeMX generate the following lines in SystemClock_Config if the HAL timer is set to anything other than SysTick?

HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

/**Configure the Systick

*/HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

/* SysTick_IRQn interrupt configuration */

HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

I'm having to comment these lines out as they are interfering with my code and they shouldn't be there in my opinion.

[T J]

Posted on February 03, 2018 at 03:07

curious,

Do you configure all your clocks manually ?  or through the cube ?

which line is giving you grief ?

for the cube users, we use this function as is.

then make everything else work around it.

I use:

void HAL_SYSTICK_Callback(void){

    mS++;                  // foreground view of mS         mSint = true;       // foreground flag }

[adrian]

Posted on February 03, 2018 at 10:03

Clocks are configured using cube.  The HAL tick is configured to be one of the timers and not systick.

I have manually added FreeRTOS 10 to my project and that's working perfectly, I have told cube not to generate handlers for SVC, PendSV and SysTick so that the FreeRTOS handlers are used.

Cube should not be touching SysTick at all, it's baffling why it's putting this code in 

SystemClock_Config.

It's the 

HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000); line that causes the problem as this sets up and enables the systick interrupt, which obviously happens to be the FreeRTOS SysTick interrupt and the scheduler hasn't started at this point so I just end up in a fault.

This has to be a bug in CubeMX, it should not be generating those lines of code if you are not using SysTick.

[henry.dick]

Posted on February 04, 2018 at 18:23

'

Why does CubeMX generate the following lines in SystemClock_Config if the HAL timer is set to anything other than SysTick?'

agreed that it doesn't make sense.

with that said, the code looks quite harmless. Maybe the rest of your code assumed something that's contradictory to Systick being activated?

[adrian]

Posted on February 04, 2018 at 18:46

The issue is that it configures and starts the SysTick interrupt, this is a problem because the SysTick in my case is set to an RTOS tick handler and at this point the scheduler isn't started, so it crashes.

[henry.dick]

Posted on February 04, 2018 at 20:01

'

The issue is

 ...'

the real issue is that each framework assumes that they are the master of the universe so they lay down certain rules that your code must follow. Unfortunately when you put the two in a cage, those rules don't play nice.

the solution is obviously clear (and you already know): 1) comment out the SysTick portion of the code; or 2) use a different time base; or 3) pick one master and roll your own.

[adrian]

Posted on February 05, 2018 at 09:16

However, it still shouldn't be touching SysTick, there is nothing set up in CubeMX which is telling it to use SysTick!

[henry.dick]

Posted on February 05, 2018 at 12:17

Yeah. no one said it should. but it does so you have to deal with it.