Why aren't global FS interrupts firing even though the control transfer occurs? (USBD VCP)

[ZThat]

I am currently attempting to use the USBD drivers for the STM32F765 in order to communicate over USB C as a virtual com port. I get to the point where my computer recognizes the device and the driver that is necessary, therefore the control transfer is occurring over the cable. However, the global FS interrupts then fail to fire when I send messages to the board. Also, when sending messages from the board to the computer the pClassData fails to populate (which prevents anything from sending in an if statement). I currently configure the device to be peripheral only by setting the FDMOD bit in the OTG_GUSBCFG register to 1, and I disable Vbus sensing. Therefore the Vbus is not configured or connected to anything. Could this be causing issues? Also, the pClassData is set to 0x00000 and is a single index array with a value of zero. Does this mean that I am not managing to configure the FIFO buffer for the class?

How should I troubleshoot this?

Thanks!

[waclawek.jan]

> I currently configure the device to be peripheral only by setting the FDMOD bit in the OTG_GUSBCFG

> register to 1, and I disable Vbus sensing. Therefore the Vbus is not configured or connected to anything.

> Could this be causing issues?

No, at least not directly.

> the global FS interrupts then fail to fire when I send messages to the board

It's debugging as usual: check whether the given endpoint's registers are configured correctly, whether all interrupt enables which are supposed to be enabled are enabled, whether the interrupt/status flag which is supposed to get set upon message arrival got set.

Given the quirky Synopsys OTG IP and woeful state of documentation and, well, soft...Cube you are using? - yes, it's not a trivial undertaking. I know of no magic solution, just sweat, sorry.

JW

[ZThat]

This ended up being a board issue. Once the board issue was fixed, this solved itself. However, an interesting note is that the chip will not re-enumerate if it resets while plugged in. It used to do so when using normal micro to USB 2.0 connection. Now that it uses a USBC connection the enumeration will only occur upon plug-in (when the chip is powered of course).

[waclawek.jan]

I don't quite believe this is USB-C-specific, rather, it may be a coincidence. Do you have battery charging or any other DP/DM-connected circuitry implemented around the USB-C?

JW

[ZThat]

​Yes. There is a USB PD being used for power delivery negotiations.

[waclawek.jan]

Disconnect is detected by the host/hub through detecting missing pullup on DP (for Full Speed) for a specified time. Host/hub has a 15kOhm pulldown to discharge the parasitic capacitances. If your circuitry pulls up DP actively during reset, or the reset duration is too short, it may happen that DP does not reach low level for long enough.

JW