Timebase no longer works after the TouchGFX Engine Initialization

[ALomb.1]

Form TouchGFX Designer 4.18.1 I created a simple application.

I imported the project into the STM32CubeIDE (1.9) and added support for FreeRTOS.

I have selected TIM7 as the timebase source.

After calling TouchGFXGeneratedHAL::initialize() in file TouchGFXHAL.cpp the TIM7 interrupt is no longer called!

I also tried with other timers: same result.

What could be the problem ?

I noticed the problem because I had put a Hal_Delay after switching on the Display which never returned.

My hardware is NUCLEO-G071RE and X-NUCLEO-GFX01M1

[CPras.1]

Did you find the solution? I have same problem too

Thanks

[CPras.1]

Did you find the solution? I have same problem too

Thanks

[ALomb.1]

No, I haven't found a solution yet, apart from not using the HAL_Delay.

[zoronelf]

same issue there.

Timer interrupt stops working after

HAL::initialize();

in file 

TouchGFXGeneratedHAL.cpp

call, and resume after 

osKernelStart();

[Zaher]

Check this out:
https://community.st.com/t5/stm32-mcus-touch-gfx-and-gui/touchgfx-initialization-should-not-use-freertos-api-before/td-p/582375

[HRidd.2]

You aren't crazy. This is 100% a bug in ST's code. They call a FreeRTOS function intended to be called after the kernel is started before the kernel is started in their pre-compiled TouchGFX library. This has the unintended side-effect of disabling interrupts until the kernel is started essentially. @Zaher 's linked post explains in more detail but I'm going to  open up a support ticket with ST because it's crazy this bug is still around. Just wasted a good half day tracking it down myself only to come to the same conclusion a couple other forum posts came to. 

[HRidd.2]

Update for anyone who might still be struggling with this! Egg on my face, it was my own fault, not a bug in ST's code (although there are some questionable defaults that led to this behavior in STM32CubeMX).

The issue:
- OsWrappers.cpp creates a semaphore + queue for purposes of framebuffer swapping BEFORE the FreeRTOS scheduler is called

- This is "allowed" behavior in FreeRTOS, however ANY interrupts with a lower (higher integer number) priority than configMAX_SYSCALL_INTERRUPT_PRIORITY (in FreeRTOSConfig.h) will be disabled until the kernel starts
- The intention of this in the API is to block any ISRs from firing that might call scheduler related API functions before the kernel starts, which is not allowed

- By default, my TIM6 SysTick source had an interrupt priority of 15, lower priority than configMAX_SYSCALL_INTERRUPT_PRIORITY of 5

- This ISR doesn't call any FreeRTOS API functions, so it can safely be increased in priority to < 5, and it will no longer be disabled by these calls
- Things now function as expected

Hope this helps someone!

[BMB]

This is clearly a bug. Still present in CubeMX v6.11.1 and TouchGFX 4.23.1 (with X-CUBE-FREERTOS v1.2.0 and STM32Cube_FW_U5_V1.5.0).

The workaround works there but ...:

The whole thing may break on any update of any of these components or maybe even with some specific CubeMX components parameters. I walked thru the code and there might be other places where things may break (the critical sections, for example).

I need delays in the display initialization code and I am not sure I can move it to a RTOS task because I am not sure how reliably I can "hold off" TouchGFX from trying to draw once the kernel starts.