BIG BUG - CubeMX, STM32L476 and USB OTG Device Only and HAL_GPIO_EXTI_Callback

[Kent Swan]

STM32L476 with STM32Cube_FW_L4_V1.12.0. Configuring for Device only OTG, CubeMX ALWAYS generates HAL_GPIO_EXTI_Callback in usbd_conf.c for VBUSDetect. This HAL_GPIO_EXTI_Callback generated code does not have any USER CODE BEGIN... USER CODE END construct. This means that this generated code HOGS the HAL_GPIO_EXTI_Callback and does not permit any other EXTI actions to be stably implemented within the callback.

RULE 1: It is not permissible for a single generated peripheral pin function (such as HAL_GPIO_EXTI_Callback) in a way that additional normal usage of that function is blocked in a way that you cannot add the other usages of the function in a stable manner.

[Kent Swan]

More bad news. HAL_GPIO_EXTI_Callback for VBUSDetect is generated without regard to the enable/disable selections in CubeMX. Means that this CubeMX implentation is badly broken.

[Kent Swan]

Observation: HAL_GPIO_EXTI_Callback should probably be generated in main() and include the normal USER CODE blocks so that additional defined EXTI pins can be reliably incorporated without undue strain.

[Kent Swan]

WORK AROUND!!!!!

Found a workaround to CubeMX not generating the HAL_GPIO_EXTI_Callback in usbd_conf.c with USER CODE blocks to allow extension. The following is a stable hack under CubeMX regeneration.

1. At the top of usbd_conf.c in USER CODE 0 block add the following

• #undef HAL_GPIO_EXTI_Callback
  • #define HAL_GPIO_EXTI_Callback HAL_GPIO_EXTI_Callback_VUSBDetect

2. Where ever you implement HAL_GPIO_EXTI_Callback add the following inside that code

HAL_GPIO_EXTI_Callback_VBUSDetect(GPIO_Pin);

What this does is renames the improperly defined HAL_GPIO_EXTI_Callback to HAL_GPIO_EXTI_Callback_VBUSDetect in a way that compiles and links properly even when code is regnerated and thus allows you to add the additional EXTI captures in a stable manner