Program stuck at DMA config

[vgokhale]

I am using the AXI4 Stream to test the simple loopback. However, it never returns from XAxiDma_CfgInitialize. If it came back with an error, I could do something about it. Without that, I'm stuck without any clues. I set a lower DMA frequency because I read somewhere that it might help - didn't work. I'm using the ZC706.

[bwiec]

If you step into the XAxiDma_CfgInitialize function with the debugger, where inside that function does it get stuck?

[vgokhale]

XAxiDma_CfgInitialize calls XAxi_Dma_Reset which then calls XAxiDma_WriteReg.

This last call, when I step again, instead takes the program to Xil_Out16 which is a function defined inside of xil_io.c. 

Another step crashes the program with the error - 

Error while handling inferior event:

Remote failure reply: E01

Remote failre reply: E01.

Any suggestions?

[vgokhale]

Okay so it goes into Xil_Out32 because XAxiDma_WriteReg calls XAxiDma_Out32 which is #def'd as Xil_Out32. I am not sure why it crashes there though.

[vgokhale]

Okay this is even weird. The insrtuction pointer is stuck INSIDE of a commented block. As you can see, the breakpoint is inside Xil_Out32 but the current pointer location is indicated about 8 lines above that inside of that comments block. What gives?

[mrelko]

I am having the exact same issue.  I even had the weird breakpoint thing like you show in your post above.

http://forums.xilinx.com/t5/Embedded-Processors-and/ZC702-Cannot-write-to-AXI-TIMER-Registers/td-p/332199  

[laursand]

I have the exact same problem - system hangs when writing to the AXI Lite DMA port (DMA reset instruction inside AXAIDMA_CfgInitialize). Did you find what the issue was?

thank you

[laursand]

To add to my previous comment. It looks like on step by step debugging, the system will hang. However, when running from QSPI booting for example, it doesn't hang.
Running non-debug loaded via JTAG also hangs.
I am using Zedboard and 2013.2.
Thanks

[mrelko]

Iaursand,

The solution for me was that Vivado was exporting the .bit file to a folder called hw, instead of hw_platform_0 which is where I thought it was putting it.  Needless to say, I was programming the .bit file from the hw_platform_0 folder which was never getting updated.  This was caising the hardware to get confused.

Bottom line: It is somthing with the .bit file, its either not configured correctly, or the .bit file is not being programmed.

Hope this helps,

Michael

[laursand]

thanks Michael - helpful advice.

I had this issue on and off. I also think it was a discrepancy between the .bit file and what the SDK debugger was expecting... 

Somehow, I think the hanging is due to the AXI (in my case the DMA config port is via GP1) communication hanging between the DMA module and the PS. Even if adresses are the same between bitstream, the routing being maybe different creates this problem... not sure...

But anyways yes it looks like it's resolved when ensuring compatibility between .bit file and whatever SDK is using as a hardware reference,

Thanks..

[mengfanyin]

I encountered a  problem similarly.When using the function of XGpio_SetDataDirection(&GPIOInstance_Ptr,1,1) to set the direction   axi_gpio_0, I find that  it can not return. atfer debugged it  ,the error  appeared on the code as follow

void Xil_Out32(u32 OutAddress, u32 Value)
{
*(volatile u32 *) OutAddress = Value;
}

Remote failure reply: E01

At last , I found that   in Run Configurations,On the lable 0f Reset Type ,the value  is Reset Entire system.afetr changing the value to Reset the processor only,the problem disappered.

[elbrujo]

I have the same problem when using the function XGpio_SetrDataDirection(&GPIOInstance_Ptr,1,1), I debugged and found that is notreturning at the same point as you, even I changed Reset Type to Reset the processor only but it didnt work.

I also tried by using the .bt file exported to the hw folder istead of system_7.... folder

If any body knows how to solve this please let me know how to do it

[bwiec]

I'd probe the interface with an ILA to see if transactions are completing successfully with proper responses.

[aniketpatil]

Hi, I am facing the same problem and my design is also exactly same loopback design. ( Link from where I have taken design : http://www.fpgadeveloper.com/2014/08/using-the-axi-dma-in-vivado.html)

I have seen other forums but my error is not solved.

Debugger stucks at XAxiDma_CfgInitialize. I am not able to even step into this function.

( SDK version that i am using is Release Version: 2016.2 ) 

Can someone please help to rectify this issue.

Thanks

[muzaffer]

please don't post to 2 year old threads. Create a new one for yourself with enough info to debug the problem.

[bhatti25]

Hi, I am also facing the same issue. Have you found any solution so far? Thanks in anticipation. 

[bhatti25]

@aniketpatil Hi, I am also facing the same issue. Have you found any solution so far? Thanks in anticipation. 

[eepro_bt]

The year is 2019.
I hope you all get the problem fixed.
In case someone googled the same problem.
Here is how I fixed the problem.
The Block Design in Vivado Automatically connect axi_dma ip port "mm2s_prmry_reset_out_n" to Processor System Reset port "ext_reset_in", and "peripheral_aresetn" to axi_dma port "axi_resetn", which makes axi_dma repeatedly reset itself, connect the "ext_reset_in" port to zynq ip port "pl_resetn0" will fix the problem.

[airbu]

hi @eepro_bt,

Mine is already connected like they way you described by default. any other idea ?

thanks

[cloukas]

Well, I am having the exact same problem. I first encountered it in a previous design I had, which used 2 reset modules and the reset signal I was using, was connected to the wrong reset module.

This time around though, my design only has a single reset source which is connected the right way. I know because the design was working and giving me results. I had to modify the code in one of the IPs however and when I upgraded the IP and rerun implementation, it gave me the exact same problem.

I have not been able to find a solution yet, but I am almost certain this is a wrong bit file configuration problem and not a design flaw. This is probably a bug.

[cloukas]

UPDATE: I solved the problem by starting the project all over from scratch. The exact same design, no differences whatsoever, run with no problem. Must be some kind of bitstream configuration bug.

[Elgendy]

Sometimeis it can be solved by increasing the Stack size in the "lscript.ld" file.