Skip to main content
Associate
May 8, 2026
Question

USB OTG HS Host: PENA cleared spuriously at HFNUM=16383 with ULPI PHY (USB3300)

  • May 8, 2026
  • 2 replies
  • 165 views

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?

2 replies

Technical Moderator
May 8, 2026

Hi @hi_cc 

Would you attach minimum firmware to reproduce the issue?

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.Best regards,FBL
hi_ccAuthor
Associate
May 9, 2026

Thank you for your response. I have attached the minimum firmware to reproduce the issue, along with a detailed description of the observed behavior in issue_report.md.
Please let me know if you need any additional information.

Technical Moderator
May 11, 2026

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 "Best answer" on the reply which solved your issue or answered your question.Best regards,FBL