9 Replies Latest reply on Nov 27, 2012 8:41 AM by content.librarian

    Cancelling of Control transfer causes following Control transfers to fail.

          Cancelling of Control transfer is very common operation. For example while user terminates the program, typically all pending I/O operations are cancelled. Therefore this case should be handled properly in device.   
          Right now there is a concurrency issue in processing of Control transfers between FX3 hardware and setup callback (as this is already mentioned in FX3 documentation as well). When new SETUP packet arrives then the hardware switches to serve this new request while software continues to serve previous (cancelled) one, supplying hardware with expired data this way. Result is chaos - wrong data read/written, errors, transfer hanging, etc.   
          As cancelling is so common, then I expect that fixing this could have high priority. Assuming that quick bullet-proof  implementation is impossible with current hardware (as it typically tends to be) then even polling "new SETUP packet arrived" flag in SW and failing CyFx3BootUsbDmaXferData, CyU3PUsbSendEP0Data, etc., functions as soon as possible would be a great improvement.   
          BTW, is there a function for flushing/resetting Control Pipe DMA in Boot Loader API? This functionality is needed for recovering from situations where not all data are transferred, especially when CyFx3BootUsbDmaXferData will be fixed to return error when new SETUP packet arrives.