artvvb

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

The voltage provided by a microphone tends to be quite low. You could potentially amplify the signal before it reaches the I2S2, multiply it up in the FPGA (resulting in a poor quality signal, since you are only effectively using the lowest couple of bits), or try out your project with a cable connected to a computer's audio out. I'd recommend the latter if you happen to have a 3.5mm-3.5mm cable lying around. Getting a bunch of samples dumped into block RAM and then potentially out over UART or into the ILA in a burst could be a good way of looking at more than just one sample at a time. Could potentially also wire something up to look for the minimum and maximum values received in the incoming data. Thanks, Arthur

@Jan Kager It looks like the constraints for the top and bottom row of the Pmod port are swapped. I don't have a Pmod I2S2 to test with at the moment, but was able to get the transceiver core running with your constraints and a Pmod I2S (which uses the same CS4344 chip used in the I2S2's line-out) connected to the bottom row of port JA. I've attached the Verilog module I used to generate the audio output data for testing, as well as a screenshot of the block design. Please also check that your MST/SLV jumper is in the SLV position, since the transceiver core generates the clocks for the line-in chip, rather than taking them as input. Thanks, Arthur module audio_test_pattern( input clk, // 11.29 MHz mclk input lrck_in, // 44.1 kHz lrck output [23:0] count_out ); reg store; wire enable; always@(posedge clk) begin store <= lrck_in; end assign enable = store & ~lrck_in; reg [23:0] count = 0; assign count_out = count; always@(posedge clk) begin if (enable) begin count <= count + 24'd100000; // the counter rolls over at ~262 Hz end end endmodule

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 @rmccormack1, There's an not-yet-fully-released version of the board files that helps to fix it available here: https://github.com/Digilent/vivado-boards/archive/refs/heads/Microblaze-MIG.zip The solution is to reconfigure the MIG to accept a 100 MHz system clock (avoiding the upstream clocking wizard entirely, and just connecting the system clock to the 100 MHz clock pin) and produce it's own reference clock. This also entails constraining the sys_clk_i port in an XDC and, in the case of the USB104, either tying off the sys_reset or connecting it to a button through an inverter manually. I've attached a working Vivado 2020.1 project. Thanks, Arthur USB104A7-MIG.xpr.zip

Hi @Joe_01 I've attached ZIP files with 2020.2 projects for the baremetal demos for the Zmod ADC and Zmod DAC, and the vivado project supporting both of them. Note, I have not tested this in hardware. You can also take a look at an updated version of the IPI getting started guide written for 2020.1 (there should be only minimal differences): https://reference.digilentinc.com/programmable-logic/guides/getting-started-with-ipi Thanks, Arthur vitis_export_archive.ide.zip hw.xpr.zip

Hi Dave, The board files lock in the some of the IP settings. The number of slaves can't be changed when using the board files to constrain the SPI bus, since the board.xml interface and the part0_pins.xml constraints only specify a single chip select pin. I'd recommend using Make External on the relevant pins of the AXI Quad SPI's SPI port, and constraining them all yourself. For what its worth, it looks like clearing the interface selection to Custom in the IP's Board tab will preserve all of the other settings. It may also be necessary to manually add IO buffers into the design (probably in an RTL module between the AXI SPI core and the block design ports) as I'm not positive if Vivado will automatically insert the right buffers for the single tristate, multiple i/o pin pattern of the SS bus. Alternatively, if wasting resources isn't an issue, you could just add a second AXI SPI controller. -Arthur

Hi @davec I don't see anything wrong with your hardware design or the board files. So I spun up a similar design with port J6, working from the polled_example (Vivado/Vitis 2020.1 and version 4.6 of the xspi drivers). Debugging the modifications showed a problem where XSpi_Transfer was silently failing when checking if a slave was selected in the driver, and finding none. Make sure you are calling XSpi_SetSlaveSelect. See my main.c, below. #include "xspi.h" #include "xparameters.h" #include "xil_printf.h" #include "sleep.h" int main() { xil_printf("Hello World!\r\n"); XSpi device; XSpi_Config *pcfg; pcfg = XSpi_LookupConfig(XPAR_AXI_QUAD_SPI_0_DEVICE_ID); XSpi_CfgInitialize(&device, pcfg, pcfg->BaseAddress); XSpi_SetOptions(&device, XSP_MASTER_OPTION); XSpi_Start(&device); XSpi_IntrGlobalDisable(&device); XSpi_SetSlaveSelect(&device, 0b1); u8 bytes [4] = {0xDE,0xAD,0xBE,0xEF}; while (1) { XSpi_Transfer(&device, bytes, NULL, 4); usleep(1); } } Hope this helps, Arthur

Welcome to the forum! Those clocks should be fine. As mic hardware and line hardware are different, an amplifier is required. This why computers use two ports. The converter you linked only splits the cable, and does not appear to do any kind of amplification. Mic to line amplifiers are available for purchase online, but I do not have any specific ones to recommend. -Arthur