AnsweredAssumed Answered

[BUG] USB DFIFO write ignored during SOF (host mode)

Question asked by Peter Flox on Aug 31, 2014
Latest reply on Mar 25, 2015 by Peter Flox
Hi folks,

I debugged an issue with my own USB Full-Speed host stack where transmission stops at random.
Chip: STM32F407@168MHz, USB_FS core, internal PHY

In my test scenario I am using using a USB memory stick (MSC class, BOT, transparent SCSI command set) and try to write 2MB of data on it. I am using the Chan's FatFS code. The write is issued via a number of subsequent 32000bytes long f_write calls.

My low level USB code writes one packet to the according endpoint DFIFO and then waites for an ACK before writing the next packet to the DFIFO. All other error conditions are properly handled, logging shows they do not occur.

My logging reveals that the transfer always stops when the DFIFO is written during a change in the frame number. In that case, it looks like the write to the DFIFO is simply ignored. Is this intended, a silicon bug, or noted in some tiny footnote?

Here is my log output (explanation below):
Time [us] file:line                           code            repeats   description
42036718 app/media/src/usb/usb.c:755          0x0             (15197) SOF
26839399 app/media/src/usb/usb.c:455          0x18080060      (0)     TXSTS
26839398 app/media/src/usb/usb.c:454          0xAB05580       (0)     HCTSIZ
26839397 app/media/src/usb/usb.c:453          0xBA9F0782      (0)     HFNUM2
26839388 app/media/src/usb/usb.c:447          0xBF0781        (0)     HFNUM1
26839387 app/media/src/usb/usb.c:446          0x18080060      (0)     TXSTS
26839386 app/media/src/usb/usb.c:445          0xAB05580       (0)     HCTSIZ
26839381 app/media/src/usb/usb.c:990          0x3             (0)     ACK
26839380 app/media/src/usb/usb.c:889          0x20            (0)     CH-IRQ
26839315 app/media/src/usb/usb.c:455          0x18080060      (0)     TXSTS
26839314 app/media/src/usb/usb.c:454          0x4AB85580      (0)     HCTSIZ
26839313 app/media/src/usb/usb.c:453          0xEDE0781       (0)     HFNUM2
26839308 app/media/src/usb/usb.c:447          0xFA10781       (0)     HFNUM1
26839307 app/media/src/usb/usb.c:446          0x18080060      (0)     TXSTS
26839306 app/media/src/usb/usb.c:445          0x4AB855C0      (0)     HCTSIZ
26839302 app/media/src/usb/usb.c:990          0x3             (0)     ACK
26839300 app/media/src/usb/usb.c:889          0x20            (0)     CH-IRQ
The lower part shows a regular channel interrupt (CH-IRQ), which is an ACK (on EP3, bulk out). Then follows a register dump of EP3 HCTSIZ, NPTXSTS, and HFNUM before the write to the DFIFO. The registers are dumped once more after the DFIFO write. Everything works as expected here, note that HCTSIZ changed.
The upper part shows the errornous event where the frame number (check HFNUM) changes during the write to the DFIFO. HCTSIZ remains unchanged.

Is this a silicon bug?

Outcomes