GPIFII multi-socket DMA, buffer not ready after COMMIT operation

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello,

   

I've implemented a multi-socket DMA channel from GPIF to USB. I use 2 PIB sockets and implement a counting mechanism to switch between threads within the GPIF state machine - everything is OK (attachment 1).

   

But after that I have to commit "short packets" sometimes, while the external master is continuously streaming data. In order to achieve this, I use the COMMIT action (within the state machine). Immediately after that thread switching is performed (attachment 2).

   

And, unfortunately, it turns out, that after the COMMIT action another buffer is not ready immediately - overrun events are generated and the data become corrupted. The problem can be avoided if I insert a 100-cycle delay after the COMMIT action, but this is not acceptable.

   

Is there any workaround to perform immediate buffer switching after the COMMIT action, like as with the full buffer switching?

0 Likes
2 Replies
Anonymous
Not applicable

Hi,

   

In the state machine, you have initialized the Counter limit value for LD_ADDR_COUNT  to 4094 and Counter limit value for LD_CTRL_COUNT  to 4095. I suppose you have configured the DMA buffer size to be 16KB in FX3 firmware. In this case,  LD_ADDR_COUNT  has to be initialized to 4095.

   

Could you tell the exact functionality that you want to implement in the GPIF state machine.

   

You can refer to the GPIF state machine provided in example project associated with AN75779. In this application, we have implemented Many to One DMA channel (Producer: PIB_SOCKET_0 and PIB_SOCKET_1, Consumer: UIB_SOCKET_CONS) and switching between threads occur when the counters hit the limit. 

   

Download AN75779.zip from the following link:

   

http://www.cypress.com/documentation/application-notes/an75779-how-implement-image-sensor-interface-...

0 Likes
Anonymous
Not applicable

Thanks for the reply,

   

I've initialised ADDR_COUNT ER to 4094 because when it hits. I finally proceed with one more DATA_IN along with the COMMIT action. So, when ADDR_CNT_HIT event is produced, COMMIT has no effect (buffer is filled with 16384bytes), but when DATA_CNT_HIT is produces, I would like to see short packet commited to the USB side.

   

The actual problem I'm solving is to generate a short packet after some amount of bytes transferred to the USB.

   

Well, this SEEMS to work with some delay after COMMT action (despite I write to a different DMA thread and hoped no delay is necessary). But unfortunately it turned out to work in unstable manner with corrupting data flow after a few minutes of transferring the data at 100MB/s.

   

No problems with AN75779, but it is implemented with MANUAL channel, while I prefer AUTO channel for this design.

   

Is it correct to use COMMIT operation from the state machine with AUTO channel?

0 Likes