March 7, 2025

Black Pill boards - F411 USB -- VBUS sensing

What the heck is VBUS sensing?, I hear you say.

That is exactly what I said. I think I have a clue after looking at the schematic for the STM32F429 discovery board, but hold that thought for just a while.

The F411 code we are working with has a compiler macro called VBUS_SENSING_ENABLED. I have been ignoring it for the most part up to know, but have gotten curious about it. It is not defined for our build.

Code in usb_bsp.c (which we dicarded) configures GPIO pin A9 as an output when USB initializes, but configures it as an input when the USB system de-initializes. The GCCFG register has several bits that configure VBUS sensing, including one to disable it (which does get set in our case.) There are two interrupts related to it that can be enabled.

The ultimate purpose of all this can be found in library/usbd_core.c where it is used to identify events when a device is connected or disconnected.

And indeed this is the purpose of all this. On the F429 discovery board, the Vcc (5 volt) line from the USB connector is routed to a GPIO line that would allow sensing of whenever a powered device was connected. This would seem to only be useful in host mode, so I am not at all clear why this gets involved at all with our device mode driver. Whether it could be used at all, and how, would depend on details of the circuit board design outside of the F411 (or F429) chip itself.

The concept of connected or not connected seems to have various definitions. Some drivers consider a chip connected as soon as a reset takes place and enumeration is launched. This makes sense to me. The definition in this driver is somewhat different. Without VBUS sensing, our driver will always indicate that it is connected as per the following routine in vcp/usbd_usr.c

uint8_t usb_isConnected(void) { return USB_CONNECTED; }
A final note. This file "usbd_usr.c" does not seem specific to VCP and is probably mislocated. This is indeed correct, and I moved it.

A general review of all the files in the usbF4 source tree is in order. Here is some surprising information about the 3 directories involved:

library -- 2577 lines of code
vcp  -- 849 lines of code
driver -- 5297 lines of code
The hardware specific driver is nearly twice as big as the general USB code. I find this surprising.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org