Skip to main content
Z
ZThat
Visitor II
October 23, 2019
Solved

USB Endpoint Zero Stall on 3.0 Sticks Using 2.1 Protocol

  • October 23, 2019
  • 1 reply
  • 824 views

Hello,

I am using the STM32F7 for USB communication as an MSD host and using the usbh_core.c code and all of it's associated pieces. I have it working consistently on USB 2.0 devices (side note: I needed to insert an enumeration retry for certain non-USB compliant sticks), but it only works on certain USB 3.0 sticks. Also, it seems to error out at different points in the USB enumeration process on these 3.0 sticks, which has become more obvious now that I have implemented the enumeration retry.

I am seeing that I occasionally manage to get the device descriptor, but that when I (the host) send the status packets of zero data length to confirm that I got the message, the USB is busy for a short while, indicated by it nacking the message (which is unusual, normally it is not busy at this stage), and then the endpoint stalls. This is all done on endpoint zero. I know that to resolve a stall you typically go through the software reset of the device by pulling the Dp line low for an extended period, but I know that I will just go through the same sequence again if I retry in this way.

Has anyone else experienced getting a stall on endpoint zero? If so, how did you go about resolving it? I have a feeling this is noise, but I want to be sure so that I can confidently claim this to be an electrical issue and pass it off to an electrical engineer to fix. On that note, if you do have a setup with working 3.0 full speed communication, can you let me know what ESD /noise protection you have implemented on the board?

(edit: it may help if I emphasize that some USB 3.0 stick consistently work and others don't. I also don't consistently even get the device descriptor back from the USB stick if it is one of the 3.0 sticks that won't work)

Thanks!0690X00000Aqmo3QAB.jpg

    This topic has been closed for replies.
    Best answer by ZThat

    The root of all of this intermittency was that the 48MHz clock used for USB was actually running at 50MHz. Be careful when using the CubeMX example code as a starting point for an application that uses the 48 MHz clock for multiple purposes that the 48MHz clock isn't being set to 50MHz. 48 should work for both the SD card and the USB. 50 only works for the SD card.

    1 reply

    Z
    ZThatAuthorAnswer
    Visitor II
    January 3, 2020

    The root of all of this intermittency was that the 48MHz clock used for USB was actually running at 50MHz. Be careful when using the CubeMX example code as a starting point for an application that uses the 48 MHz clock for multiple purposes that the 48MHz clock isn't being set to 50MHz. 48 should work for both the SD card and the USB. 50 only works for the SD card.

    Terms & ConditionsAccessibility statement