Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

Not applicable

I have a simple firmware that does a short bulk transfer like this:


CONTROL_OUT-> sends a few bytes of information


BULK_IN <- read a couple bytes of data


BULK_IN <- read a few more bytes of status information


This works correct when I first boot the firmware and run my test.  If I try to run the test again though (firmware still running but close and reconnect to the device with the driver) I get:


CONTROL_OUT-> sends a few bytes (information received on device correctly)


BULK_IN <- timeout.  On the device side the dmabuffer functions were obtained and no error code was submitted.  The data for the 2nd BULK_IN is also committed to a dma buffer w/ out error.


If I try 3-4 times without re-connecting the device gets back in a state where the test passes.  From that point I can execute the test as fast as I want or as many times as I want and it'll continue to pass.  But if I close the device and reconnect (calls SET_CONFIGURATION, AppStop/Start again), the device is back in a state where the first few commands don't transfer the data correctly.


I'm using wireshark w/ usb monitoring on Linux.  The BULK_IN transfer alternates error status of -EPROTO -71 and -ENOENT -2 when the BULK_IN call fails.


If I execute a BULK_OUT instead of bulk in like this:


CONTROL_OUT-> send a few bytes (ok)


BULK_OUT-> send a few bytes 


BULK_IN <- read status


The OUT data is received on the device but the IN data that is the status again has a timeout or error transferring.  Again, if a few attempts are made the device gets back in a state where transfers work as expected.




Anyone have a suggestion as to why this might be happening?  I've stripped my firmware down to almost exactly what happens in the basic firmware examples:


appStart->configure endpoints and dma channels


handle_vendor_commands->minimal application logic 


Thread_Entry->read/write data to dma channel buffers.


appStop->unconfigure endpoints and dma channels




So when I reconnect, stop/start gets called when SET_CONFIGURATION is called, but I've tried disabling the code that tears down and reconfigures the endpoints as a test but it behaves exactly the same.  It seems like there might be some other API call needed to reset back to a working state after SET_CONFIGURATION perhaps.

2 Replies
Not applicable

 Also noteworthy, the test works as expected when plugged into a usb 2.0 port.  I'm only having this issue with usb 3.

Not applicable
        Hi, I encountered similar issue, have you solved this issue? If yes, could you please share the solution? Thanks.