SGDMA Transfers only 20 bytes

[Altera_Forum]

Hi, 

 I am having an issue using the SGDMA core with a NIOS core and uCOSII. I think the code sets up the descriptor correctly (this to tx a packet out the TSE MAC): the source is the transmit buffer in memory (verified as having the correct data in the buffer), the destination is 0 because it is streaming peripheral, and the bytes_to_transfer is 60 (it is an ARP packet). Checking the descriptor for the actual_bytes_transferred the value is 60. Sometimes the packet is transmitted over Ethernet as expected, but sometimes only the first 20 bytes are transmitted correctly, the other 40 bytes appear to be random data. The tx buffer data is double word (32bit) aligned. Anyone had this type of issue with the SGDMA controller before?  Thank you for any help.

[Altera_Forum]

So if I understand you correctly, the packet size is correct, but the end of the data isn't correct. It could be either because your software begins to overwrite the data before the DMA is finished sending it, or it could be a data cache coherency problem. If your CPU has a data cache, ensure you flush the data buffer before you start the SGDMA. 

Are you using Altera's driver with the Interniche stack, or your own implementation?

[Altera_Forum]

Thank you for the response. To prove the HW is good I used the iNicheStack example which works as expected, no lost packets, pings work, can open a socket. However our application uses the Micrium TCP/IP stack. The driver is provided by Micrium but is heavily based on the Altera version. I'll check through the driver and add code if necessary to check the DMA transfer is complete before writing more data. 

 The problem does suggest a timing/overwrite problem because if I set a breakpoint before just before and just after the DMA registers are written, send the ping, the first breakpoint is hit, then continue to the next breakpoint, and watch what happens with Wireshark, the packet is correct…most for the time. I say most of the time because I have still seen incorrect packets transmitted. The reason I have the two breakpoints here is to observe the DMA registers before and after the transfer, and to see how many bytes where actually transferred, which is always correct. So either the address the DMA controller is reading from changes, or the data where it is reading from changes. I don't think the simple examples that Altera provides have a cache, but I should check.

[Altera_Forum]

I think the standard Nios II designs that Altera provides with their kits does have cache. You can check it in SOPC Builder / QSys, Nios CPU parameters, in the Memory interfaces tab. 

From what you are describing, it looks like a synchronization or cache problem, and I'd say the latter is the most likely.