Cancelling of Control transfer causes following Control transfers to fail. | Cypress Semiconductor
Cancelling of Control transfer causes following Control transfers to fail.
Summary: 9 Replies, Latest post by Lumpi6 on 27 Nov 2012 08:41 AM PST
Verified Answers: 0
07 Sep 2012 09:47 AM PDT#1
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.