Disable VBUS sensing

[manuelbl]

Fixes #1119
Partially fixes #1073 (*).

So far, the USB OTG peripheral has been initialized with active VBUS sensing. This doesn't make much sense as the driver is a device mode only driver. It does not support host mode let alone switching between modes. Furthermore, VBUS sensing requires VBUS be routed to a specific pin.

The unfortunate side effect was that the USB OTG driver would not work with several F4 series chips, in particular F411CE and F446RE (probably all F446xx versions).

This pull request disables VBUS sensing and fixes the issues on the above chips (*). It covers both USB core ID 0x1200 and 0x2000.

The code has been successfully tested on:

• Chinese Black Pill with STM32F401CCU6
• STM Nucleo-F411RE
• STM Nucleo-F446RE

The tests included my bulk endpoint speed test (source, sink, loopback) as well as gadget0. Note that three gadget0 tests fail on all boards, before the code changes, after the code changes and with boards using a different USB driver.

If anyone would like to use VBUS sensing, it can be easily activated after initializing the USB driver.

I also tried to include a Nucelo-L476RG board into the tests. However, it seems that libOpenCM3 thinks that all L4 series chips have a USB FS device peripheral, when in fact only L41xx through L46xx have while L47xx through L4Axx have an USB OTG peripheral. That's will be a separate issue...

(*) As mentioned in #1073, the F446RE additionally requires reverting 26ab78a.

[manuelbl]

I've additionally tested Nucleo-F412ZG. It works as well (with 26ab78a reverted).

Can anybody help me with the integration checks? It doesn't look like something related to my change and at the moment the details can't even be viewed (502 Bad Gateway).

[manuelbl]

Jenkins is up again but the error message is very strange:

make[1]: *** No rule to make target '../../../include/libopencm3/usb/hid_usage_tables.h', needed by 'usb_hid.o'.  Stop.

The code base does not contain a single reference to hid_usage_tables.h or similar, let alone a file of that name. So where does this reference come from?

[OpenUAS]

@manuelbl First of all thanks fro your work on this. Just curious is this "hid_usage_tables.h" could be solved, so to come closer to a honoured pull request?

[manuelbl]

@karlp How can we progress the different USB related PRs? What kind of tests and reviews are needed? Who can perform them?

Can we support you with the Jenkins problems? The error message mentioning hid_usage_tables.h indicates that either the wrong code is checkout from GitHub or a previous build wasn't cleaned up correctly. (hid_usage_tables.h refers to a different PR.)

[karlp]

the jenkins bugs are fucking crazy, I have no idea why why it fucks up here, but not locally, and not when I run in the same buildroot on the jenkins host. 😡

Generally though, it's been brought up before, and the "right" solution IMO, is an api option for vbus sensing, not hard decisions on or off. Of course, there's no great way of doing API options right now. At least, that's how I remember this last time I looked at it.

[manuelbl]

Regarding Jenkins: The error message sounds as if the .d files from a previous build have not been cleaned up. I'm not familiar with Jenkins and how it switches between different check-outs. But some additional clean up might be needed. Possibly make clean is sufficient.

Regarding VBUS sensing: It certainly makes sense to have it configurable. But the default should be that VBUS sensing is not enabled as most hardware design lack the required wiring. And that's what this simple change achieves. So I think this change adds immediate value. More options can be added later.

[aligitlabmirror]

Hi I am barely any sort of expert here, but trying this patch with the weact f411 board, the usb port does at least get a reaction from the computer (it didn't before) but none of the Nucleof4 USB demos successfully run:

USB Midi (which is what interests me the most)

[2097592.917568] usb 1-5.1.4.2: new full-speed USB device number 77 using xhci_hcd
[2097593.001587] usb 1-5.1.4.2: device descriptor read/64, error -32
[2097593.189889] usb 1-5.1.4.2: device descriptor read/64, error -32
[2097593.377578] usb 1-5.1.4.2: new full-speed USB device number 78 using xhci_hcd
[2097593.465531] usb 1-5.1.4.2: device descriptor read/64, error -32
[2097593.661527] usb 1-5.1.4.2: device descriptor read/64, error -32
[2097593.769647] usb 1-5.1.4-port2: attempt power cycle
[2097594.373524] usb 1-5.1.4.2: new full-speed USB device number 79 using xhci_hcd
[2097594.373604] usb 1-5.1.4.2: Device not responding to setup address.

I also tried CDC

[2097793.354006] usb 1-5.1.4.2: new full-speed USB device number 59 using xhci_hcd
[2097793.354138] usb 1-5.1.4.2: Device not responding to setup address.
[2097793.562119] usb 1-5.1.4.2: Device not responding to setup address.
[2097793.769966] usb 1-5.1.4.2: device not accepting address 59, error -71
[2097793.770030] usb 1-5.1.4-port2: unable to enumerate USB device
[2097795.254002] usb 1-5.1.4.2: new full-speed USB device number 60 using xhci_hcd
[2097795.334148] usb 1-5.1.4.2: device descriptor read/64, error -32
[2097795.522142] usb 1-5.1.4.2: device descriptor read/64, error -32

[manuelbl]

This PR is probably not sufficient to fix all the current libopencm3 USB issues. I recommend to apply this entire list:

• Disable VBUS sensing #1256 Disable VBUS sensing
• Fix usb_dwc_common.c endpoint initialization #1258 Fix usb_dwc_common.c endpoint initialization
• Fix usb_dwc_common.c late IN usb interrupt flag clearing, #1241 #1259 Fix usb_dwc_common.c late IN usb interrupt flag clearing
• USB Core 0x2000 Fix #1261 USB Core 0x2000 fix

And make sure the clock configuration is suitable for USB operation.

I have successfully tested it with a NUCELO-F411RE board (using the gadget0 and my own loopback test).

[aligitlabmirror]

@manuelbl thanks for that info. I merged all 4 and I get the same issue, sadly.

I'm using this clock:

rcc_clock_setup_pll(&rcc_hse_16mhz_3v3[RCC_CLOCK_3V3_84MHZ]); But I'm going to double check what the HSE actually is on the board because I don't trust the docs.

[aligitlabmirror]

Was the clock, actuallly 25Mhz HSE thank you so much!

[2102586.712719] usb 1-5.1.4.2: new full-speed USB device number 126 using xhci_hcd
[2102589.614122] usb 1-5.1.4.2: New USB device found, idVendor=6666, idProduct=5119, bcdDevice= 1.00
[2102589.614128] usb 1-5.1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2102589.614132] usb 1-5.1.4.2: Product: MIDI demo
[2102589.614135] usb 1-5.1.4.2: Manufacturer: libopencm3.org
[2102589.614137] usb 1-5.1.4.2: SerialNumber: 323536341951393564004C00

[ghost]

@manuelbl so just that I get this right. USB specification requires a pullup to detect device presence.

According to ST's USB design guidelines STM32F4 familiy is supposed to have this pullup embedded.
Is you're PR fixing the configuration in libopencm so this embedded pullup will be used?
At the moment I can only have my STM32F411CEU6 detected if I provide an external pullup.

[manuelbl]

This PR disables VBUS sensing. A side effect is that the internal pull-up resistor on D+ is always enabled. This setup is suitable for bus-powered devices as well as self-powered devices that don't need to turn off the USB peripheral for energy saving or other reasons. It's not suitable for host or OTG role, which isn't supported by libopencm3 anyway.

Do you need the external pull-up resistor even when applying this PR? Or haven't you tried this PR yet?

If you don't turn off VBUS sensing, you need to wire VBUS to PA9, possibly with a voltage divider.

[ghost]

I haven't tested your PR yet. I'm not even sure if it is possible to custom build libopencm3 in PlatformIO. I'm kind of new to STM32 development using libopencm3 and after fighting cryptic makefiles and linker scripts for days I decided to go the easy way and use PlatformIO.
I was trying to make the usb cdcacm example work on my Blackpill board when I realized that it is not recognized without providing an external 1K5 between PA12 and 3V3.

[manuelbl]

The easiest approach is probably to add the below code after calling usbd_init in your code:

OTG_FS_GCCFG |= OTG_GCCFG_NOVBUSSENS | OTG_GCCFG_PWRDWN;
OTG_FS_GCCFG &= ~(OTG_GCCFG_VBUSBSEN | OTG_GCCFG_VBUSASEN);