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.