Skip to main content
adrian
adrian
Associate III
February 2, 2018
Question

CubeMX and SysTick

  • February 2, 2018
  • 7 replies
  • 4889 views
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.

    This topic has been closed for replies.

    7 replies

    T J
    T J
    Senior III
    February 3, 2018
    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
    adrianAuthor
    Associate III
    February 3, 2018
    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
    henry.dick
    Associate II
    February 4, 2018
    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
    adrianAuthor
    Associate III
    February 4, 2018
    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
    henry.dick
    Associate II
    February 4, 2018
    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.

    Terms & ConditionsAccessibility statement