12-18-2019 12:41 AM - edited 12-18-2019 12:45 AM
I am working on a project, configuring DMA to read data from a connected IP. However, the Tready of s2mm is always low even after configuring DMA, Flushing and starting. What could be the issue? The block design, output of ILA and the codes can be found below.
unsigned int tmpVal;
tmpVal = Xil_In32(XPAR_AXI_DMA_0_BASEADDR + 0x30); // read from AXI DMA control register
tmpVal |= 0x10001; // modify the read value with setting the run bit and interrupt_on_complete enable bit
Xil_Out32(XPAR_AXI_DMA_0_BASEADDR + 0x30, tmpVal); // write the modified value back to AXI DMA register
tmpVal = Xil_In32(XPAR_AXI_DMA_0_BASEADDR + 0x30); // read the written value
xil_printf("Value of the DMA control register after the configuration: %x\n\r",tmpVal); // print out the value for user verification
void StartDMATransfer(unsigned int dstAddress, unsigned int len)
// write destination address to S2MM_DA register
Xil_Out32(XPAR_AXI_DMA_0_BASEADDR + 0x48, dstAddress);
// write length to the S2MM_LENGTH register, this will start the DMA transfer
Xil_Out32(XPAR_AXI_DMA_0_BASEADDR + 0x58, len);
xil_printf("Calling init_platform ... \n\r");
// initialize AXI DMA unit
xil_printf("Initializing AXI DMA ... \n\r");
xil_printf("Starting DMA transfer ... \n\r");
09-24-2020 07:42 AM
Double check that you aren't allowing stream data into the core before giving it a length, an address, and starting the transfer--otherwise the S2MM core has been known to lock up.
09-26-2020 04:22 AM
Experiencing the exact same problem. Tried gating the valid signal from S2MM to DMA so that the valid signal would never go high before the full setup of the DMA but to no avail. We can see that despite valid going high ready remains low and no setting seems to help. Tried cyclic BD mode to be sure the Descriptor flags did not interfere. Everything seem normal, no errors reported by the DMA. Only thing I can think of is that we did not make a new BSP, could this be a problem? PS-system attached.
09-26-2020 04:26 AM
No data was being sent because without TREADY being active, the send process was on hold.
I found this though:
It seems to have done the trick for my case, and now TREADY is working as it should according to my simple initial test.
09-26-2020 04:31 AM
@tsjorgensen, I applied the patch as mentioned in my previous post, verified the patch was active, as per:
Then rebuilt everything in Vivado, exported the h/w & bitstream, then rebuilt the BSP in the SDK and it worked for me.
09-26-2020 04:40 AM
Thank you. But we are already using Vivado 2019.2 where it says it should be fixed? I'm speculating that maybe it is the rebuild of the BSP that is needed. I've looked through the internal Zynq registers but could not find anything that would prohibit the use of HP1 as DMA port to the DDR-RAM. We already use the HP0 for a Video DMA and that works fine. I've checked through the registers for HP0 and HP1 and they have identical settings. Probably best to try a new BSP. Thanks again.