2022-03-22 07:12 AM
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
2022-10-12 04:30 PM
Did you find the solution? I have same problem too
Thanks
2022-10-12 04:42 PM
Did you find the solution? I have same problem too
Thanks
2022-10-12 11:12 PM
No, I haven't found a solution yet, apart from not using the HAL_Delay.
2023-09-06 06:14 AM
same issue there.
Timer interrupt stops working after
HAL::initialize();
in file
TouchGFXGeneratedHAL.cpp
call, and resume after
osKernelStart();
2023-10-12 07:23 AM
2024-03-13 08:23 AM
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.
2024-04-26 08:35 AM
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!
2024-05-31 03:09 PM
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.