2021-03-26 08:30 AM
It only happens when there's an active transfer.
The OTG interrupt was called every 3...6uS (300-500 Core clocks @ 96MHz).
It seemed crazy excesive to me, that can't be correct!
Just to clarify: STM32F411, internal FS controller, cubeIde initialization, host mode (OTG).
Checking what interrupt flag was causing the calls, I found the culprit to be the SOF flag.
I put a small variable there and traced using SVW:
I have SOF disabled in CubeMX, however the code enables it anyway:
IDE: STM32Cube IDE v1.6.0
FILE: stm32f4xx_ll_usb.c
LINE: 1355
FUNCTION: HAL_StatusTypeDef USB_HostInit(USB_OTG_GlobalTypeDef *USBx, USB_OTG_CfgTypeDef cfg)
USBx->GINTMSK |= (USB_OTG_GINTMSK_PRTIM | USB_OTG_GINTMSK_HCIM | \
USB_OTG_GINTMSK_SOFM | USB_OTG_GINTSTS_DISCINT | \
USB_OTG_GINTMSK_PXFRM_IISOOXFRM | USB_OTG_GINTMSK_WUIM);
Removing USB_OTG_GINTMSK_SOFM from the mask fixed the problem.
I'm still having interrupts every 40uS (around 3000 cpu cycles) caused by the USB_OTG_GINTSTS_RXFLVL flag.
Edit: That's correct, due the 64-byte buffer triggering the FIFO interrupt
(64 bytes = 512 bits, at USB 12MHz clock = 42uS).
However it still has does some 3-5uS ones. Not a thousand, but maybe 10 out of 20.
Maybe the interrupt is not being fast enough ?
This is a 512-bytes read:
Cycles Timestep(uS)
3631
4027 4,1
4455 4,5
4922 4,9
6036 11,6
21355 159,6
89994 715,0
95273 55,0
100552 55,0
104458 40,7
108230 39,3
111117 30,1
113988 29,9
123957 103,8
124385 4,5
124899 5,4
125324 4,4
130489 53,8
130917 4,5
131431 5,4
133660 23,2
137085 35,7
140378 34,3
143691 34,5
147096 35,5
148832 18,1
2021-03-26 03:53 PM
Which STM32?
Device or host?
Okay I've guessed, host.
If you have SOF interrupt more often than once in a frame (maybe microframe in HS, I don't use HS), then it's likely you've set the frame timer (OTG_HFIR) incorrectly. Observe, how fast frame number in OTG_HFNUM increments, and observe the SOF frames on the bus.
JW
2021-03-27 10:17 AM
OTG, so Host mode. Internal FS controller.
Default CubeMx configuration.
I might be a debugging issue, as it seems to happen a lot more when you halt the core, I guess the USB keeps working in the background, the interrupts pile up, and when you resume it's like a tsunami.