artvvb

Manually updating did the trick... thanks.

Hi @Eran Zeavi
Do other demo projects run successfully on your board? I would also confirm that the programming mode select jumper is set to JTAG and power cycling, as it could be related to a project actively running on the board while attempting to program it. Others have reported similar errors with other Zynq boards, and other threads may have useful troubleshooting tips, like here: 
Thanks,
Arthur
 

Apologies, I haven't had a chance to take a look at your project yet, and may not tomorrow either.
This is interesting, I would expect to see some kind of "multiply defined" error indicating that the same definition occurs more than once. It's still possible that there could be issues like this that don't generate that specific error though.

Awesome, this was the trick! I also fixed the mask error I introduced. The DMA buffer length register was set to 16 I changed it to 17.
I can now collect 320 us.  

I'll let you know what the maximum capture time ends up being. Thanks so much! ⭐ ⭐ ⭐ ⭐

Hi @Manik Dautta
I believe you need to update WaveForms and WaveForms SDK. Installers can be found via the WaveForms resource center - http://reference.digilentinc.com/software/waveforms/waveforms-3/start. The AD3 is supported by 3.20.1 and higher (3.21.3 is most recent). We've also updated the compatibility list for SDK on the reference site and appreciate the feedback - it had been missed during the launch of the AD3.
Thanks,
Arthur

The mask here represents pulling out one of two 14-bit values packed into a 32-bit word, so it should stay 3FFF.
For the DMA, please confirm the width of buffer length register setting is large enough, it's an IP setting in the block design.
I'm not sure where else to look, it looks like the window position register width in the AXI controller is also controlled by kBufferSize in the VHDL source, and the corresponding definition in the C++ sources defines it as up to 26 bits wide: https://github.com/Digilent/zmodlib/blob/f2f491971aa43fa23d3d2a1d6640d6f97ad69318/ZmodADC1410/zmodadc1410.h#L49C9-L49C40. Same for the S2MM length register width in software: https://github.com/Digilent/zmodlib/blob/f2f491971aa43fa23d3d2a1d6640d6f97ad69318/Zmod/zmod.h#L46C9-L46C45.
I would also consider adding an ILA to the design (if possible, it also requires BRAM...), to take a look at the AXI stream signals going into the DMA.
Thanks,
Arthur

Thank you. I suspected this to be the answer and have already got a respberry pi i'm trying to spin up. This link helps. I appreciate it.

Hi DGISTKSJ,
No, the MIG cannot be used to interface with DDR on the Eclypse, as the DDR is connected to the Zynq PS. However, you ought to be able to access DDR memory through the Zynq PS's AXI slave ports, which can be enabled in the PS configuration, as below. It isn't trivial to implement a custom full AXI master interface to control these ports, so we would normally recommend using IP like Xilinx's AXI DMA.
Thanks,
Arthur

Hi @Bobsaito
The Pmod specification is pretty loose about what can be defined as a GPIO Pmod. If something supports the defined electrical specifications, it's likely fine.
Thanks,
Arthur

Wow, I totally missed this when looking at UG480.  in my design XADC is instantiated on the PL side but I was using the XAdcPs drivers (I should have suspected something with the 'Ps' in the name).  As always, your help greatly appreciated.  I'll review the SysMon v7.8 and go that route since that makes more sense with my design.
 
 

Hello @MCOATS1.
Instead of searching for capacitor,...

 
Click on the resistor icon in the component toolbar to view the Capacitor component.

 
Does that help?
Regards,
Fausto

Another potential way to fix the issues would be to make sure that your source code uses the same instance of the XScuGic handler as the zmodlib sources. In zmodlib, this is declared in zmodlib/Zmod/zmod.cpp and is externed into other files where it's relevant. Options are to either modify the zmodlib sources so you can pass in a handler to an instance that you declare in code outside of zmodlib, or use the API defined in intc.h when setting up handlers for the ethernet and timer sources. I'm not sure of the details of either option.
@Xband I realized you weren't necessarily just asking about the base addresses. Register offsets that specify where a particular register is located relative to a base address are commonly defined in both peripheral drivers and in IP documentation. The section of the AXI DMA user guide I linked in the previous comment is an example of the latter. As an example of where you might find register offsets in drivers, xaxidma_hw.h (found in BSP sources or by clicking through various other AXI DMA driver files) includes them for the DMA core. That receive status register offset is defined by the two following lines:
#define XAXIDMA_RX_OFFSET 0x00000030 /**< RX channel registers base * offset */ #define XAXIDMA_SR_OFFSET 0x00000004 /**< Status */  

Regarding the approach of commenting out the interrupt functionality, as an experiment, I cloned a fresh instance of the Zmod Scope baremetal demo (here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope), and ran it in 2019.1 with and without the contents of the interrupt initialization functions. It worked fine with the interrupt functions, but when the sources were commented out, there was no response. Debugging the demo, it seems that the DMA API doesn't expose the polled version of the fnIsDMATransferComplete function, and the system stalls while waiting for data to be transferred from PL.
To fix this, I added the second line below to zmodlib/Zmod/dma.h:
uint8_t fnIsDMATransferComplete(uintptr_t addr); uint8_t fnIsDMATransferCompletePoll(uintptr_t addr); Modified the following line in zmodlib/ZmodADC1410/zmodadc1410.cpp's ZMODADC1410::acquirePolling function:
// Wait for DMA to Complete transfer while(!isDMATransferCompletePoll()) {} And added the following function to zmodlib/Zmod/zmod.cpp and the corresponding header:
/** * Check if the DMA transfer previously started has completed. * * @return true if the DMA transfer completed, false if it is still running */ bool ZMOD::isDMATransferCompletePoll() { return fnIsDMATransferCompletePoll(dmaAddr); } The zmodlib/Zmod/zmod.h header:
bool isDMATransferComplete(); bool isDMATransferCompletePoll(); I also needed to adjust the fnIsDMATransferCompletePoll function in zmodlib/Zmod/baremetal/dma.c as follows, since the status register for PL->PS transfer is at address 0x34 instead of 4 (https://docs.amd.com/r/en-US/pg021_axi_dma/S2MM_DMASR-S2MM-DMA-Status-Register-Offset-34h):
uint8_t fnIsDMATransferCompletePoll(uintptr_t addr) { DMAEnv *dmaEnv = (DMAEnv *)addr; if (!dmaEnv) return 0; uint32_t offset = (dmaEnv->direction == DMA_DIRECTION_RX) ? 0x34 : 0x04; uint8_t val = readDMAReg(dmaEnv->base_addr, offset); return (val & 2); }  

Hey, sorry for the delay.
Unfortunately, whenever I've seen invalid xpfm files, I've needed to recreate a workspace... Speculating, but it's possible that copying or moving a workspace directory from one place on your system to another could cause it.
It's great that the hardware project is working!
Thanks,
Arthur

Mamatchai, I'll need a bit of time to reproduce and double-check whether there are other important interrupts.
Addresses for PL IP are different per project, they're assigned in the address editor in Vivado. You can either let Vivado automatically assign them (the default behavior) or manually set them. Either way, the address map is exported with the XSA file after generating a bitstream, along with various additional information about the hardware design (this is also how IP configuration information makes its way into the files used by *_LookupConfig functions). Including the xparameters file in your code and using the macros it defines is recommended in case the peripheral addresses are changed in Vivado.

Mamatchai, I'll need a bit of time to reproduce and double-check whether there are other important interrupts.
Addresses for PL IP are different per project, they're assigned in the address editor in Vivado. You can either let Vivado automatically assign them (the default behavior) or manually set them. Either way, the address map is exported with the XSA file after generating a bitstream, along with various additional information about the hardware design (this is also how IP configuration information makes its way into the files used by *_LookupConfig functions). Including the xparameters file in your code and using the macros it defines is recommended in case the peripheral addresses are changed in Vivado.

ZMODADC1410_REG_ADDR_TRIG is an offset - there should be a corresponding BASEADDR (base address) macro in the "xparameters.h" file, add the offset to the base address, rather than just using the offset. In the screenshot in my previous comment, you can see the addresses are coming from "XPAR_AXI_DMA_0_BASEADDR + * + XAXIDMA_*_OFFSET". Ignore the middle value, it's specific to the DMA IP and doesn't apply to the Zmod ADC controller. You should have something like "XPAR_(Zmod ADC controller name)_BASEADDR + ZMODADC1410_REG_ADDR_TRIG".
I apologize if that's not super clear - if you have the Vivado project, you can also see where base addresses are assigned for different peripherals in the Address Editor, something like this is usually in the 0x40000000+ range (that DMA core in the screenshot is at address 0x40400000). You can also get this info in the hardware platform SPR file, though the xparameters.h header is where to get it for the code itself.

I believe that to get the updated bitstream into BOOT.bin, you need to clone the petalinux project, use petalinux-config to swap out the HDF file with a new export from your project, then rebuild and repackage the project.

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

@artvvb, 
Moving that definition fixed it on my side too, thanks for a small win here and great instructions getting through the process.  I found this quite valuable as a training intro to the ILA process.  Cant say I would have successfully debugged and found the problem but its a good step in the process!
Glossed over the bit about triggering the acquisition twice and seeing the difference in the buffer.  My success was getting all of your steps to line up and work.  Spent 2 days messing around after trying to address a buffer overflow diagnosis from the AMD help site, finally restored the settings and things worked after rebooting the machine.  This platform seems to have an infinite number of issues to deal with.  
 
Thanks again for the help!

@artvvb, 
thanks for putting this together.  I'll need some time to absorb all that is going on, its a great tutorial.   

Running through the debugging process:
Using a 20-word (80-byte) transfer for the sake of being able to see things on screen. Below is the input stream going into the DMA. You can see that it counts from 0 to 19, and on that 19 (the 20th word), tlast is asserted. If an issue with the counter module was causing the first two words to be corrupted, I'd expect to see it here, but everything looks as expected. - If the DMA worked perfectly, but the counter provided data to it that didn't match what I expected, then the data seen in software would also be wrong, not the case here, since we see the expected 0, 1, 2, 3, ...

Below is the output of the DMA, the AXI master interface that writes to DDR. The DMA takes the input stream, breaks it up into bursts, and sends data to DDR by first writing an address and then the data - here you can see the first ten bytes are transferred in one burst, starting with address 0x2062d8. After the DMA transfer is complete, the processor will be able to access that memory and see the new data. Again, if there was an issue with the DMA or the counter, I'd expect to see it here, potentially by seeing a value other than 0 or 1 on the WDATA bus at the start of the transfer.

Now in the Vitis debugger, this is where we can actually see the bug. I can look at the data in DDR after the transfer by setting a breakpoint after the Xil_DCacheInvalidateRange call, and using the "Memory" view to monitor the address that the buffer is pointing at. In this case, I have two breakpoints set. One at the start of the do_transfer function, so that I can check the buffer address in the "Variables" view. I take that buffer address and add it to the memory view, which shows me that the data is set up as expected - in the code pictured, I'm zeroing everything other than the first word to make sure that the expected value after DMA is different from the known value before the transfer.

Hitting continue to go to the next breakpoint, we can see that everything except for the first two words is updated correctly - the red delta indicates that there's a difference in the value at that memory address since the last time the processor was halted:

This is then checked by the program and the pass/fail is printed to console, in this case a fail since the first two words don't match the expectation.

So, the issue doesn't seem to be with the hardware, at least up to the DMA output. Either the first two words aren't being written by the DMA transfer at all, or they are overwritten behind the scenes after the transfer is completed (overwritten specifically back to the original state).
Moving the buffer declaration out of the do_transfer function so that it's a global variable seems to consistently fix it (it puts the buffer at a different place in memory). That said, I'm still not sure what exactly is going on. I tried increasing both the stack and heap sizes in lscript.ld to 0x200000, which didn't help. I also tried checking the "allow unaligned transfers" box in the DMA settings, since alignment can also matter, which also didn't help.

Hopefully my thought process is relatively clear.

Ugh, I'm really sorry, there's a bug I didn't catch... The hardware design seems to be fine but the second word in the buffer is getting overwritten at some point, possibly due to insufficient memory in the stack/heap, memory alignment, or some pointer issue. Taking a look.
I also likely should have started a new thread when posting the example code, rather than replying into this one.

Hi @artvvb
I followed your instruction and changed the memory size of Microblaze to 128k by adding a new Microblaze IP in Block Design and I got the result that I expected. You can see the picture below.
Thank you very much for helping me do my work ! 
 Bach

No need for any of it - you can simply change the address range in the address editor, and Vivado will figure out the rest by itself:

If you have separate instruction and data buses (like it's shown in the screenshot), you will need to change it in both places.

Hi @Bach
Local memory size is set when you run Block Automation to build out the system around the Microblaze processor in Vivado - you can't change local memory size from Vitis as the amount of BRAM dedicated to it is part of the hardware design. The easiest way to increase it is often to go back to Vivado, strip out Microblaze and many of the core blocks that come with it, add a Microblaze IP back into the design, and rerun Block Automation picking the largest local memory available (likely 64k). If you need more than 64k of memory and your board has DDR, you should use it (again, by modifying the hardware design).
Alternatively, reduce the amount of memory used by your software app - common libraries for C/C++, even stdio, can be too large for a system with very little memory.
Thanks,
Arthur