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

[Peter Flox]

Posted on August 31, 2014 at 16:42

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? #stm32-usb-host-dfifo

[tsuneo]

Posted on September 01, 2014 at 15:49

Did you touch to OTG_FS_HFIR register?

It is known by FTREM field (bit 31-16) of OTG_FS_HFNUM register The host core decrements FTREM field by the PHY clock (UTMI 60 MHz) OTG_FS_HFIR register gives the reload value (default: 0xEA60 = 60,000) for FTREM On the upper case, the captured values of OTG_FS_HFNUM are, 26839388 (us) HFNUM1 0x00BF 0781 26839397 (us) HFNUM2 0xBA9F 0782 The estimated time difference by FTREM field is, 0x00BF - 0xBA9F + 0xEA60 = 0x3080 (12416) = 206.93 us But on your log time, only 9 us is elapsed. On the lower case, 26839308 (us) HFNUM1 0x0FA1 0781 26839313 (us) HFNUM2 0x0EDE 0781 The estimated time difference by FTREM field is, 0x0FA1 - 0x0EDE = 0x00C3 (195) = 3.25 us On your log time, it’s 5 us. If OTG_FS_HFIR would be too short, host scheduler should get confused near the end of frame. Tsuneo

[Peter Flox]

Posted on September 02, 2014 at 10:52

Hi Tsuneo, and thanks for your reply. I think the PHY clock is 48MHz for the full speed core, isn't it?

- edit begin - I just verified it, I set FSLSPCS in the OTG_FS_HCFG to 01, thereby selecting a PHY speed of 48MHz. So 48000 should be the correct HFIR value. - edit end - According to that, and to the fact that a full-speed device is connected, I configure OTG_FS_HFIR with a reload value of 48000 (after the port has been enabled). With this value, the time differences shown by HFNUM (FTREM) and log time (calculated based on SysTick counter value and OS time) match. I also see SOFs appearing at a precise 1ms interval. Is there some mistake in my clock configuration/HFIR value?

[Peter Flox]

Posted on September 25, 2014 at 15:31

Is there somebody else who could help me with that problem? clive? (=

The issue still persists. Is there a way to escalate this problem to some ST engineers to check back?

[rabryan]

Posted on January 30, 2015 at 16:32

Did anyone ever figure this out?  We're seeing the exact same issue with a CDC host.  Its hard to believe ST actually tested any of the USB host functionality... It's ridiculously buggy and poorly documented.

[Peter Flox]

Posted on March 25, 2015 at 15:53

Hi Bryan,

at least I am not the only one with this problem. I really think this is a silicon bug and should be put into the errata. I tried several ways of detecting and correcting the ignored DFIFO write, but none of them was working reliable. I finally circumvented the problem by checking the HFNUM value just before a DFIFO write. If the value is below 8192, chances are high that the frame number will change and the write is lost. So if HFNUM < 8192 I skip the DFIFO write and do it as soon as the SOF interrupt triggers. Of course this has a performance impact, but my USB stick wasn't that fast anyway. So I preferred the stable variant over the fast one. Note, that this may still fail if there is a long time (e.g. IRQ) between HFNUM check and DFIFO write.