HAL_Delay() stopped working after touchGFX initial?

[Junde]

Hi there,

I am trying a touchGFX demo on my homemade board with STM32H743IIT6.

Everything is OK except the HAL_Delay() is not working after the MX_TouchGFX_Init().

The following code works well:

 ... 
 MX_GPIO_Init();
 MX_FMC_Init();
 MX_CRC_Init();
 MX_DMA2D_Init();
 MX_LTDC_Init();
 HAL_Delay(1);
 MX_TouchGFX_Init();
 MX_TouchGFX_PreOSInit();
 osKernelInitialize();
 ...

However, the change below will stop the program at HAL_Delay(1):

 ... 
 MX_GPIO_Init();
 MX_FMC_Init();
 MX_CRC_Init();
 MX_DMA2D_Init();
 MX_LTDC_Init();
 MX_TouchGFX_Init();
 HAL_Delay(1);
 MX_TouchGFX_PreOSInit();
 osKernelInitialize();
 ...

 I saw some talking(see details ) about this issue, but it does not seem to have an official solution.

How is this issue going now?

(I need the HAL_Delay() to initial my touch sensor after peripherals initialization)

[Junde]

my working environment is as follows:

stm32cubeMx: 6.11.0

TouchGFX: 4.23.2

stm32cube_fw_h7_v1.11.2

 

[Bob S]

TouchGFX uses FreeRTOS.  I suspect that MX_TouchGFX_Init() makes calls to FreeRTOS to initialize tasks/mutexes/queues/etc.  The FreeRTOS code will DISASBLE ALL INTERRUPTS when any of those functions are called before osKernelStart().  It does this by setting its uxCriticalNesting variable to 0xaaaaaaaa.

One answer is to put your code that needs delays into the default task.  This can get messy when using auto-generated code because sometimes you need to insert your code outside the /* USER CODE */ comments (i.e. before any auto-generated code in StartDefaultTask()).  The only other solution is to manually re-enable interrupts after the TouchGFX calls.  But if any of your init code also makes FreeRTOS calls, you need to re-enable interrupts again after those.  And that can get even messier, specially 2 years from now when someone updates the code and doesn't know to look for that.

[Junde]

Thanks to @Bob S for your clear explanation. I get it now.