UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
10,811 Views
Registered: ‎10-25-2011

Program stuck at DMA config

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.

Tags (3)
19 Replies
Xilinx Employee
Xilinx Employee
10,806 Views
Registered: ‎08-02-2011

Re: Program stuck at DMA config

If you step into the XAxiDma_CfgInitialize function with the debugger, where inside that function does it get stuck?
www.xilinx.com
0 Kudos
Explorer
Explorer
10,796 Views
Registered: ‎10-25-2011

Re: Program stuck at DMA config

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?

0 Kudos
Explorer
Explorer
10,795 Views
Registered: ‎10-25-2011

Re: Program stuck at DMA config

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.

0 Kudos
Explorer
Explorer
10,786 Views
Registered: ‎10-25-2011

Re: Program stuck at DMA config

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?

Screen Shot 2013-07-02 at 5.39.26 PM.png
0 Kudos
Adventurer
Adventurer
10,750 Views
Registered: ‎05-10-2013

Re: Program stuck at DMA config

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  

0 Kudos
Contributor
Contributor
10,635 Views
Registered: ‎08-09-2013

Re: Program stuck at DMA config

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

0 Kudos
Contributor
Contributor
10,630 Views
Registered: ‎08-09-2013

Re: Program stuck at DMA config

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
0 Kudos
Adventurer
Adventurer
10,612 Views
Registered: ‎05-10-2013

Re: Program stuck at DMA config

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

0 Kudos
Contributor
Contributor
10,537 Views
Registered: ‎08-09-2013

Re: Program stuck at DMA config

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..

 

0 Kudos
Visitor mengfanyin
Visitor
6,107 Views
Registered: ‎04-01-2014

Re: Program stuck at DMA config

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.

 

0 Kudos
Visitor elbrujo
Visitor
6,068 Views
Registered: ‎04-10-2014

Re: Program stuck at DMA config

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

0 Kudos
Xilinx Employee
Xilinx Employee
6,058 Views
Registered: ‎08-02-2011

Re: Program stuck at DMA config

I'd probe the interface with an ILA to see if transactions are completing successfully with proper responses.
www.xilinx.com
0 Kudos
Newbie aniketpatil
Newbie
3,431 Views
Registered: ‎09-01-2016

Re: Program stuck at DMA config

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

0 Kudos
Teacher muzaffer
Teacher
3,418 Views
Registered: ‎03-31-2012

Re: Program stuck at DMA config

please don't post to 2 year old threads. Create a new one for yourself with enough info to debug the problem.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Visitor bhatti25
Visitor
3,200 Views
Registered: ‎09-26-2016

Re: Program stuck at DMA config

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

0 Kudos
Visitor bhatti25
Visitor
3,199 Views
Registered: ‎09-26-2016

Re: Program stuck at DMA config

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

0 Kudos
Highlighted
Visitor eepro_bt
Visitor
920 Views
Registered: ‎08-27-2018

Re: Program stuck at DMA config

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.
0 Kudos
Visitor airbu
Visitor
613 Views
Registered: ‎10-04-2018

Re: Program stuck at DMA config

hi @eepro_bt,

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

thanks

0 Kudos
Visitor cloukas
Visitor
45 Views
Registered: ‎12-16-2018

Re: Program stuck at DMA config

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.

0 Kudos