Post Go back to editing

No-Os drivers DAC_DMA Example build problem

I have recently started using ADRV9009 Evaluation board along with ZC706 board (Plan to use with ZCU102 later by month end ).

I created the project cloning the sources from https://github.com/analogdevicesinc/hdl/ for both ZC706 and ZCU102 platforms and even downloaded the source codes from https://github.com/analogdevicesinc/hdl/ created the hw hw_bsp and sw project on XSDK and could compile properly.

Using https://github.com/analogdevicesinc/no-OS/blob/master/projects/adrv9009/src/app/headless.c as example code.

But if I uncomment DAC_DMA_EXAMPLE  from https://github.com/analogdevicesinc/no-OS/blob/master/projects/adrv9009/src/app/app_config.h this file to check the DMA example build fails with error "ad9528_gpio_param undeclared? Did you mean adi_hal_param"  and next error is "storage size of 'gpio_init_plddrbypass' is unknown"

Kindly suggest is I am missing any header or where gpio_init_plddrbypass gets defined?

Thanks in advance

Arun Kumar

Parents
  • Hi Arun,

    Thanks for the feedback, the adrv9009 DMA example was indeed broken by recent changes.

    Please see this pull request, you may use the commit of this pull request to be able to compile and play with the DMA example.

    https://github.com/analogdevicesinc/no-OS/pull/430

    Best regards,

    buha

  • Thank you for the reply.

    Now I am getting

    AD9528 SPI Read Verify failed (0x0)

    error: ad9528_setup() failed with (-1)

    on my console output

    How to solve this issue?

    is there any more changes required at gpio api i.e gpio.c and gpio.h

    Please suggest.

    Regards

    Arun Kumar

  • Please find it below.  

    Hello
    rx_clkgen: MMCM-PLL locked (245760000 Hz)
    tx_clkgen: MMCM-PLL locked (122880000 Hz)
    rx_os_clkgen: MMCM-PLL locked (122880000 Hz)
    rx_adxcvr: OK (9830400 kHz)
    tx_adxcvr: OK (4915200 kHz)
    rx_os_adxcvr: OK (4915200 kHz)
    talise: Device Revision 192, Firmware 6.0.2, API 3.6.0.5
    talise: Calibrations completed successfully
    rx_jesd: Lane 0 desynced (19 errors), restarting link
    rx_jesd: Lane 1 desynced (7 errors), restarting link
    rx_os_jesd: Lane 0 desynced (22 errors), restarting link
    rx_os_jesd: Lane 1 desynced (19 errors), restarting link
    rx_jesd status:
    	Link is enabled
    	Measured Link Clock: 245.764 MHz
    	Reported Link Clock: 245.760 MHz
    	Lane rate: 9830.400 MHz
    	Lane rate / 40: 245.760 MHz
    	Link status: DATA
    	SYSREF captured: Yes
    	SYSREF alignment error: No
    tx_jesd status:
    	Link is enabled
    	Measured Link Clock: 122.882 MHz
    	Reported Link Clock: 122.880 MHz
    	Lane rate: 4915.200 MHz
    	Lane rate / 40: 122.880 MHz
    	SYNC~: deasserted
    	Link status: DATA
    	SYSREF captured: Yes
    	SYSREF alignment error: No
    rx_os_jesd status:
    	Link is enabled
    	Measured Link Clock: 122.882 MHz
    	Reported Link Clock: 122.880 MHz
    	Lane rate: 4915.200 MHz
    	Lane rate / 40: 122.880 MHz
    	Link status: DATA
    	SYSREF captured: Yes
    	SYSREF alignment error: No
    tx_dac: Successfully initialized (245764160 Hz)
    rx_adc: Successfully initialized (245762634 Hz)

    Thanks for your help

  • The log looks good. How do you transfer the captured data to PC?

    Thanks,
    Dragos

  • Just reading from memory and print it out as below. 

    uint32_t *P2StartAdd = DDR_MEM_BASEADDR + 0x800000;
    memcpy(Data2Store_Test, P2StartAdd, (16384 * 8)/4);
    xil_printf("\n\n\n\n ******************** Rx data ******************** \n");
    for(int i=0; i< ((16384 * 8)/4) ; i++)
    {
    	xil_printf(" 0x%08x  ", Data2Store_Test[i]);
    	xil_printf("\n");
    }
     

  • Please note that in memory you should have 16384 samples, but 8 times more bytes since each sample requires 2 bytes and there are 4 channels: I0, Q0, I1, Q1.

    So, first 16 bytes will belong to I0, the next 16 bytes to Q0 and so one.

    Dragos

  • Thanks. I have considered the above fact you mentioned. Sometimes I receive just a noise. 

  • Don't forget to invalidate the cache memory (Xil_DCacheInvalidateRange()) after each DMA transfer to be sure you are reading the data from the actual main memory and not from the cache memory. Make sure the links are in DATA mode too.

    Dragos

  • I will check the cache memory. The problem is that I am receiving data (not a good data off course) once and the next power up I am receiving noise. In the log message it mentioned Link status is Data, I am thinking the link is fine, is that right? 

    Thanks

  • I have tried your suggestion by including Xil_DCacheInvalidateRange() after DMA transfer, still I am reading noise sometimes in several power ups. Please let me know if you have any other ideas. 

    Thanks

  • Can you describe a power up when you are receiving only noise? Is it a power on from a completely powered off state that implies the bitstream programming and software application downloading/running?

    Thanks,
    Dragos

  • SDK program starts headless.c  that contains initialization and setup and then sending data and receiving followed by the final stage that power down the hardware. Is it necessary to power down the hardware? I am thinking something is not right in the DAC_DMA_Example example, either software, configuration or hardware. Because I did not change the program other than printing out the results.

    Thanks

Reply
  • SDK program starts headless.c  that contains initialization and setup and then sending data and receiving followed by the final stage that power down the hardware. Is it necessary to power down the hardware? I am thinking something is not right in the DAC_DMA_Example example, either software, configuration or hardware. Because I did not change the program other than printing out the results.

    Thanks

Children
  • If you don't see the issue on a freshly powered on board (please confirm if this is the case), the issue might be caused by some components that are not properly reset when the software is re-run.

    Dragos

  • I am seeing the issue most of the time, even if I reset the FPGA board. The sine wave I am receiving is also very noisy. I checked the status of Rx/Tx or radio on and any other reasons I thought but I did not find the solution. I tried less lane HDL version still not good, I actually spend a lot of time to make it work, unfortunately was not successful. Please let me know if there is a log or functions I can use for find the issue.

    Thanks

  • I borrowed a zcu102 to try adrv9009, the first time I tried the sine wave example, it worked without any problem. So, I am still thinking there is something not right with the design of zc706. I do appreciate it if you check it for me and let me know. 

    Thanks