5

STM32 manual for the F4xx series chips says that the application writes TXFFLSH bit in the OTG_FS_GRSTCTL register to flush the TxFIFO. As a note it mentions that ...application must write this bit only after checking that the core is neither writing to the TxFIFO nor reading from the TxFIFO. As a means to do that, it suggests making sure that the NAK Effective Interrupt is set (I presume this means the GINAKEFF bit in OTG_FS_GINTSTS register) to ensure the core is not reading the FIFO, and checking that AHBIDL (AHB idle) bit in OTG_FS_GRSTCTL is set to guarantee that nothing is being written in the FIFO. The (awful) USB OTG library supplied by STM itself ignores both of these checks, while the free libopencm3 library only checks the AHB idle bit. My questions are the following:

  1. The manual does not suggest disabling the USB OTG core before performing the above checks and writing the TXFFLSH bit. Does this not leave open the possibility that the core might start using the FIFO between the time the checks are performed and the writing of the TXFFLSH?

  2. The 'NAK Effective' bit only guarantees that no data is read from the TxFIFO for non-periodic endpoints. Would this not still make it possible for the core to utilize the FIFO for isochronous endpoints unless the core is disabled?

I know these are 'nitpicking' type questions but the project I am working on is supposed to result in a very reliable piece of hardware, where the customer cannot afford checking the device for years so these subtleties matter (yes, we have a watchdog enabled, etc. but we need the core to work without resets most of the time).

Sam Protsenko
  • 14,045
  • 4
  • 59
  • 75
alexsh
  • 1,121
  • 8
  • 12
  • Have you contacted the factory or FAE? Is this chipset one of [OHCI, UHCI, EHCI, XHCI, etc](http://en.wikipedia.org/wiki/Host_Controller_Interface_%28USB%29#USB) or is it some custom register set? It is hard to reply about specifics of how some specific hardware can work. You may get an answer, put your audience is probably limited. – artless noise May 14 '14 at 15:58
  • 1
    We did call an FAE but we are too small to warrant their close attention ('see the manual and the library' basically). The USB OTG macrocell in stm32 chips is a custom implementation of a full speed USB SIE and some transaction logic (not nearly as sophisticated as a full UHCI; I think STM aquired it from somebody else which may explain things). It is a very popular series of microcontrollers. Right now we are just disabling the whole macrocell to flush the buffers (which, remarkably, is not so easy either, just goes to show how badly thought out it is). – alexsh May 14 '14 at 16:47
  • "STM aquired it from somebody else which may explain things" Hint: "DWC OTG" ;) – Kuldeep Dhaka Jul 05 '16 at 20:50
  • also almost ARM uC vendors i know have the same periph with no/minor tweak. – Kuldeep Dhaka Jul 05 '16 at 20:55

0 Answers0