STM32CubeMX incorrect code generation for EXTI on STM32H7 with LL driver

[Remi.G]

I am using STM32CubeMX 6.2.1 with STM32H7 package 1.9.0.

Some IOs are configured as EXTI, and I have configured CubeMX to use LL for GPIO.

The generated code per IO is:

  LL_SYSCFG_SetEXTISource(LL_SYSCFG_EXTI_PORTG, LL_SYSCFG_EXTI_LINE12);

  /**/

  EXTI_InitStruct.Line_0_31 = LL_EXTI_LINE_12;

  EXTI_InitStruct.Line_32_63 = LL_EXTI_LINE_NONE;

  EXTI_InitStruct.Line_64_95 = LL_EXTI_LINE_NONE;

  EXTI_InitStruct.LineCommand = ENABLE;

  EXTI_InitStruct.Mode = LL_EXTI_MODE_IT;

  EXTI_InitStruct.Trigger = LL_EXTI_TRIGGER_RISING_FALLING;

  LL_EXTI_Init(&EXTI_InitStruct);

  /**/

  LL_GPIO_SetPinPull(...);

Note that there is no LL_GPIO_Init() call, as would be the case with non-EXTI GPIOs.

Because that call is missing, the GPIOx_MODER setting is remaining at the default, which for H7 appears to be 0b11 (analog). This appears to be a mistake in the reference manual also, which lists 0b00 as the default.

With the default (analog) setting, the external input is never sensed.

Calling LL_GPIO_SetPinMode() explicitly (in my user code) works.

But I think the "proper" fix is for CubeMX autogen to also call LL_GPIO_Init() on EXTI pins?

With the HAL GPIO driver, the configuration is correct.

[Amel NASRI]

Hi @Remi.G​ ,

Thanks for bringing this limitation to our attention.

One of our STM32CubeMX experts (@Khouloud ZEMMELI​ , @Khouloud OTHMAN​ , @Houda GHABRI​ ) will take care to check and ensure that reported issue will be fixed.

-Amel

[Khouloud ZEMMELI]

Hello @Remi.G​ ,

Thanks for your post,

Could you please share your ioc file to check more your case?

Thanks, Khouloud

[Remi.G]

I can't share my full project ioc, but here's a simple case that reproduces the issue.

[Remi.G]

And the generated main.c. Note that in MX_GPIO_Init(), there is no LL_GPIO_Init() call for this pin, so it is not set to input mode.

[Khouloud ZEMMELI]

Hello @Remi.G​ 

Thanks for the share,

Actually, for EXTI case , and contrary to other IP, it only needs LL_GPIO_SetPinMode() and LL_GPIO_SetPinPull() from LL_GPIO_Init() function to correctly work, that's why, it's not expected to call LL_GPIO_Init() in MX_GPIO_Init().

And you're right, with the absence of the mode, the pin will be considered as analog as it is the default mode for the GPIO H7, so the expected code is missing this line :

LL_GPIO_SetPinMode(GPIOx, LL_GPIO_PIN_x, LL_GPIO_MODE_INPUT);

Many thanks @Remi.G​  for brining this issue to our attention and for your contribution, it will be fixed :)

Khouloud

[Khouloud ZEMMELI]

Hello @Remi.G​ ,

I'm back again to inform you that issue has been fixed in the Latest CubeMX version (6.3.0) available on site :)

Khouloud

[Piranha]

And all of this mess would disappear instantly, if ST's developers would make an actually useful code and adapt pin configuration arrays. That reduces the code and flash size significantly and completely decouples the MCU/board specific pin configuration from an application code. Some examples:

http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/SIMPLELINK_MSP432_SDK/1.20.00.45/exports/docs/tidrivers/doxygen/html/_g_p_i_o_m_s_p432_8h.html

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L432xC/TARGET_NUCLEO_L432KC/PeripheralPins.c

[BTrem.1]

I'm currently starting to learn mbed, having struggled with CubeMX & LL_ and HAL_ for 18+mo. I have a novel motor control scheme working but it was a painful experience. I will definitely look at your pin configuration arrays. --Thanks