uwTick stops updating, stuck in HAL::initialize after project update to new tools.

[wired]

I have a working project that was running in STM32CubeIDE v1.7.0, with STM32CubeMX v6.3.0 and TouchGFX v4.18. After updating to STM32CubeIDE v1.10.1, STM32CubeMX v6.6.1, and TouchGFX v4.20, the program is getting stuck in HAL_Delay when HAL::initialize() is initializing the touchscreen.

I watch uwTick variable up until the HAL::initialize() call, and it is updating. It is no longer updating in the Hal_GetTick function during touchscreen initialization.

I have not changed any settings in the project or in CubeMX. I am not doing any overrides of the system tick initialization. Any ideas why this is happening?

[LBend.1]

Wired or anyone else, 

I've been testing a number of the options in this forum to try solve my identical issue. I too unfortunately updated past CubeMX 6.5.0 to 6.8.1. I tried to reinstall the CubeMX 6.5.0 version to align with your suggestions but am now getting this error that the project was generated with 6.8.1: 

Is there a way to downgrade the required CubeMX .ioc file so it works with 6.5.0 to testing building with that?

Thanks!

[HRidd.2]

For all those still struggling with this, please see this post that goes into detail about what's happening:
https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/touchgfx-initialization-should-not-use-freertos-api-before/td-p/582375

This is 100% a bug in ST's code, and I've filed a ticket to try to get a timeline on when it will be fixed. Ran into this same problem and tracked it down + came to the same conclusion the above post does. Working now on a possible work-around that's a little easier than "just avoid using HAL_Delay() after TouchGFX init but BEFORE the kernel is started" and will update this post if it pans out.

[HRidd.2]

Update for anyone who cares! 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!