HAL_SYSTICK_IRQHandler() call is missing in CubeMX v5 generated Systick_Handler.

[Innomatic]

When STM32CubeMX v.5 generates project, it does not insert HAL_SYSTICK_IRQHander() inside SysTick_Handler(). As a result, your HAL_SYSTICK_Callback() no longer works. Previous versions of CubeMX used to generate following code for SysTick_Handler()

/**
* @brief This function handles System tick timer.
*/
void SysTick_Handler(void)
{
 /* USER CODE BEGIN SysTick_IRQn 0 */
 
 /* USER CODE END SysTick_IRQn 0 */
 HAL_IncTick();
 HAL_SYSTICK_IRQHandler();
 /* USER CODE BEGIN SysTick_IRQn 1 */
 
 /* USER CODE END SysTick_IRQn 1 */
}

In version 5. it becomes

/**
* @brief This function handles System tick timer.
*/
void SysTick_Handler(void)
{
 /* USER CODE BEGIN SysTick_IRQn 0 */
 
 /* USER CODE END SysTick_IRQn 0 */
 HAL_IncTick();
 /* USER CODE BEGIN SysTick_IRQn 1 */
 
 /* USER CODE END SysTick_IRQn 1 */
}

[kurta999]

For me it evern worse, entrie systick handler was removed by 5.0 after upgrading from 4.27.0 and re-generating an existing project.

[Amel NASRI]

Hello,

Please note that this issue is shared with our STM32CubeMX experts for farther check.

Thanks for highlighting this, and sorry for any inconvenience it may create for you.

-Amel

[Nawres GHARBI]

Hi

a new implementation has been done on the 5.0 for the systick

the HAL_SYSTICK_IRQHandler is used for debug purpose and should not be called if you refer to Cube coding rules.

If needed you are still able to add it in the dedicated user sections

[GQuan]

where is Cube coding rules？

[Tesla DeLorean]

I'd guess it is this

https://www.st.com/content/ccc/resource/technical/document/user_manual/10/c5/1a/43/3a/70/43/7d/DM00104712.pdf/files/DM00104712.pdf/jcr:content/translations/en.DM00104712.pdf

https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/d6/4c/20/0d/a1/c1/4c/99/DM00210526/files/DM00210526.pdf/jcr:content/translations/en.DM00210526.pdf

[Innomatic]

> should not be called if you refer to Cube coding rules.

That would be o.k. if all the previous versions of CubeMX have followed THAT RULE. What other Cube coding rules are there, which haven't been observed so far but suddenly respected in the version 5? Are there any rules like consistency or compatibility across the versions?

[GS1]

Hi, I have an even worse problem:

I updated my FreeRTOS project and now the system is halted in Hard Fault interrupt immediately after startup. I also have found that the complete handler for SysTick is missing. .. now trying to get my project to life again ...

Second issue: MXCube creates two file entries of file "system_stm32h7xx.c" in my Keil project (under Driver/CMSIS) and I have to delete one from the tree to get the project linked correctly.

P.S: The project was working without issues before converting to version 5.0 of CubeMX.

[Nawres GHARBI]

Hi @GS@S​ 

Could you attach your old project or ioc before migration please

[GS1]

Hi Nawres, sorry, but I am not allowed to add the project due to company restrictions.

But I assume it should easily be possible to reproduce the issue when creating a simple project with the old version for an STM32H743 (Activate FreeRTOS in standard configuration), generate code and then convert the project to the new release.

[JGawe]

Hi, I have a similar problem. I used HAL_SYSTICK_IRQHandler () to increment my own timer software to count the duration of the event on the GPIO microcontroller.

Now, instead of using HAL_SYSTICK_IRQHandler(), do I set up a hardware Timer and use it to count the duration? Or can I getting the value from the system variable 'uwTick' which is incremented in HAL_IncTick () - is checking the value of 'uwTick' is ugly? and not suitable for the final release solution ??

[GS1]

Hello,

actually you can still call HAL_SYSTICK_IRQHandler(), but you have to place the call in the "USER" area by yourself.

[Marcelo Barros]

I found some more missing points:

1) In *msp.c we do not have anymore the priority setting for SYSTICK. However, Cube allows you to modify the SYSTICK priority. So where is it located ?

2) During clock initialization, we do not have anymore any call to SYSTICK functions like HAL_SYSTICK_Config() or HAL_SYSTICK_CLKSourceConfig().

Reading the documentation, it is stated that "SysTick_Handler not generated in the code when FreeRTOSTM is enabled" but my project does not have FreeRTOS and all Systick related items are missing.

In my opinion, SYSTICK is a valuable resource and should be made available for developers as before. We use it for many tick based applications.

[Lionel1]

Hi,

Same for me. When I passed my code with this new version of CubeMX, nothing work.

I spent several hours to find that the problem is the missing "HAL_SYSTICK_IRQHandler();" line >:(

Hopefully I found this post of Innomatic :)

[Noppe.Jack]

There is a bigger issue at play here also. Code generation changes should be documented in the release notes. Irrespective of philosophical arguments about right and wrong, ST has the right to make decisions about what behaviours they want to change. That said, if they make these changes without warning the developer community, it results in distrust of the utility. We can all adjust to changes if we know about them, but when we have to discover these through troubleshooting, then the frustration levels become too high.

Please can we get a commitment from ST to document changes in code generation rules?