STM32F7 USB CDC Device Descriptor Request failing

[lejanz]

I am struggling to get USB CDC working. I am very far down a rabbit hole and I'm completely stuck.

I am using HAL libraries for USB_OTG_HS on the STM32F746ZGT6, with a 16MHz HSE.

I am running in bus powered mode, VBUS detect disabled, and I have hardwired an external D+ pullup, because I have not been able to get the internal pullup to activate. I know the hardwired pullup is not recommended, but I don't think that is what is causing my problems. My IOC file is attached.

When I connect the device to my computer, windows reports "device descriptor request failed" in device manager. I have determined the following sequence of events is occurring:

1. Connect STM32 to computer (powers on STM32)

2. USB suspend interrupt (USBSUSP)

3. USB wakeup interrupt (WKUPINT)

4. USB reset interrupt (USBRST)

5. Enumeration done interrupt (ENUMDNE)

6. RX fill level interrupt (RXFLVL), packet status == STS_SETUP_UPDT

7. RX fill level interrupt (RXFLVL), packet status == STS_SETUP_UPDT

8. RX fill level interrupt (RXFLVL), packet status == STS_SETUP_UPDT

9. Nothing for about 500ms

10. Steps (4) to (9) repeat 2 more times

11. USB suspend interrupt (USBSUSP)

My interpretation of this sequence:

1. USB suspend triggers immediately on startup because the USB lines are inactive for a few ms

2. Windows detects the device and begins its enumeration sequence, which triggers interrupts on the STM32

3. The device does not respond to the device descriptor request, so after 500ms windows tries again, and then again.

4. After 3 failures, windows reports device descriptor request failed.

After this sequence has completed, I have checked the contents of hpcd_USB_OTG_HS->Setup, and the bytes match up with a USB device descriptor request. To me this all seems to mean that the USG_OTG_HS core is active, and is correctly receiving data on the USB lines.

From what I can tell, the critical step that is missing is the "setup stage done" packet, which should trigger another RXFLVL interrupt with packet status == STS_STUP_COMP. When this packet is read out of the FIFO, a setup done interrupt (STUP) should be triggered, which triggers the OEPINT interrupt. In the handler for OEPINT, the setup packet is parsed and the reply to the device descriptor request should be sent.

According to the RM0385 reference manual: "When the setup stage changes to a data IN/OUT stage, the core writes an entry (setup stage done word) to the receive FIFO, indicating the completion of the setup stage."

Any insight into what is going wrong here would be much appreciated. Thanks!

[Pavel A.]

>  I have hardwired an external D+ pullup, because I have not been able to get the internal pullup to activate. 

Let's begin from this. Why do you think the internal pullup does not work or cannot activate?

[lejanz]

I referenced this post when looking into the internal pullup issue:

https://community.st.com/t5/stm32-mcus-embedded-software/trying-to-get-usb-device-working/td-p/251622

So to my understanding, the internal pull-up is activated when VBUS is above a certain threshold, as long as the USB_OTG core is active and the soft disconnect bit (SDIS) is not set. I confirmed that GCCFG.PWRDWN, GUSBCFG.FDMOD, and GCCFG.VBUSBSEN, were all set, and that SDIS was reset, by calling HAL_PCD_DevConnect().

I don't have VBUS detect wired on my PCB, but I was able to use jumper wires to connect the pin to 5V. Upon doing so, I confirmed that the a USB connect interrupt was called, and the B session valid bit GOTGCTL.BSVLD changed from 0 to 1. Grounding out VBUS detect caused a USB disconnect interrupt, and GOTGCTL.BSVLD was reset back to 0. At no point did windows detect a device. If memory serves, I scoped the data lines as well and didn't see any sort of pull-up effect. I didn't do too much more debugging since I don't have VBUS detect wired in the current design.

[Pavel A.]

Well. So the read requests for descriptors are not received properly or not handled.

Enable debug prints in the USB library; direct the prints to ITM (SWO).  Try to track the sequence of events and see any errors/warnings

[AScha.3]

> I have hardwired an external D+ pullup, because I have not been able to get the internal pullup to activate.

Dont do this - because this cpu/usb has internal pullup, it can switch on. So if it not doing this, you are not at "start the usb now" - so setup something wrong and need do it better. If connecting external pullup - you cannot see this anymore...not helpful.

+

about "internal pullup issue" in the link: there is a old F10x used , that didnt have internal pullup (afaik.).

+

"VBUS detect" you should use (even if you dont use it for OTG , the usb uses this as "info" : usb connected now.)

and not connect to 5V (this is a 3v3 cpu, even with some 5v "tolerant" pins) direct, use a 2k/3k3 voltage divider to give the pin about 3v3 , when usb is connected.

Then tell: what its doing...

[lejanz · Accepted solution]

SOLVED:

It turns out I did not have VDDUSB connected to 3.3V. I fixed that issue and it works like a charm. I guess that's a good lesson in always triple checking your power supply scheme.

Thanks to everyone who replied!