2 Replies Latest reply on Jun 6, 2013 2:25 PM by david.wang.2

    bulk transfer errors on subsequent connects.

    dennis.muhlestein

      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.