Issue with STM32Cube generated code for USB Host with middleware ''platform settings''

[Jon Carrier]

Posted on April 13, 2018 at 23:17

I am not sure if this is the best way to report issues with STM32Cube, if not please let me know and I can go the suggested path.

Before describing the actual issue here are the primary configuration settings using STM32F767ZI Nucleo that are related to the problem:

- Pinout: USB_OTG_FS: set to 'Host_Only'

- Pinout: Middleware: USB_HOST: 'Host supporting ALL classes'

- Configuration: Middleware: USB_HOST: Platform Settings: Set 'Supported IPs' to 'GPIO:Output' using PG6

This generates code for USBH_Start() containing the following:

/* Activate VBUS on the port */

USBH_LL_DriverVBUS (phost, TRUE);

The issue is that USBH_LL_DriverVBUS() is defined such that the second parameter is inverted logic.

Here is the function comment for USBH_LL_DriverVBUS():

/**

  * @brief  Drive VBUS.

  * @param  phost: Host handle

  * @param  state : VBUS state

  *          This parameter can be one of the these values:

  *           0 : VBUS Active

  *           1 : VBUS Inactive

  * @retval Status

  */

So when calling USBH_Start() with TRUE, it is actually turning the port's VBUS OFF instead of ON. The same issue exists for USBH_Stop().

Simply changing the call above to use FALSE (and similarly for USBH_Stop, setting to TRUE), the issue of the USB host not working will be resolved.

#nucleo-stm32f7 #bug-report #stm32-stm32cube

[Brown.Paul]

I'd like to know if this issue is being addressed. It is difficult to work around bugs in auto-generated code. I hit this issue today and only by knowing the exact problem was I able to find this 'question'.

Or is there another mechanism for reporting STM32CubeMX bugs?

[Ede S]

Same problem than the two previous contributors. I lost one day working on that, then by chance I found the bug by another way, but, the problem is exactly the one described here (Nucleo board with STM32F4, FreeRTOS, LwIP, USB and FATFS together, code generated from FW_F4 V1.23.0).

[Ede S]

Same problem than the two previous contributors. I lost one day working on that, then by chance I found the bug by another way, but, the problem is exactly the one described here (Nucleo board with STM32F4, FreeRTOS, LwIP, USB and FATFS together, code generated from FW_F4 V1.23.0).