I have a state machine transferring GPIF to USB. The transition from my wait state is defined as DMA_RDY_THx&!BUSY where busy is a pin on the external interface to indicate if there is data ready, I then read this data until WM, read the rest of the packet and then transfer back to the wait state, the usb packet is sent.

If I get back to the wait state and there is no data ready on my external interface then it waits a while and transitions when !BUSY and everything works fine. If it gets back to the wait state and the interface is already !BUSY then some data is lost (transferred over the GPIF but not transferred over the USB). The only conclusion I can draw from this is that the DMA_RDY and DMA _WM flags are not correct when I am in my wait state? AN65974 indicates that there is a 3 cycle latency of the DMA _RDY flag but insertting a dummy state with considerably more wait than this does not fix the problem. This also seems to be true if I do a commit of a shorter packet and then transfer to the wait state.

I can only think that this might be that the DMA flags are not valid during DMA buffer switching? Is there a way that I can detect the buffers are switching from my state machine?

I think you can know the end of the buffer using two actions:

LD_DATA_COUNT and COUNT_DATA.

You can load the count as your buffer size and you can look for DATA_CNT_HIT.

Thanks,

sai krishna.

Hi Sai,

My issue is not finding the end of a buffer, I can do this happily with WM or Count as you suggest, the problem is that not all of the data transferred over the GPIF is transferred over USB (I am transferring packet at a time over GPIF). The only explanation I can come up with at the moment is that the DMA buffer is not ready to receive data and so the data transferred over the GPIF is not read into a buffer, the only way this can happen from my state machine is if the DMA _RDY and DMA _WM flags are incorrect directly after a buffer is commited to USB. So, are there any conditions under which the RDY or WM flags are incorrect or invalid?

Pete

By any chance are your USB transfers high-bandwidth isochronous? 

Hi Steve, my'n are all bulk transfers and actually on some more work today the problem doesn't seem to be as bad, it just seems that the WM flag is not ready directly after starting my GPIF waveform which seems to be solved by inserting a dummy state that repeats 30 times?! I'd still like to understand all of the conditions that these flags might not be valid as I can see this problem rearing its head in the future.