We modified a bit the AN75779 application note example and we noticed this strange behavior on a GPIF state machine with a multi-channel manual-commit dma.
In order to avoid a call to CyU3PDmaMultiChannelSetWrapUp in the code, we replaced the INTR_CPU action in PARTIAL_BUF_IN_SCK* states with a COMMIT. The result is a double commit or at least a double DmaCallback call. The first time we get a partially filled buffer with status = 8 (and this is the expected behavior). The second time we get an empty buffer (count = 0) with an error status (status = 10).
Please notice that in PARTIAL_BUF_IN_SCK* states the "Repeat actions until next transition" checkbox is unchecked and we added a LOGIC_ONE transition to an IDLE state to be shure that the state machine does not remain in the PARTIAL_BUF_IN_SCK* state for more than a clock cycle.
Could you suggest a solution? Is this a GPIF bug?
Thank you very much in advance.
Right. We need to do IN_DATA action along with the COMMIT action. If we don't do IN_DATA then it will generate a Zero length packet after committing the short packet. But if you do IN_DATA then there is a chance that you may see extra data for one clock cycle. Anyways, you can try adding IN_DATA action where you are doing the COMMIT action.
I think the best way to handle short packet is through CyU3PDmaMultiChannelSetWrapUp API call only.