Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Just to be clear, you are sure that your data is not a multiple of High speed EP max size? In SS, probably you have set the EP max to 1024, but in high speed it can be upto 512 for bulk. Please check if your data is not a multiple of this. What is your data size and EPmax settings of the device?
When performing reset of the dma channel to receive the CY_U3P_DMA_CB_PROD_EVENT this causes the CY_U3P_DMA_CB_XFER_CPLT notification to be missing at times.
My code relies on the DMA channel state to schedule new operation.
When using the above workaround to received the CY_U3P_DMA_CB_PROD_EVENT notification. I have observed the DMA Channel state to fail reporting transfer completion in 97.2% of the time, i.e only 2.7% of the transfer completion are notified (out of 11815 transfers).
When not using the above workaround (dma channel is not reset prior CyU3PDmaChannelSetXfer ). I have observed the DMA Channel state to report transfer completion all the time (out of 10422 transfers).
Since I am using the workaround, my code reports error because it is not able to schedule a new operation due to the invalid DMA Channel State.
The above behavior of invalid DMA Channel State is under USB SS.
What is the source of the data coming to the FX3. And what do you plan to do when you get a short packet?
Are you using GPIF? If so, you need to identify the scenario of short packet and commit the short packet even with auto channel. If so, you can generate a interrupt to cpu at the same time to identify that short packet is recieved.
The SLP is to detect the end of the transfer from the USB side. The GPIF transfer the data to another processor.
The SLP is part of the transfer handling system. If the USB send too little or too much data that it is supposed to for the GPIF to transfer an error will be detected and reported to the USB host via a STALL. The GPIF interface will be reset to recover for the potential dead lock that may occur.
Have you been able to confirm the issue ? I need to have a validation of the issue or perhaps I am missing something in that case what ?