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?

[Tesla DeLorean]

>>Any ideas why this is happening?

Priorities changed?

Software counters need to be brief, and preempt everything, especial with unfettered usage in interrupt and callback contexts.

Make sure the interrupt is enabled and firing. Make sure interrupts are enabled on the MCU. So watch for boot-loaders, or control transfers done from interrupt context, or RTOS's

[wired]

Thanks for the quick reply. Like I said, I made no changes to the project or its configuration. And uwTick was ticking until the TouchGFX initialization. Do you know of any changes made to TouchGFX between 4.18 and 4.20 that could cause this? I'm going to try just the IDE and CubeMX update without the TouchGFX update and see if that works.

[wired]

OK, so I started back with the original project, which was in STM32CubeIDE v1.7.0, with STM32CubeMX v6.3.0 and TouchGFX v4.18. (NOTE: for the following information: CubeIDE 1.10.1 is associated with CubeMX6.6.1 whan I do a Help->About in the IDE, but I also have CubeMX 6.50 installed in a different folder.

1. Load the original code into Cube IDE v1.10.1
2. Build and run code (works fine).
3. Double-click on .ioc file in IDE (says it uses CubeMX 6.3.0 with ST F4 FWv1.26.2, and asks if I want to migrate to 6.6.1 and Fw 1.27.1. I cancel out of loading the IOC file.
4. Start CubeMX v6.5 externally (from a desktop shortcut).
5. Load .ioc file for the project.
6. Dialog asks if I want to migrate to CubeMX 6.5.0 and ST F4 FWv1.27.1. I choose to migrate.
7. Press GENERATE CODE button, and exit CubeMX when complete.
8. Start CubeIDE 1.10.1. Middlewares, CMSIS, and STM32F4xx_HAL_Driver folders are GONE.
9. Start CubeMX from within IDE by double-clicking on .ioc file.
10. Dialog says file is at CubeMX 6.5 and Fw 1.27.1, asks if I want to migrate to CubeMX 6.6.1. I say Continue (which continues loading ioc file without migrating).
11. I activate WWDG, then deactivate it to force a change (there is no GENERATE CODE button from IDE).
12. Generate code after saving ioc file. Folders RE-APPEAR!
13. Rebuild project, load in debugger, and it runs fine.
14. Exit IDE, and start CubeMX 6.6.1 externally (from desktop icon).
15. Asks if I want to migrate from CubeMX 6.5.0 to 6.6.1. I say Migrate.
16. I press GENERATE CODE button, and exit CubeMX when done.
17. I open IDE 1.10.1. Folders that were missing earlier are still present.
18. Build project, run in debugger, and SysTick quits updating sometime after MX_TouchGFX_Init is called, and SW hangs at first call to HAL_Delay.
19. Just to be sure problem won't go away, open .ioc file, force a change, generate code, rebuild project, and still hangs at same point in debugger.

From all of this, one has to assume there is something different between CubeMX 6.5.0 and 6.6.1 that is causing a failure.

[wired]

Latest update: The last time I see uwTick updated is when it increments by one count between the calling and returning of osSemaphoreNew() in OsWrappers::initialize().

I am not seeing it update anymore after that, and the software later gets hung in the HAL_Delay() that gets called in the touchscreen driver initialization.

[wired]

Apparently the uwTick counter stops updating somewhere within the osSemaphoreNew() call. I modified osWrapper.cpp to add some Hal_Delay calls as follows:

/*
 * Initialize frame buffer semaphore and queue/mutex for VSYNC signal.
 */
void OSWrappers::initialize()
{
 // Create a queue of length 1
	HAL_Delay(5);
 frame_buffer_sem = osSemaphoreNew(1, 1, NULL); // Binary semaphore
 assert((frame_buffer_sem != NULL) && "Creation of framebuffer semaphore failed");
HAL_Delay(5);
 // Create a queue of length 1
 vsync_queue = osMessageQueueNew(1, 4, NULL);
 assert((vsync_queue != NULL) && "Creation of vsync message queue failed");
 HAL_Delay(5);
}

The uwTick count was 283 at a breakpoint set for the first HAL_Delay(). After stepping over it, it was at 290. After stepping over the osSemaphoreNew() call, it was at 291. It was no longer incrementing when the 2nd HAL_Delay() call was made, and the program remained in that 2nd call.

[wired]

Well, I found out why the system is hanging, but I haven't chased down the differences between the project that works and the one that doesn't.

There is a variable used by FreeRTOS called uxCriticalNesting. It is initialized in its declaration to 0xaaaaaaaa. It is initialized to zero when the Scheduler is started with an osKernelStart() call. That's fine, but the problem is it is used in the call to MX_TouchGFX_Init(), which sets up a semaphore and a queue. I followed the osSemaphoreNew() code, and within this function we reach the following code (see the call stack as well):

here, interrupts are disabled and uxCriticalNesting gets increment not from 0 to 1, but from 0xaaaaaaaa to 0xaaaaaaab.

Later, when vPortExitCritical is called (see image above), uxCriticalNesting is decremented not from 1 to 0, but from 0xaaaaaaab to 0xaaaaaaaa. And.... interrupts do not get re-enabled.

I tried temporarily initializing the uxCriticalNesting variable to 0 at its declaration, and the code runs fine. Perhaps this was initialized to zero earlier in the earlier release of all the software, but this is definitely a problem in this release, because MX_TouchGFX_Init() is called before osStartKernel() is called. These two calls are made in auto-generated code, so I think something needs to change, ST.

[wired]

Well, that may have made the program work, but I also tried single-stepping through the program that uses CubeMX 6.5, and osSemaphoreNew exhibits the same behavior with the uwCriticalNesting value of 0xaaaaaaaa, yet the uwTick keeps updating. I'm really at a loss now.

[wired]

It looks like I have to move this to a tech support case. I've created two versions of a simple test case that just displays a 'SUCCESSFUL TEST' screen on the STM32F469i-DISCO if successful. The version using CubeMX 6.5.0 displays the screen, and the version using CubeMX 6.6.1 does not, because it gets hung up in MX_TouchGFX_Init due to the uwTick updates stopping once it is called. Will post an update if there is a resolution to this. If anyone is curious enough about this to see for themselves and you have a STM32F469i-DISCO board, just reply to this and I will provide the two projects.

[wired]

After submitting the case to ST, I continued my investigation. I instrumented the failing software using CubeMX 6.6.1, and discovered that the HAL quit updating after the first call to portDISABLE_INTERRUPTS() in FreeRTOS port.c. This led to me thinking that there is a priority issue or something related to the HAL timer 6 initialization. I compared HAL_InitTick() from 6.5.0 to the same function in 6.6.1, and they are quite a bit different. I replaced the HAL_InitTick() function that was being called with the one from 6.5.0 and everything works. See the attached file, where both functions are present, but the 6.6.1 version is commented out. When I run the 6.6.1 version of the project, but with this one function replaced with the 6.5.0 version, the program works. So the question for ST is... why the change?

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

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.

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