07-02-2013 05:00 AM
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.
07-02-2013 07:34 AM
07-02-2013 01:25 PM
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.
07-02-2013 01:30 PM
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.
07-02-2013 02:41 PM
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?
07-08-2013 07:08 AM
I am having the exact same issue. I even had the weird breakpoint thing like you show in your post above.
08-09-2013 09:19 PM
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?
08-09-2013 10:32 PM
08-12-2013 05:08 AM
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,
09-13-2013 10:56 AM
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,
04-01-2014 07:13 PM
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.
04-10-2014 03:31 AM
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
04-11-2014 10:49 AM
09-01-2016 06:23 AM
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.
09-04-2016 08:00 PM
01-03-2019 02:20 AM
10-18-2019 10:45 AM - edited 10-18-2019 11:05 AM
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.