07-21-2017 02:27 AM
Currently i'm working on AXI DMA Core in loop back on Zynq Ultrascale+ in SG Mode using VIVADO 2016.4 tool, When i tried to run the example file "xaxidma_example_simple_poll.c " on the SDK using system debugger, the process gets stuck at PSU INIT.
Similar design was retargeted to Zed Board and when i tried to run the example file "xaxidma_example_simple_poll.c" on the SDK using Launch on Hardware(GDB), SG Polling Test is passed.
Screen shots of block design and Address editor are shared below.
Zynq Ultrascale+ Block Design and Address Editor
Zed Board Block Design and Address Editor
Any Pointers in resolving this issue would be helpful.
07-27-2017 03:04 PM
I've used axi_dma on zcu102 via 2017.2 without issues.
Make sure the fpga is downloaded and debug config enables PS to PL.
Also verify your PS config. If DDR is configured wrong, psu_init.tcl will wait for DDR init to complete before continuing. I think there are also other loops in psu_init when configuring clk PLLs and waiting for the PLLs to lock.
You could try copy/past the commands from psu_init.tcl into xsdb to find where it gets stuck.
08-28-2017 01:15 PM
Can you provide some details on the DMA parameter settings and PS-PL interface settings? For example: what is your memory map data width? what is your stream data width?
08-29-2017 06:56 AM
dma settings are 128bit axi4 and axis data width.
and the PS slave axi4 interfaces are configured as 128bit data widths.
In my case, I used an axi_crossbar to increase 'read acceptance' to 8 instead of the default value of 2. But you could start off by using an axi_interconnect. This way, the interconnect will automatically insert data width converters if necessary. After validating the IPI BD design, you can expand the axi_interconnect and you can expand the internal couplers. This exercise of expanding the blocks and double clicking axi_interconnect internal blocks helps to uncover clock crossing, and data width differences that you didn't expect.
My address map is as follows:
02-23-2018 06:46 AM
I have also issues with the design presented above running on Vivado 2017.4. When i try to use my exported design in the SDK, i get the warnings:
"CHECK FOR THE VALID DDR ADDRESS IN XPARAMETERS.H"
"There's no DDR_1 in the HW design. MMU translation table marks 32 GB DDR address space as undefined"
If i just ignore them, whithin debugging the app gets stuck. What is the reason for this error? Btw DDR is properly configured in PS. Shouldn't Vivado generate a correct DDR_1 by itsself?
Help is appreciated! Thanks a lot.
02-18-2019 04:43 AM - edited 02-18-2019 04:44 AM
Has anyone managed to solve this problem?
I have checked the other posts but nothing seems to solove the stucking problem.
07-12-2019 06:48 AM
I also have this issue.
I have the "There's no DDR_1 in the HW design. MMU translation table marks 32 GB DDR address space as undefined" warning that someone mentioned above, as well, so I am speculating that it may be related to this.
07-17-2019 10:22 AM
I solved this issue, at least in my instance.
The default DDR configuration was incorrect. I simply had to change the configuration in the Zynq IP Customization from a custom DDR3 configuration to the DDR4 configuration associated with the MICRON RAM on my ZCU111
07-19-2019 12:50 PM
Actually, my previous solution had an error in it. The issue was the DDR configuration, but I needed to fix it by running the "Block Automation Tool" because the ZCU111's PS RAM isn't one of the default presets.