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?

[AKole.5]

replace stm32f7xx_hal_timebase_tim.c

taken from the old version

HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)

{

 RCC_ClkInitTypeDef  clkconfig;

 uint32_t       uwTimclock = 0;

 uint32_t       uwPrescalerValue = 0;

 uint32_t       pFLatency;

 /*Configure the TIM6 IRQ priority */

 HAL_NVIC_SetPriority(TIM6_DAC_IRQn, TickPriority ,0);

 /* Enable the TIM6 global Interrupt */

 HAL_NVIC_EnableIRQ(TIM6_DAC_IRQn);

 /* Enable TIM6 clock */

 __HAL_RCC_TIM6_CLK_ENABLE();

 /* Get clock configuration */

 HAL_RCC_GetClockConfig(&clkconfig, &pFLatency);

 /* Compute TIM6 clock */

 uwTimclock = 2*HAL_RCC_GetPCLK1Freq();

 /* Compute the prescaler value to have TIM6 counter clock equal to 1MHz */

 uwPrescalerValue = (uint32_t) ((uwTimclock / 1000000U) - 1U);

 /* Initialize TIM6 */

 htim6.Instance = TIM6;

 /* Initialize TIMx peripheral as follow:

 + Period = [(TIM6CLK/1000) - 1]. to have a (1/1000) s time base.

 + Prescaler = (uwTimclock/1000000 - 1) to have a 1MHz counter clock.

 + ClockDivision = 0

 + Counter direction = Up

 */

 htim6.Init.Period = (1000000U / 1000U) - 1U;

 htim6.Init.Prescaler = uwPrescalerValue;

 htim6.Init.ClockDivision = 0;

 htim6.Init.CounterMode = TIM_COUNTERMODE_UP;

 if(HAL_TIM_Base_Init(&htim6) == HAL_OK)

 {

  /* Start the TIM time Base generation in interrupt mode */

  return HAL_TIM_Base_Start_IT(&htim6);

 }

 /* Return function status */

 return HAL_ERROR;

}

and you will be happy

checked cubeide 1.10.1 cubeMX 6.6.1

[rgree.1]

I also faced this issue with latest TouchGFX upgrade to a functioning project.

my config is

STM32CubeIDE 1.12.1,

CubeMX 6.8.1,

TouchGFX 4.21.4,

FreeRTOS,

STM32L4R9 running on custom hardware,

480x480 TFT using LTDC, DSI, Video Burst Mode

I was able to resolve the issue not by switching to the older CubeMX version of stm32l4xx_hal_timebase_tim.c routine HAL_InitTick() (which incidentally does also solve the problem). Instead simply making sure not to use HAL_Delay() between MX_TouchGFX_Init() and osKernelStart(). Once the kernel starts the interrupts and HAL_IncTick() resume working.

[derek2399]

I have a horrible feeling I have done a similar thing. I had a program working fine and after adding to it, it would not compile (even when I removed the changes), so I ended up copying files into a new program (with the later Cube V6.81 / TouchGFX V4.21.4. It now compiles but gets no further than MX_TouchGFX_Init();
It appears to finish at

in the TouchGFXGPIO.cpp program.

Most, if not all of this has been generated by Cube/Touch programs.

Incidentally, I don't know if it is related, but I also get this coming up consistently.

Is this likely to be related to updating Cube/Touch programs?

I foolishly thought working with the latest versions would be a good thing.

[rgree.1]

Derek, One issue I ran into during my upgrade was the project settings for the Linker had a Libraries search path that was picking up the wrong libtouchgfx-float-abi-hard.a file from the prior version of TouchGFX, make sure you are linking in the appropriate library.

[derek2399]

Thanks for taking the time to reply so quickly. It's much appreciated. I am using the Keil compiler and as far as I can tell, it appears to be use the same touchgfx_core.lib, which I think has the libtouchgfx-float-abi-hard.a within it ?? All the other project attempt's touchgfx_core.lib, have the same date 20-04-2023. I haven't seen any later versions, generated.

 

Please enlighten me if I am missing something or you feel something requires updating. I assumed it would just work and haven't much hair left to pull out.

[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!