2026-05-08 1:37 AM - last edited on 2026-05-08 1:45 AM by Andrew Neil
Environment:
- MCU: STM32H743IITx
- USB PHY: USB3300 (ULPI, external HS PHY)
- HAL version: STM32CubeH7 v1.11.6
- Mode: USB Host, HS, ISOC transfer (UVC camera)
- HFIR: 7500 (manually set for 60MHz PHY clock)
Problem:
HPRT.PENA is cleared by hardware at exactly HFNUM=16383 (14-bit frame
counter maximum, about to roll over to 0). HPRT value at the moment of
HAL_HCD_PortDisabled_Callback: 0x00001409.
Key observations:
1. PCSTS=1 at the time of the event — device is still physically connected
2. This happens 100% reproducibly at frame 16383, never at any other frame
3. Without SDRAM (FMC) and LTDC active, the issue does not occur for 1.5+ hours
4. With SDRAM only: occurs after ~7 minutes
5. With SDRAM + LTDC (framebuffer in SDRAM): occurs within seconds
6. Temporarily shorting USB3300 VCC to GND with a probe (adding bypass
capacitance) eliminated the issue for 50+ minutes — suggesting power
supply noise is a contributing factor, but the frame=16383 correlation
is too precise to be purely noise-driven
Question:
Is there a known hardware behavior or errata in STM32H743 USB OTG HS
where the 14-bit HFNUM counter rollover (16383→0) can trigger a spurious
PENCHNG interrupt and clear PENA, even when the USB device remains
physically connected?
2026-05-08 6:31 AM
Hi @hi_cc
Would you attach minimum firmware to reproduce the issue?
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.
2026-05-08 11:12 PM
2026-05-11 6:52 AM
Hi @hi_cc
Thank you for the details.
First, I would suggest to change the USB clock source,
PeriphClkInitStruct.UsbClockSelection = RCC_USBCLKSOURCE_HSI48;
Operating in USB host mode imposes a strict clock accuracy requirement of ±0.05%. The internal HSI48 oscillator, even when using the Clock Recovery System (CRS), cannot meet this requirement because its minimum trimming step is 0.11% or 0.18%, which is not precise enough. Therefore, only an external clock source such as HSE can provide the necessary accuracy for USB host mode. HSI48 with CRS is only suitable for USB device mode, where the accuracy requirement is relaxed to 0.25%.
Second, FRNUM = 0x3FFF indicates the controller is at the last frame before rollover, so that value 16383 is expected and does not itself explain the port disable event.
The likely problem is not the frame counter register, but a side effect triggered at frame rollover or a timing sensitive interaction during integration.
Also, the published ZLP erratum does not appear to match this symptom, since it concerns packet generation behavior rather than PENA being cleared in host mode.
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.