CubeMX GPIO not initialized in STM32H747-DISCO?

[victagayun]

Newbie here and quite fortunate and unfortunate to use STM32H747-DISCO.

For a newbie like me, it is quite overwhelming.

I mostly rely on CubeMX to generate code and combine with firmware examples.

For STM32H747-DISCO, the generated code is emptly.

In CM4 src:

{
 
  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOI_CLK_ENABLE();
  __HAL_RCC_GPIOB_CLK_ENABLE();
  __HAL_RCC_GPIOG_CLK_ENABLE();
  __HAL_RCC_GPIOC_CLK_ENABLE();
  __HAL_RCC_GPIOE_CLK_ENABLE();
  __HAL_RCC_GPIOH_CLK_ENABLE();
  __HAL_RCC_GPIOD_CLK_ENABLE();
  __HAL_RCC_GPIOA_CLK_ENABLE();
  __HAL_RCC_GPIOF_CLK_ENABLE();
  __HAL_RCC_GPIOK_CLK_ENABLE();
  __HAL_RCC_GPIOJ_CLK_ENABLE();
 
}

and in CM7 src:

static void MX_GPIO_Init(void)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
 
  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOC_CLK_ENABLE();
  __HAL_RCC_GPIOA_CLK_ENABLE();
  __HAL_RCC_GPIOH_CLK_ENABLE();
 
  /*Configure GPIO pin : CEC_CK_MCO1_Pin */
  GPIO_InitStruct.Pin = CEC_CK_MCO1_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  GPIO_InitStruct.Alternate = GPIO_AF0_MCO;
  HAL_GPIO_Init(CEC_CK_MCO1_GPIO_Port, &GPIO_InitStruct);
 
}

I also find that most Init are in CM4 src, why is that so?

Is this the new feature of CUbeMX for H747 or any dual core MCU?

[TDK]

GPIO initialization for various peripherals is generally within the HAL_*_MspInit functions which are placed in "stm32h7xx_hal_mspinit.c". The code you've linked just enables the clocks (and MCO).

> I also find that most Init are in CM4 src, why is that so?

As for why they're in CM4 instead of CM7, just depends which core you've assigned them to in CubeMX.

> Is this the new feature of CubeMX for H747 or any dual core MCU?

Not sure what you mean here. Initializing GPIO pins isn't new. Dual core programming on STM32 is somewhat new, since the chips are somewhat recent.

Dual core programming in general can get quite complicated. If you're just starting out, I would stick with a single core until you're more comfortable.

[victagayun]

> GPIO initialization for various peripherals is generally within the HAL_*_MspInit functions which are placed in "stm32h7xx_hal_mspinit.c". The code you've linked just enables the clocks (and MCO).

Generally the GPIO init is in main.c from my previous projects as shown below.

 

The "stm32h7xx_hal_msp.c" does not contain GPIO init.

Also you may notice that stm32h7xx_hal_msp.c and stm32h7xx_it.c is under M4 folder as shown below. Must be typo during code generation.

 

 BTW, this is the code/project generated where the pins are initialized as default.

[TDK]

Maybe I misunderstood the question. MX_GPIO_Init is indeed in main.c.

Each core only initializes the peripherals/pins it uses. I would expect your CM7 code only uses pins within the 3 GPIO ports that are started in MX_GPIO_Init.

> Also you may notice that stm32h7xx_hal_msp.c and stm32h7xx_it.c is under M4 folder as shown below. Must be typo during code generation.

Why would that be a typo? Both files are present in both of the cores, although their contents will not be identical.

Oh yes I meant "stm32h7xx_hal_msp.c" and not "stm32h7xx_hal_mspinit.c".

[victagayun]

Well, I am expecting like stm32h4xx_hal_msp.c and stm32h4xx_it.c to be in the CM4 folder.

BTW, CubeIDe ver is 1.4.2 and H7 version is 1.8.0.

So is this a confirmed bug?

[TDK]

No. The chip is an STM32H7, that's what it refers to. It's not referring to the core.

[victagayun]

The bug is still there and CUbeMX does not generate the GPIO init.....

So there is still no "best answer"

[victagayun · Accepted solution]

Sorry, I did not explore fully the GPIO in CubeMX for dual core like the H747.

You may need to assign which core will need to init it.