You are here

bulk transfer errors on subsequent connects. | Cypress Semiconductor

bulk transfer errors on subsequent connects.

Summary: 2 Replies, Latest post by davidw on 06 Jun 2013 02:25 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
dennisjm's picture
33 posts

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.


dennisjm's picture
33 posts

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

davidw's picture
4 posts

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

Log in to post new comments.