search

STMicroelectronics / STM32CubeG0

STM32Cube MCU Full Package for the STM32G0 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
164 stars 75 forks source link

STM32G0 HAL_GPIO_EXTI_Callback() incompatibility #7

Closed suikan4github closed 3 years ago

suikan4github commented 4 years ago

Describe the set-up

Describe the bug The following call back should be called when EXTI is accepted, according to the HAL reference UM2319 - Rev 1, section 3.11 : 

 void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
}

This is common manner among the STM32 series.

But only STM32G0 uses HAL_GPIO_EXTI_Rising_Callback() and HAL_GPIO_EXTI_Falling_Callback().

This is a bad idea to make a Hardware "Abstraction" Layer. The API should be aligned among the different hardware, as far as possible. ANd this is a possible case.

How To Reproduce

  1. The demo program turn on the LED on the HAL_GPIO_EXTI_Callback.
  2. Clone the stm32-defects repository.
  3. Import d003-nucleo-g070-gpio-exti into CubeIDE
  4. Build and run the project on the Nucleo-G070.
  5. Import d003-nucleo-g431rb-control into CubeIDE
  6. BUild and run the project on the Nucleo-G431RB.

Please push the blue button (B1) of the Nucleo. On the Nucleo G070, the green LED is off, while the Nucleo G431RB the green LED in turned on. Both projects try to catch the EXTI by HAL_GPIO_EXTI_Callback() and turn on LED. The G431RB is expected behavior.

Additional context This is duplicated with the bug-report on the community.

Screenshots

ALABSTM commented 4 years ago

Hi Suikan,

Thank you for this report. It will be forwarded to our development teams for analysis. We will be back to you as soon as we get feedback.

Thank you for your patience and thank you again for your contribution.

With regards,

ALABSTM commented 4 years ago

ST Internal Reference: 80891

ALABSTM commented 4 years ago

Hi Suikan,

The issue you reported is an already known one. An internal bug tracker has been already opened to request to update the EXTI HAL driver so it becomes aligned with ones of other families.

The fix will be made available in a future release. We cannot share a date for the moment, unfortunately. We will try to keep you updated. Thank you again.

With regards,

ALABSTM commented 3 years ago

Hi @suikan4github,

I hope you are fine. The issue you reported has been fixed in the frame of version v1.4.0 of the STM32CubeG0 published a few minutes ago on GitHub.

Thank you again for having reported.

With regards,

insolace commented 11 months ago

I don't show that this has been fixed in either the current 1.61 version of STM32CubeG0, or in the commit made on Dec 2nd. There is no HAL_GPIO_EXTI_Callback function called in stm32g0xx_hal_gpio.c. Very frustrating to spend hours debugging this only to find that the G0 HAL does not match the standard methods used in tutorials, example code, and other STM nucleo boards.

https://github.com/STMicroelectronics/STM32CubeG0/blob/master/Drivers/STM32G0xx_HAL_Driver/Src/stm32g0xx_hal_gpio.c

MattPamenter commented 3 weeks ago

HAL_GPIO_EXTI_Callback() is still not functional with the STM32G0. Using either HAL_GPIO_EXTI_Rising_Callback() or HAL_GPIO_EXTI_Falling_Callback() works. It's a shame it took 2 hours to find this. Very frustrating.