STM32CubeMX 6.8.0 and STM32CubeIDE 1.12.0: bug in initialization of GTZC, missing clock enable

[SOfne.1]

I'm using STM32CubeIDE 1.12.0 with a TrustZone enabled project and observed incorrect initialization of GTZC when the option "Generate peripheral initialization as a pair of '.c/.h' files per peripheral" is active:

 

If this option is not active the function HAL_MspInit() in stm32XXXX_hal_msp.c contains some code to enable the clock of GTZC1 and/or GTZC2, depending on the further configuration e.g.:

/**
  * Initializes the Global MSP.
  */
void HAL_MspInit(void)
{
  /* USER CODE BEGIN MspInit 0 */
 
  /* USER CODE END MspInit 0 */
 
  __HAL_RCC_GTZC1_CLK_ENABLE();
 
  /* System interrupt init*/
 
  /* USER CODE BEGIN MspInit 1 */
 
  /* USER CODE END MspInit 1 */
}

If this option is active the GTZC clocks are not enabled in stm32XXXX_hal_msp.c any more. This is as expected. But the generated gtzc_s.c, which then contains the whole initialization of the GTZC, misses the code to enable the clock of GTZC1 and/or GTZC2.

Of course GTZC peripheral must be enabled (I enabled GTZC_S) in the Pinout&Configuration tab in order to trigger generation of GTZC initialization code at all.

My current workaround is to manually enable the clock(s):

/* GTZC_S init function */
void MX_GTZC_S_Init(void)
{
 
  /* USER CODE BEGIN GTZC_S_Init 0 */
  __HAL_RCC_GTZC1_CLK_ENABLE();
  /* USER CODE END GTZC_S_Init 0 */
 
  MPCBB_ConfigTypeDef MPCBB_Area_Desc = {0};
...

If you also use GTZC2 you have to add "__HAL_RCC_GTZC2_CLK_ENABLE();", too.

As far as I can see in the release notes of the latest STM32CubeMX 6.8.1, this bug has not been fixed yet.

[Ghofrane GSOURI · Accepted solution]

Hello @SOfne.1​ 

Thank you for your contributions and for your detailed explanations,

I confirm the issue on my side, it has been reported to STM32CubeMX development team .

Internal ticket number: 151261(This is an internal tracking number and is not accessible or usable by customers).

I will keep you posted with updates.

 Thx

Ghofrane