Hello,

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.

Best regards,

Gianni

Hi Gianni,

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.

Thanks,

sai kirshna.

Thank you very much. It worked.

Regards,

Gianni

 if set IN_DATA with “no Write data into Data Sink” parameter is there no chance that  may see extra data for one clock cycle？