STM32N6570-DK + USBX host: composite FTDI FT600 fails the first control transfer (port reaches PENA at HS); mass-storage device enumerates fine
Board / software
- STM32N6570-DK (MB1939), STM32N657X0H3Q
- STM32Cube FW_N6 V1.4.1, ThreadX + USBX from the package (not X-CUBE)
- STM32CubeIDE, load-and-run development flow (ELF downloaded into internal SRAM by the debugger; no FSBL, no XIP, no external loader)
USB2_OTG_HSconfigured as Host_HS on CN17, internal HS PHY- OTGPHY2 clock =
RCC_USBPHY2CLKSOURCE_HSE_DIRECT, 24 MHz HSE crystal - CPU 600 MHz, AHB 200 MHz
- USBX:
UX_MAX_DEVICES8,UX_APP_MEM_POOL_SIZE98304,USBX_MEMORY_STACK_SIZE65536, only the CDC-ACM class registered
What works
A USB 2.0 mass-storage device (HP, VID 0x03F0 / PID 0x2003) enumerates reliably and repeatedly:
[usb] idVendor : 0x03F0
[usb] idProduct : 0x2003
[usb] bcdUSB : 0x0210
[usb] bMaxPacketSize0 : 64
[usb] speed : HIGH
[usb] state : ADDRESSED
[usb] -- interface 0 class 0x08 (mass storage) 0x06/0x50
[usb] ep 0x81 BULK IN mps 512
[usb] ep 0x02 BULK OUT mps 512UX_DEVICE_ENUMERATION_FAILURE here is expected — only CDC-ACM is registered, so nothing claims it. Device and configuration descriptors are read correctly.
What fails
An FTDI FT600Q (VID 0x0403 / PID 0x601E, composite, IAD, bDeviceClass 0xEF/0x02/0x01, 2 interfaces, self-powered, 96 mA) never completes enumeration on the same port and the same build:
[usb] idVendor : 0x0000
[usb] idProduct : 0x0000
[usb] bcdUSB : 0x0000
[usb] bMaxPacketSize0 : 0
[usb] bNumConfigurations : 0
[usb] speed : HIGH
[usb] state : ATTACHED
[usb] err: UX_DEVICE_ENUMERATION_FAILUREbMaxPacketSize0 = 0 means the first 8-byte GET_DESCRIPTOR at address 0 returns nothing. USBX retries three times, then gives up. Repeated connect/disconnect follows.
The link layer is confirmed good
I instrumented HPRT (OTG core offset 0x440). Observed sequence on plug-in:
| HPRT | Decoded |
|---|---|
0x00021401 | PCSTS, D+ high, PPWR, PSPD=01 (Full Speed idle) |
0x00001501 / 0x00001901 | PCSTS, PRST (host driving reset), PPWR |
0x00001005 | PCSTS, PENA (port enabled), PPWR, PSPD=00 (High Speed) |
So the reset, the high-speed chirp handshake and the port enable all complete. The device's HS transceiver is alive and cooperating. Only the control transfers that follow produce nothing.
Already ruled out, with evidence
| Candidate | Evidence it isn't the cause |
|---|---|
| Host stack / USBX config | Mass-storage device enumerates fully, repeatedly, same build |
| Link / chirp / speed negotiation | HPRT reaches PENA + PSPD=00 |
| Board brownout | Console and tx beat counter run uninterrupted through every attempt; RCC->RSR unchanged at 0x00E00000 |
| LPM / low power | Both DISABLE |
| Device needing retries | On a Raspberry Pi Zero 2 W (also dwc_otg, also USB 2.0 only) the same device enumerates first attempt, zero errors, zero retries — see dmesg below |
| SuperSpeed dependency | The Pi Zero 2 W has no SuperSpeed at all, and it works there |
Raspberry Pi Zero 2 W, same device, same cable:
[3.954369] usb 1-1: new high-speed USB device number 2 using dwc_otg
[4.187470] usb 1-1: New USB device found, idVendor=0403, idProduct=601e
[4.216056] usb 1-1: Manufacturer: FTDI
[4.222393] usb 1-1: SerialNumber: 000000000001The device also enumerates and streams normally on Windows PCs.
HCD configuration
c
hhcd_USB_OTG_HS2.Instance = USB2_OTG_HS;
hhcd_USB_OTG_HS2.Init.dev_endpoints = 9;
hhcd_USB_OTG_HS2.Init.Host_channels = 16;
hhcd_USB_OTG_HS2.Init.speed = HCD_SPEED_HIGH;
hhcd_USB_OTG_HS2.Init.dma_enable = DISABLE;
hhcd_USB_OTG_HS2.Init.phy_itface = USB_OTG_HS_EMBEDDED_PHY;
hhcd_USB_OTG_HS2.Init.Sof_enable = DISABLE;
hhcd_USB_OTG_HS2.Init.low_power_enable = DISABLE;
hhcd_USB_OTG_HS2.Init.lpm_enable = DISABLE;
hhcd_USB_OTG_HS2.Init.vbus_sensing_enable = DISABLE;
hhcd_USB_OTG_HS2.Init.use_external_vbus = ENABLE;Questions
- Is slave mode (
dma_enable = DISABLE) fully supported by the USBX STM32 HCD port on the N6, or is DMA required for reliable control transfers with some devices? - Should
Sof_enablebeENABLEfor the USBX HCD port to schedule correctly? CubeMX generatedDISABLE. - What post-reset settle delay does USBX apply before the first
GET_DESCRIPTOR, and is it configurable? Linux waits roughly 192 ms after connect debounce before enumerating this device; I would like to compare. - Are there known issues or errata with USBX host enumeration of composite IAD devices (
bDeviceClass 0xEF) on STM32N6? - Is there any N6-specific erratum affecting
USB2_OTG_HShost-mode control transfers after the port reachesPENAat high speed?
Happy to provide full UART logs, the complete USBTreeView descriptor dump, or the Pi dmesg on request.
One suggestion before you post it: if you run the usb_port_diag() edit first, you'll be able to add one line that makes the post far stronger — the URB state of the control channel (ERROR vs STALL vs NOTREADY). That single word tells ST whether the device replied at all, and it's the first thing an ST engineer will want. Worth the extra build.
