eclypse-z7 Eclypse Z7 AXI DMA buffer malloc always returning 0/NULL

[s4fq7]

Hey Digilent,

I've successfully run the low_level_zmod_adc_dac demo on my board with a ADC and DAC ZMOD.

https://reference.digilentinc.com/reference/programmable-logic/eclypse-z7/low_level_zmod_adc_dac

I next decided to run the zmod_dac demo using both petalinux and baremetal.

https://github.com/Digilent/Eclypse-Z7/tree/zmod_dac/master

I was able to program the FPGA and also run the code, however every time it attempts to allocate a buffer to transfer the waveform via AXI DMA malloc is returning a 0/NULL value for the buffer address. If I am correct this means that malloc is unable to obtain memory. I'm running this demo as is directly from your git repo.

The error that occurs due to this 0 buffer address varies, for petalinux it causes a memory violation error when it  tries to copy the waveform to the buffer. For bare metal it copies fine, but then the AXI DMA copy never completes presumably due to the bad 0 address.

Do you have any tips for me on how to get this demo running? If there is any additional information I can provide just let me know.

I did find it curious that fnAllocBuffer takes an "addr" corresponding to the dmaAddr on the zmod but then doesn't use it for anything, could that be related?

Thanks!

void* fnAllocBuffer(uintptr_t addr, size_t size) {

	uint32_t *buf = (uint32_t *)malloc(size);

	return buf;
}

 

[Ciprian]

Hi @s4fq7,

Glad to hear it was fixed. Embedded Linux is a complex thing, eventually we would have gotten to this point but it would have taken a couple of back and forward messages. Have fun with the Eclypse and the environment, it can be a powerful tool.

-Ciprian

[s4fq7]

Hey Digilent, I'm pretty sure this DAC sample is broken for the Eclypse Z7.

I spent afew more hours today looking into it and it seems like the DMA device for the DAC is returning that it only has RX channels meanwhile the code is saying it needs a TX channel. Is there some chance you guys have the wrong FPGA hardware image in the repo as that is the one I'm using to program?

https://github.com/Digilent/Eclypse-Z7-SW/blob/00ad914cdf8d7691d352803334ede168103963e9/design_1_wrapper_hw_platform_0/design_1_wrapper.bit

Either that or perhaps your petalinux release distribution has the hardware dma addresses and zmod addresses wrong?

I'm using the V0.2 files for the sdcard image and the sysroot from https://github.com/Digilent/Eclypse-Z7/releases

I've attached an image of the directory listing for sys/firmware/devicetree/base/amba_pl/

I've attached another 3 images showing what I mean in the Xilinx SDK.

I'de be curious to know has anyone run either the baremetal or petalinux versions of the DAC demo projects?

The documentation on the SW repo site https://github.com/Digilent/Eclypse-Z7-SW/tree/00ad914cdf8d7691d352803334ede168103963e9

Says "This is a branch of the Eclypse Z7 board containing the SDK workspace with the Zmod DAC 1411 set in Zmod connector B."

My system is configured with the Zmod ADC in Zmod connector A and the Zmod DAC in Zmod connector B.

Perhaps the hardware bitstream in the repo was built with the Zmod in A?

I'm very new to working with FPGA's so I appologize if I'm doing something wrong, but given all the files I'm using are from SW repo I would have expected this to work. Even the baremetal variant of the project doesn't appear to work which shouldn't depend on the petalinux file system at all if I understand correctly.

Any help would be appreciated.

 

 

[s4fq7]

One last datapoint I wanted to include from the top of the main.cpp shows that the DAC_DMA_BASE_ADDR is defined as 0x40400000, looking at the image of the directory from my last comment and given the fact this is supposed to be the Zmod B connector this seems odd to me. I would have expected it to be the second DMA address of 40410000... Just mentioning it incase this is the cause.

 

#define TRANSFER_LEN	0x400
#define IIC_BASE_ADDR   0xE0005000
#define ZMOD_IRQ 		61

#define DAC_BASE_ADDR 		0x43C00000
#define DAC_DMA_BASE_ADDR 	0x40400000
#define DAC_FLASH_ADDR   	0x31
#define DAC_DMA_IRQ 		61

Changing DAC_DMA_BASE_ADDR to 0x40410000 allows the code to get further, but it is now failing when it gets to "startDMATransfer(buffer);" and inside it "rc = ioctl(dev->fd, axidma_cmd, &trans);" the board crashes with a "Segmentation Violation". As such I don't think changing the DAC_DMA_BASE_ADD to 40410000 was the correct thing to do.

Last Update:

Bare Metal: Fails due waiting for DMA transfer to complete from buffer with what appears to be an invalid memory address of "0" due to malloc returning "0"

Peta Linux: Fails due to what appears to be a configuration or compatability issue associated with the petalinux image V0.2 where the code thinks the DAC DMA device has one rx channel and no tx channels (see above images)

Looking forward to your reply..

[s4fq7]

Next update:

 

I've gotten further with the petalinux version by using the version of the hardware and SW supplied by https://github.com/Digilent/Eclypse-Z7-SW/tree/zmod_adc_dac/master

It seems the latest version under zmod_dac has incompatible HW and SW (https://github.com/Digilent/Eclypse-Z7-SW/tree/zmod_dac/master)

Using the code under zmod_adc_dac I still can't get the petalinux or baremetal versions to work I'll detail the errors below.

petalinux: Recieves what appears to be a valid non 0/NULL DMA address but for whatever reason the set waevform never triggers the DMA complete interrupt so it hangs there.

baremetal: Recieves a 0/NULL address from "buf = dacZmod.allocChannelsBuffer(length);" which later causes the dma transfer to never complete too.

Hopefully someone can direct me to a simple HW and software that works just so I have a starting place to proceed to make my customizations...

 

I also tried the ADC example on petalinux and it gets stuck waiting indefinitely on the DMA transfer indefinitely. It got a valid DMA buffer when run under petalinux (I didn't try baremetal). I've attached a screenshot of this below. Given I'm using the latest hardware and software (workspaces and projects) and using your recommended 2019.1 version for both Vivado and the SDK any idea why all the projects are failing on DMA? (the hardware appears to work when I run the low_level_zmod_adc_dac branch without the Zynq CPU.

[s4fq7]

I filed an issue on github for this post

https://github.com/Digilent/Eclypse-Z7-SW/issues/1

[Ciprian]

Hi @s4fq7,

I'm looking in to it, will try to get back to you ASAP.

-Ciprian

[s4fq7]

Update: I was able to get the baremetal version of the code to work, if I removed the sd card from the EclypseZ7, repowered it and then repeated the manual fpga programming before launching the code. I'm not sure why I needed to remove the sd card in addition to reprogramming the fpga as I had already tried reprogramming the fpga and making sure that if it did use the bit file on the sdcard boot it would use the adc_dac file. I'm guessing some how petalinux was overriding the fpga image I was flashing from xilinx sdk before I could start the code. (seems unlikely though). Also I was able to confirm that the working code does actually have a buffer address of 0 when run in baremetal mode.

I still can't get the petalinux version to work though which is what I want to hopefully use. Any help for digilent in this regard would be great. So far it seems that the following are true for my case.

1. the adc_dac file included with the V0.2 image doesn't seem to work with the petalinux code in the SW repo.
2. If I remove the petalinux sdcard and program the fpga from xilinx sdk manually I can get the bare metal demo the work with
   1. the bit file in the SW repo folder design_1_wrapper_hw_platform_0
   2. my own custom built bit file based on the latest HW repo

So it seems like most likely the issue is with the V0.2 release image just not being compatible.

I guess my final request if possible would be if someone from Digilent has time could they please test they can get the petalinux SD card release image https://github.com/Digilent/Eclypse-Z7/releases to work with the linux DAC software demo? https://github.com/Digilent/Eclypse-Z7-SW/tree/zmod_adc_dac/master/ZmodDAC1411_Demo_Linux

 

I've tried rebuilding petalinux by following the directions on https://reference.digilentinc.com/reference/programmable-logic/eclypse-z7/customizing-zmods-os

As well as the instructions at https://github.com/Digilent/Eclypse-Z7-OS/tree/zmod_adc_dac/master

I tried both building an image based on the V0.2 release image (replacing the files in the boot partition as instructed) and it didn't work (possibly due to me lacking the knowledge about how to get my bit image to load to the fpga automatically, even though I also tried programming from Xilinx SDK manually after too).

I also tried building an image based on initramfs (to try to eliminate the possibility the issue was related to some files in the rootfs of the release image that were causing issues). I was unable to get this working (due to my own lack of knowledge though)

It would be great if I could get your release image SD card to work as it would give me a working starting ground.

For now though I will start work on my hardware design using baremetal until I hear back from you.

I'm renaming this forum post to "Eclypse Z7 petalinux sd card release V0.2 seems incompatible with linux zmod_adc_dac SW demo" as I believe it's a more appropriate title.

 

Edit: I can't rename the title as I wanted (so I'll just rename the github ticket instead :) Thanks for helping to look into my issue Ciprian I apologize for any confusion my earlier comments may have caused.

 

[s4fq7]

Now that I know to run the baremetal demo's without an sdcard in the board I was able to get the zmod_dac demo to work as well in baremetal mode. However I couldn't use the hardware file that was in the SW repo for some reason I needed to rebuild the hardware from the HW repo. I'm guessing maybe that hardware image in the SW repo only works for the zmod_adc_dac demo for some reason. So the only thing left for me is figuring out how to get petalinux to work either using your release image or a custom built petalinux image.

[Ciprian]

Please send the boot log for the petalinux boot. Also what configuration are you using (adc_dac, adc,dac) to boot in to the system?

-Ciprian

P.S. you can leave the SD inside of the tray as long as you move the jumper from SD to JTAG if you want to use bare-metal mode. Otherwise the boot sequence will go trough the SD and JTAG gets overwritten.

[s4fq7]

Hey Ciprian,

Thanks so much for looking into this. I have some good news. I had been fiddling with my sdcard to try and get things working so I decided to re-flash it.

After reflashing with the V0.2 release image again and checking the uEnv.txt file I was able to get things working.

I tested both the zmod_adc_dac mode and zmod_dac mode and both appeared to work fine.

I'm really not sure what went wrong during my original testing. I can only thing that somehow I may have done something to damage the initial state of the sd card OR damage the state of the SW Xilinx SDK project such that the hardware didn't match the software.

I'm going to try the process of rebuilding the HW config and then building the OS files and finally running the SW code again using my custom image.

It may take me a day or two to go through the whole process again and see where I went wrong the first time.

Since it was obviously user error I'm going to close the github ticket. I'de appreciate if I could leave this thread open for afew more days incase I run into issues getting my custom built petalinux boot image to work.

Thanks again and sorry for putting you through re-testing things.

[s4fq7]

Thanks Ciprian,

I got my environment working. Afew interesting things I noticed were that the BRAM being allocated for the dac demo appears to use a kBufferSize of 14 which equates to 16384 samples. Each of 32 bits. This roughly corresponds to the BRAM usage one sees when one builds the project. The SW also has a limit of 3FFF for the maximum waveform length. However in my cause sending any waveform longer than FFF resulting in any samples after FFF being set to 0. In my case I was able to track down the issue to the axi_dma_1 controller it has a "Width of Buffer Length Register" of 14 bits. Since the actual data being sent was 14 samples of 32 bits, in order to use the full 3FFF samples I needed to change "Width of Buffer Length Register" to 16 bits. I didn't test it but I think this could be done in your tcl script.

   set axi_dma_1 [ create_bd_cell -type ip -vlnv xilinx.com:ip:axi_dma:7.1 axi_dma_1 ]
   set_property -dict [ list \
    CONFIG.c_include_mm2s {1} \
    CONFIG.c_include_s2mm {0} \
    CONFIG.c_include_sg {0} \
    CONFIG.c_sg_include_stscntrl_strm {0} \
+   CONFIG.c_sg_length_width {16} \
  ] $axi_dma_1

Also I ran into some strange issue where the length allocated for the waveform would exceed the length of values actually populated. This is likely due to float precision causing rounding down such that it never fully populated the sample buffer. Meaning between each section of waveform it would spit out afew 0V. I realize this is demo sample code though, just mentioning it as the fix I did was simple enough I just changed the initial length computation.

		length = 0;
		for(val = -amplitude; val < amplitude; val += step)
		{
			length++;
		}
		for(val = amplitude; val > -amplitude; val -= step)
		{
			length++;
		}
//		length = (size_t)(amplitude/step) << 2;

Thanks again for everything I will accept your answer so that it is closed. :)