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?

[Pavel A.]

What is the value of TickPriority on entry to HAL_InitTick?

Perhaps the old issue with the HAL tick priority initializer raises its ugly head again.

> why the change?

A Chinese proverb says that change is evil, but inevitable. Corollary: evil is inevitable.

[wired]

Pavel,

Sorry for the late reply, I am out of office on Fridays and Mondays.

There are two calls to HAL_InitTick(). The first is from HAL_Init(), and the second is from SystemClock_Config().

In the version that fails, TickPriority is 15 for both calls. Also, uwTickPrio is 16 upon entry to the first call, and 15 upon exit. It remains at 15 after the 2nd call.

In the version that works, TickPriority is 15 for the first call, and 16 for the 2nd call. uwTickPrio remains at 16 throughout the entire program execution.

[wired · Accepted solution]

ST technical support finally got back to me with the following response:

You are talking about TouchGFX 4.18 now we are on 4.20. TouchGFX 4.20 is the latest, this is for STM32CubeMX 6.5.0.

As recommendation as things are changing constantly between CubeMX and TouchGFX I do not recommend to migrate the IOC file to newer version just stick to old and use the “Continue�? not “migrate�?. As example for other bord, the problem when migrating was just at the RTOS timer no calling HAL ISR timer handler.

If you do not migrate sill can open IOC file, do modifications, generate code with CubeMX and all should be OK. As the TouchGFX project was created for that version.

The example I sent them uses TouchGFX 4.18, but the same problem exists with TouchGFX 4.20. The only reason I sent them a 4.18 example project is because there are other problems encountered when going to 4.20.

About all I can take away from this is that if you are using FreeRTOS with TouchGFX and CubeIDE and CubeMX, you had better not update CubeMX beyond version 6.5. It would be nice to have known that before I spent so much time trying to get everything to work.

[Pavel A.]

Let's look at the source, F4, version 1.27.1 (but same in several earlier versions)

https://github.com/STMicroelectronics/STM32CubeF4/blob/52757b5e33259a088509a777a9e3a5b971194c7d/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c#L262

If the TickPriority argument is > 15 (16 for example) , HAL_InitTick returns error. This will likely end in Error_Handler().

But you say that in the version that fails, TickPriority is 15 for both calls....

[wired]

Pavel, the weak function is never called.

[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.