No SysTick interrupt generated after __libc_init_array call on C++ environment

[VHEMaster]

Initially, there was CubeIDE project for STM32H747XI without TouchGFX and without C++ accordingly. Everything was ok, startup, linker or HAL init sequence were not touched. Everything worked (DSI, LTDC, I2C, etc.)

Time later, I added TouchGFX into project with CubeIDE integrated method (just enable it in software components) and regenerated the code. So C++ appeared, and after that no SysTick is generated.

Accordingly, it doesn't call HAL_IncTick that is very important for HAL functionality. That is causing whole code unworkable because at least DSI init sequence uses HAL_Delay.

So initial failure was at HAL_SYSCFG_EnableVREFBUF func (called by HAL_Init): HAL_GetTick always returned zero.

For experiment, I moved __libc_init_array after HAL_Init: there was SysTick interrupts! so it returned, but after __libc_init_array call - no another SysTick interrupts!

So the issue is inside of __libc_init_array?

Why can it cause this issue and how can it be fixed?

IOC file attached.

[GaetanGodart]

Hello @VHEMaster ,

 

It seems your clock configuration has some issue that could be fixed.

You also generate code under root, it is highly recommended to uncheck "Generate under root".

There also seems to have 2 issues before generating code :

Perhaps you could have a look at the application tick source guide .

 

Regards,

[VHEMaster]

Hi @GaetanGodart ,

The clock issue you mentioned is not related to SysTick issue. The one where RTOS recommends the usage of TIM instead of SysTick, is also not related. 

Please read topic description very carefully. The one that breaks SysTick is __libc_init_array call. RTOS and TouchGFX are not even initialized at this stage.

Thanks! BR, Maks

[GaetanGodart]

Perhaps they are not linked but I think we should fix the obvious issues before fixing the unexpected issues because there is a small chance that they are linked.

After generating the code from STM32CubeMX (and from TouchGFX Designer), I can only find "__libc_init_array" in the .s (startup) files. So I am not sure what you are talking about, perhaps I am not the best person to answer this topic.

Just a couple of considerations :

1. I have seen a lot of people struggling to make TouchGFX + USB work together, maybe you could try to disable your USB peripherals
2. You could use the STM32H747 TBS (TouchGFX Board Setup) that is provided in TouchGFX Designer and modify it to fit your needs, maybe that would be easier.

 

Regards,

[VHEMaster]

I found the workaround. Doing TIM17 as tick source is not a solution.

The root cause is that __libc_init_array calls C++ constructors for static objects. 

TouchGFX depends on RTOS API and constructors call it before osKernelInitialize which caused unexpected behaviour and core locks the interrupts.

The workaround is to call __libc_init_array after osKernelInitialize and move MX_TouchGFX_Init after these two.

Seriously, was it ever tested?

Thanks! BR, Maks