Skip to main content
PKB404
Associate II
July 28, 2026
Question

[Bug report]CubeMX generates wrong USB OTG FS macro names for STM32H743VITx

  • July 28, 2026
  • 3 replies
  • 142 views

  When enabling USB_OTG_FS peripheral in Device_Only mode for STM32H743VIT6, CubeMX generates usb_otg.c with incorrect HAL macros:

Generated (wrong) Should be (H7-native)
GPIO_AF10_OTG1_FS GPIO_AF10_OTG2_FS
__HAL_RCC_USB_OTG_FS_CLK_ENABLE __HAL_RCC_USB2_OTG_FS_CLK_ENABLE
__HAL_RCC_USB_OTG_FS_CLK_DISABLE __HAL_RCC_USB2_OTG_FS_CLK_DISABLE

 

Root cause:
  On STM32H7, the FS USB peripheral is USB2_OTG_FS, not USB1_OTG_FS. The H7 HAL defines GPIO_AF10_OTG2_FS for the FS port and GPIO_AF10_OTG1_HS for the HS port. CubeMX, however, generates F4/F7-style macro names (e.g. GPIO_AF10_OTG1_FS) which are only valid for MCUs with a single USB OTG peripheral.


  Moreover, GPIO_AF10_OTG1_FS is conditionally defined in stm32h7xx_hal_gpio_ex.h only when USB2_OTG_FS is not defined. Since STM32H743 does define USB2_OTG_FS, the macro is absent at compile time.


  The legacy compatibility aliases in stm32_hal_legacy.h could resolve this, but CubeMX does not include that header in the generated code.

Note: This issue occurs regardless of whether ST's USB middleware stack is used or not. I am using a third-party USB library (CherryUSB) and only rely on CubeMX to generate correct HAL-level hardware initialization code (clock, GPIO, NVIC). The generated peripheral init macros should always be valid for the selected target MCU — the choice of USB protocol stack should not affect the correctness of the HAL-level code that CubeMX generates.

 

Workaround:
  Manually add the following defines in the USER CODE section of usb_otg.c:

/* USER CODE BEGIN 0 */
#ifndef GPIO_AF10_OTG1_FS
#define GPIO_AF10_OTG1_FS GPIO_AF10_OTG2_FS
#endif
#ifndef __HAL_RCC_USB_OTG_FS_CLK_ENABLE
#define __HAL_RCC_USB_OTG_FS_CLK_ENABLE() __HAL_RCC_USB2_OTG_FS_CLK_ENABLE()
#define __HAL_RCC_USB_OTG_FS_CLK_DISABLE() __HAL_RCC_USB2_OTG_FS_CLK_DISABLE()
#endif
/* USER CODE END 0 */

Expected fix:
  CubeMX should generate the H7-native macro names when the target MCU has dual USB OTG peripherals (e.g. STM32H743).


Environment:

  • MCU: STM32H743VIT6
  • CubeMX: V6.18.0
  • STM32H7 series MCU package version: V1.13.0
  • Third-party USB stack: CherryUSB (ST's USB middleware not used)

3 replies

Ghofrane GSOURI
ST Technical Moderator
July 28, 2026

Hello ​@PKB404 

Regarding the first point :CubeMX generates GPIO_AF10_OTG1_FS instead of GPIO_AF10_OTG2_FS for USB_OTG_FS on STM32H743,fully agree with you , I have escalated a ticket  #0064753 to dev team to correct this behavior 

Regarding __HAL_RCC_USB_OTG_FS_CLK_ENABLE and __HAL_RCC_USB_OTG_FS_CLK_DISABLE, stm32_hal_legacy.h is correctly included in the project. As a result, these macros are properly resolved through the legacy compatibility aliases.

main.h
  -> stm32h7xx_hal.h
    -> stm32h7xx_hal_conf.h
      -> stm32h7xx_hal_cortex.h
        -> stm32h7xx_hal_def.h
          -> Legacy/stm32_hal_legacy.h

Also

THX

Ghofrane

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
PKB404
PKB404Author
Associate II
July 30, 2026

Hello ​@Ghofrane GSOURI 

  Thank you for confirming the GPIO_AF10_OTG1_FS issue and opening ticket #0064753.

  Regarding the clock macros — I dug deeper and found the actual root cause. The include order inside stm32h7xx_hal_def.h is reversed:

// stm32h7xx_hal_def.h, line 29-30
#include "Legacy/stm32_hal_legacy.h" // processed first, but STM32H7 not defined yet
#include "stm32h7xx.h" // STM32H7 gets defined here — too late

  Since stm32h7xx_hal_def.h is first pulled in by stm32h7xx_hal_rcc.h (stm32h7xx_hal_conf.h line 246, well before stm32h7xx_hal_cortex.h at line 298), the legacy header gets processed immediately with STM32H7 still undefined. The #if defined(STM32H7) guard at stm32_hal_legacy.h line 3670 silently skips the USB FS clock macros. Once stm32h7xx.h defines STM32H7 on the very next line, the legacy header's include guard has already locked it out.

   Swapping the two lines fixes it:

#include "stm32h7xx.h"                 // define STM32H7 first
#include "Legacy/stm32_hal_legacy.h" // now #if defined(STM32H7) evaluates true

  This is separate from the GPIO AF bug and is a HAL driver-level issue. Worth a second ticket perhaps?

 

Best regards

PKB404

Ghofrane GSOURI
ST Technical Moderator
August 5, 2026

Hello ​@PKB404 

I am sharing with you the response of our expert in the escalated  ticket #0064918

In Cube firmware, stm32h7xx_hal_def.h, the includes are already in the expected order:

 

 

This is also consistent with the GitHub reference:stm32h7xx-hal-driver/Inc/stm32h7xx_hal_def.h at 2ef1c0203b6953acb9751727ba34ce8ee7906783 · STMicroelectronics/stm32h7xx-hal-driver

Thx

Ghofrane 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.