artvvb

The ADC IIC base address should also be I2C_1, both Zmods share that MIO I2C:
#define IIC_ADC_BASE_ADDR       XPAR_PS7_I2C_1_BASEADDR  
The heap size should also be increased in the linker script (lscript.ld). 0x4000 should be sufficient, though larger won't hurt (and if you want to use significantly bigger software buffers, it will need to be larger). I'd adjusted this while debugging yesterday prior to correcting the length, in order to see if there was a memory leak or something progressively eating more of the heap on each pass through the DAC demo.
In case it's helpful, I've attached the modified dma.c that I've been using while debugging, which takes advantage of the mallinfo function to track when and how much of the memory in the heap is being allocated and freed.
This produced the following log, which I've annotated with the objects getting allocated and freed. Note that fordblks shows the amount of free memory that can be accessed by the malloc function.
This shows that when the DAC XAxiDma is being allocated, there isn't enough memory left for malloc.
 
The length variable is still an issue (but has now been corrected in the Github sources).
The 14 bit length limit you note is due to the size of the AXI DMA's transfer length register rather than the size of the allocated buffer in DDR. The overflow I'm describing happens solely in software. In the original code, with amplitude 5 and step 2, the following line allocates an 8-word memory space:
length = (size_t)(amplitude/step) << 2; buf = dacZmod.allocChannelsBuffer(length); // (size_t)(5.0 / 2.0) << 2 // = (size_t)(2.5) << 2 // = 2 << 2 // = 8 while each of the for loops count five times.
for(val = -amplitude; val < amplitude; val += step) // expands to -5, -3, -1, 1, 3 for(val = amplitude; val > -amplitude; val -= step) // expands to 5, 3, 1, -1, -3 This can be checked by printing the value of length and the value of i after the for loops.
 
Yesterday, before correcting the length, the mallinfo technique showed the uordblks, fordblks, and keepcost values to be underflowing at some point prior to the failed DMAEnv allocation (which was a different failure point than the xAxiDma), meaning that more memory had been freed than had previously been allocated.
Thanks,
Arthur
dma.c

Hi @Nico89
The Pmod CAN IP encapsulates Xilinx's AXI QSPI IP and AXI GPIO IPs (looks like versions 3.2 and 2.0, respectively, in the latest vivado-library release). Each of it's AXI interfaces connects to these and provides direct access to one of these IP's register spaces. The AXI GPIO is connected to the bottom row of the Pmod connector, to provide software interrupts and the ability to trigger a reset. The Pmod IP is intended to be used through C code and the software drivers provided with the IP - the drivers for the encapsulated Xilinx IP are wrapped by an additional software layer for the CAN.
Hope this helps,
Arthur
 

Hi @rmccormack1,
Can you export your projects to a ZIP file and post it here? Errors that appear as makefile errors like this one may indicate that something in the board support package is failing to build properly, which would imply either a problem with the Vivado project and XSA, or with the configuration of one the software projects. It could be missing stdin, or it could be one of a couple other potential issues not directly related to the posted source code.
Alternatively it might be down to xil_printf.h not being included, though I haven't managed to reproduce your error message.
Thanks,
Arthur
 

Hi Sheraz,
I'm not sure if anyone around here is familiar with that particular I2S IP, as it looks like it was released quite recently. As you might have seen in other threads and on the I2S2's resource center, there are a couple of different I2S demos/examples we've put together over the years - I recommend starting with these instead.
That said, I'll try to provide some general comments on potential issues in getting this IP connected up:
The AXI-stream master interface needs to be connected to something downstream to consume the data - this will be how the audio data exits the receiver. An AXI DMA is a common way of pushing this data into DDR so that the Zynq PS can do stuff with it. Since the I2S IP's stream interface doesn't have a tlast signal, you will need to provide that yourself - probably requiring something along the lines of detecting the start/end of a block based on the values in tdata (but I'm not sure).
The aud_mclk input should be connected to FCLK_CLK1 and to an external port.
The _axis_ clock should likely be connected to FCLK_CLK0 (and the _axi_ctrl_ clock), with the reset getting tied to the AXI control reset.
irq needs to be connected to the Zynq's IRQ_F2P interrupt port, which needs to be enabled in the Zynq configuration.
Thanks,
Arthur
 

Hi @RichardV
Could you clarify what you mean by "the QSPI port"?
You can create your own SPI controller and have it use any of the Cmod's IO pins - constraining the pins with an XDC instead of through the board files. The AXI QSPI IP can similarly be connected to various external pins, on the Pmod port, breadboard connector, pretty much wherever (but should be used with a Microblaze processor). You can configure the AXI QSPI to work in standard SPI mode (SPI Options: Mode = Standard instead of Quad).
Thanks,
Arthur