1 Reply Latest reply on Dec 6, 2012 5:31 AM by userc_39074

    Which work around for known ZLP Bug on SDK 1.2.1




      I’m using the sync. slave interface  (32bit) with an auto DMA channel to connect an FPGA to an Bulk-In-EP with 16 burst's.
      I have the known Problem on SDK 1.2.1, that after a ZLP I loose some data. If I wait some time after the ZLP, for example 150us, it works a little bit better. It will be better, if I wait more time like 1ms. But I think this is not a good solution, because there is no specified time on which it is safety. The next workaround to wait of EOP and suspend the DMA is not possible because it is an auto DMA channel and the FX Application don’t know the state of the transfer.

      Have somebody a better workaround or a solution to fix the problem?

        • 1. Re: Which work around for known ZLP Bug on SDK 1.2.1

          The Suspend solution works on AUTO DMA channels as well. You need to setup the channel to suspend on CY_U3P_DMA_SCK_SUSP_EOP on the consumer (USB) side. 


          e.g.: CyU3PDmaChannelSetSuspend (chHandle, CY_U3P_DMA_SCK_SUSP_NONE, CY_U3P_DMA_SCK_SUSP_EOP); 


          Then in the DMA callback for the CY_U3P_DMA_CB_CONS_SUSP event, the channel operation can be resumed (CyU3PDmaChannelResume). It may be a good idea to insert a small delay (about CyU3PBusyWait (50)) before calling channel resume. We have seen that this solution works for at least a couple of customers.






          Sai Krishna.