mSGDMA response FIFO stucks if receives 256...512 bytes

[Altera_Forum]

I use Quartus II 64-Bit Version 15.02 Build 153 

mSGDMA is used in ST to MM mode http://www.alteraforum.com/forum/attachment.php?attachmentid=11724&stc=1  in the Control register set bits DESCRIPTOR_CONTROL_GO_MASKDESCRIPTOR_CONTROL_ERROR_IRQ_MASK DESCRIPTOR_CONTROL_TRANSFER_COMPLETE_IRQ_MASK DESCRIPTOR_CONTROL_EARLY_DONE_ENABLE_MASK DESCRIPTOR_CONTROL_END_ON_EOP_MASK Transfer length is 8192 1) ST source generate packets 100...248 , bytes with controlled period reset mSGDMA push descriptor ST generates packet read response in FIFO read data OK 1) ST source generate packets 256...512 , bytes with controlled period reset mSGDMA push descriptor ST generates packet response fill level is incremented read response in FIFO - response fill level is not decremented, "response FIFO is empty" is 0 data is correct push descriptor ST generates packet response fill level is incremented read response in FIFO - response fill level is not decremented, "response FIFO is empty" is 0 data is correct mSGDMA receives next portion of data, but response FIFO is stucks  Have anybody thought on solving this trouble?

[Altera_Forum]

Are you using a custom ST source? Can you use signaltap to see if the data is flowing correctly on the streaming interface, respecting the start/stop of packet and ready/valid signals?

[Altera_Forum]

Yes, I'm using custom mSGDMA. 

Below are screenshots of Signal Tap with 52 bytes, 232 bytes, 256 bytes per packet, zoomed to the end of the packet and the beginning of the next one: 52 bytes per packet http://www.alteraforum.com/forum/attachment.php?attachmentid=11732&stc=1  232 bytes per packet http://www.alteraforum.com/forum/attachment.php?attachmentid=11733&stc=1  256 bytes per packet http://www.alteraforum.com/forum/attachment.php?attachmentid=11735&stc=1   i do not see differences of waveforms

[Altera_Forum]

Aren't you monitoring the ready signal in the stream source too?

[Altera_Forum]

If You mean ready signal of Avalon ST, then I've show it on the third diagram. 

Ready on others diagrams are the same, I have not found any differences.

[Altera_Forum]

There is something in fact, it looks like the read signal is low during your start of packet. Looking back at the other figures, I see that valid is also low each time you have a start of packet, making it not recognizes by the stream sink. That could be what makes the DMA behave strangely. Do you know why the valid signal gets low?

[Altera_Forum]

Yes, it is low during every start of packet signal is set. When it was high, mSGDMA did not work. I do not know why it behaves this manner.

[Altera_Forum]

It should be high or the start of packet will be ignored. You should then investigate the reason why the DMA doesn't work with this setting. Be sure to check for the ready signal too, you shouldn't move to the next word as long as it is low. Which readyLatency did you set on your source interface?