01-28-2021 05:58 AM - edited 02-01-2021 03:33 AM
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:
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.).
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.
04-26-2021 01:27 AM
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.