cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jvzynq
Visitor
Visitor
392 Views
Registered: ‎01-28-2021

AXI-DMA transactions fail

Hello,

I have been working on a project on a Zynq-7020 for more than 4 years and everything has been working as expected. I have been using Vivado 2017.2. Now, I upgraded to version 2019.2 and DMA stopped working (sometimes), I elaborate:

I have a PL design which implies many Xilinx and custom IP cores. One of them is connected to the AXI-DMA through the AXIS interface (and a FIFO is placed between my IP core and the AXI-DMA controller).

From the PS side, I am using both ARMs available in the Zynq-7020:

  • Core 0 runs petalinux, it is the master and I am using this core to communicate with my laptop through a TCP/IP protocol. This core powers up core 1 using "remoteproc".
  • Core 1 runs a baremetal application which controls the DMA transactions (in direct mode). Once a packet is received, the interrupt is asserted and then, another transfer is configured. This process is repeated until the total number of packets is received.

I am using openamp libraries to communicate between both ARMs. The DMA buffer allocation is accomplished with a module called "udmabuf" (available in github, https://github.com/ikwzm/udmabuf). This driver makes sure the buffer is non-cacheable.

Every time I want to share data between PL and PS through S2MM, I divide the stream data in several packets (let's say 80). I made sure the size of the packets I create can be handled by the DMA controller (buffer length is 20 bits and the size of the packets is 147456 bytes). Notice that I am transferring almost 12MB taking into account the 80 packets. The thing is everything works as expected most of the times, DMA can write the 80 packets properly in the DDR memory and I can see the data is correct; however, after a random number of iterations (each iteration launches the 80 packets of the DMA), the DMA stops working, its input tready port asserts 0, and DMA shows error. The packet at which it fails is not always the same, either.


I've had no issues with version 2017.2 (over 4 years, it has made millions of transactions). The code is the same (except some lines that I needed to update due to the lack of "rpmsg-user-module" in petalinux 2019.2, and the files that are automatically created when openamp echo-test is opened in Vitis, I mean: platform_info.c/h, rsc_table.c/h, etc.).

More info:

  • Of course, the timing constraints are met in the PL design.
  • The AXIS protocol is well designed (it was fully tested in version 2017.2, and it has been debugged with ILA in version 2019.2).

The fact that it fails at a random iteration and at a random packet, makes me think it could be a software (maybe cache) thing. Is anyone having the same issues?

 

Any ideas would be much appreciated.

0 Kudos
2 Replies
dgisselq
Scholar
Scholar
229 Views
Registered: ‎05-21-2015

@jvzynq ,

It's been a while.  Have you discovered the source of your problems at all?

Dan

0 Kudos
jvzynq
Visitor
Visitor
170 Views
Registered: ‎01-28-2021

Hi @dgisselq,

No I could not find the source of the problem. I just increased the width of buffer length register to its maximum (26) and grouped the 80 packets into a single one -> this way, it seems it works. This is just a workaround and it is not the way I would have liked to solve it, so any idea to solve the original problem would be much appreciated.

0 Kudos