2025-01-09 2:49 AM
Hello,
we are using the ST USB Stack in Device mode in an F413 project with a CDC Device Class (STMicroelectronics Virtual COM Port).
Both HAL and USB Stack code are from ST github at https://github.com/STMicroelectronics/stm32-mw-usb-device.git and https://github.com/STMicroelectronics/stm32f4xx_hal_driver, so should be the latest version.
It is a self(battery) powered device and we are using vbus sensing on PA9.
The project was initially CubeMx generated. MX_USB_DEVICE_Init is called once after startup.
In general the USB Stack works, but we are facing one serious problem:
After some time, could be hours or days when the device was not plugged in (or just connected to a USB charger), when the device is then reconnected to a PC (Linux or Windows) the device is no longer recognized/enumerated by the host.
Windows is showing some error; under Linux we see some error code in the log.
There is some power drawn from the USB, we verified that it is below 100mA so that should be ok.
In oder to understand what is happening we put in some debug code in the HAL_PCD_IRQHandler which logs the IRQs. The debug code just logs the interrupts to a buffer, the log printout (on UART) is then done later completely independent from HAL_PCD_IRQHandler so the USB ISR is not affected timing-wise.
When this problem of "not being able to enumerate" happens we see the below sequence of interrupts. It seems that the Suspend/Resume is triggered all the time. When the device is then unplugged and re-plugged the same thing happens again. It seems the USB Stack or the OTG hardware is stuck somehow. The only way to make the device enumerate properly again is to reset the device.
How can this happen? Is there something in the USB Stack that could lead to this situation? Could it be the OTG peripheral that gets stuck somehow?
Very strange.
Any hint what we could do to fix that problem is very much appreciated!
Many thanks in advance
Chris
Embedded FW developer, acurana GmbH
USB interrupts when the "unable to enumerate" happens
=====================================================
USB: IRQ: Session request/new session detected interrupt
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: ConnectCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: USB reset
USB: IRQ: Enumeration done
USB: ResetCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB reset
USB: IRQ: Enumeration done
USB: ResetCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: Resume/remote wakeup detected interrupt
USB: ResumeCB
USB: IRQ: USB suspend
USB: IRQ: Resume/remote wakeup detected interrupt
...
(keeps going for some time, then eventually stops)
USB Stack init settings
=======================
USBD_StatusTypeDef USBD_LL_Init(USBD_HandleTypeDef *pdev)
{
/* Init USB Ip. */
if (pdev->id == DEVICE_FS) {
/* Link the driver to the stack. */
hpcd_USB_OTG_FS.pData = pdev;
pdev->pData = &hpcd_USB_OTG_FS;
hpcd_USB_OTG_FS.Instance = USB_OTG_FS;
hpcd_USB_OTG_FS.Init.dev_endpoints = 6;
hpcd_USB_OTG_FS.Init.speed = PCD_SPEED_FULL;
hpcd_USB_OTG_FS.Init.dma_enable = DISABLE;
hpcd_USB_OTG_FS.Init.phy_itface = PCD_PHY_EMBEDDED;
hpcd_USB_OTG_FS.Init.Sof_enable = DISABLE;
hpcd_USB_OTG_FS.Init.low_power_enable = DISABLE;
hpcd_USB_OTG_FS.Init.lpm_enable = DISABLE;
hpcd_USB_OTG_FS.Init.battery_charging_enable = DISABLE;
hpcd_USB_OTG_FS.Init.vbus_sensing_enable = ENABLE;
hpcd_USB_OTG_FS.Init.use_dedicated_ep1 = DISABLE;
2025-04-03 9:05 AM
Do you reproduce on reference board ? or simply only on custom board? Could you provide detail on how do you handle the VBUS detection? Do you use deinitialization step before reinitializing the USB stack to ensure that the peripheral is in a clean state?
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-04-15 3:20 AM
Hi FBL,
many thanks for picking this up.
Here are some details on how we handle things:
We did not try on a reference board. Only on our custom board.
VBus detection: PA9 (VBUS_SIG_IN) is connected as you can see on the attached schematic.
The PWR_GOOD_IN is coming from a BQ24093 Charger IC, which is supplied by the USB VBUS.
The VBUS_SIG_IN is very clean, no bouncing whatsoever, the BQ24093 seem to be doing some nice debouncing.
So we assume that the VBus detection on PA9 is clean. In fact it always works when connecting the device the 1st time. In this case the USB Stack always comes up / enumerates nicely on both Windows and Linux.
The problem that we see is happening after we have the device supplied by just a USB power supply for a few days. If we then disconnect the USB PSU and connect a PC we see the above mentioned Suspend resume loop in maybe 70% of all cases.
De-Initialization: We are not using any explicit de-initialization. We are relying on PA9 VBus detection to produce the appropriate Suspend/Disconnect Callback / Session request / Resume etc. calls in the HAL_PCD_IRQHandler ISR.
Also here we would assume that the USB Stack handles proper De-Initialization on USB disconnect.
If there is some explicit De-initialization that we could add to the the existing Callbacks (Disconnect/ Suspend etc). would be interesting.
thanks a lot, Chris
acurana GmbH