Short packet committed twice on multi dma manual channel.

[GiVa_292201]

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

[Anonymous]

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.

[GiVa_292201]

Thank you very much. It worked.

   

Regards,

   

Gianni