bulk transfer errors on subsequent connects.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
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.

0 Likes
2 Replies
Anonymous
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.

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