pyadi-iio, on zedboard+fmcomms4 eval

I wanted to integrate Xilinx PYNQ framework on a Zedboard with an Fmcomms4 (ad9364) radio.  Starting point was as follows:

Ubuntu 16.04 in a Vmware VM (per Petalinux 2018.3 dev docs)

ADI hdl repo, hdl_2019_r1 branch, project/fmcomms2/zed build for zedboard

ADI meta-adi repo, 2019_R1

Vivado 2018.3.1, Petalinux 2018.3

PYNQ v2.6 arm rootfs

Everything boots up fine and behaves like a normal PYNQ environment.

To verify the ad9364(), I loaded ADI libiio and pyadi_iio (both version 0.0.7, 0.0.8) and

wrote a simple script (below).

When I run the script, I get the follow error out of the module, i.e. it seems to attempt to modify some radio attributes that don't exist:

pynq.567> sudo python3
TX 500.000 mhz
TX enabled channels [0]
Traceback (most recent call last):
File "", line 25, in <module>
File "/usr/local/lib/python3.6/dist-packages/adi/", line 394, in tx
File "/usr/local/lib/python3.6/dist-packages/adi/", line 82, in disable_dds
self.dds_enabled = np.zeros(self._num_tx_channels * 2, dtype=bool)
File "/usr/local/lib/python3.6/dist-packages/adi/", line 122, in dds_enabled
self.__update_dds("raw", value)
File "/usr/local/lib/python3.6/dist-packages/adi/", line 58, in __update_dds
chan.attrs[attr].value = str(int(value[indx]))
IndexError: index 4 is out of bounds for axis 0 with size 4

If I instance the radio as sdr.ad9361("local:"), then the script runs as intended, ie I see RF output where it should be on the spectrum analyzer.

My question is if anyone has encountered this issue before, or if I'm missing something in my script.  Of course, could easily be related to

some OS/driver integration with Pyadi.  


import adi, time
import numpy as np


sample_rate = 10e6
freq = 500e6
tx_gain = 50

sdr.sample_rate = int(sample_rate)
sdr.tx_lo = int(freq)
sdr.tx_hardware_gain_chan0 = tx_gain
sdr.tx_enabled_channels = [0]

print("TX {:.3f} mhz".format(sdr.tx_lo/1e6))
print("TX enabled channels {}".format(sdr.tx_enabled_channels))

N = 10000
t = np.arange(N)/sample_rate
samples = 0.5*np.exp(2.0j*np.pi*1000e3*t)
samples *= 2**14
samples = np.round(np.real(samples), 0) + 1j*np.round(np.imag(samples), 0)

sdr.tx_cyclic_buffer = True

Parents Reply
  • 0
    •  Analog Employees 
    on Feb 10, 2021 11:30 PM 2 months ago in reply to rspanbauer

    I don't think this is a pyadi issue, as you should not have 12 channels under cf-ad9361-dds-core-lpc. When pyadi goes to enumerate the DDS channels it will not have enough default values for the DDS settings since FMComms4 should only have 6 TX based channels (2 DMA, 4 DDS).

    What does this return on your board:

    iio_attr -D -u ip:<IP of board> ad9361-phy adi,2rx-2tx-mode-enable


  • The ad9364 is local to the zcu102.  So:

    sudo iio_attr -D -u local: ad9361-phy adi,2rx-2tx-mode-enable


    Also, the 2rx2tx setting isn't in the device tree as per /sys/firmware/devicetree/base/amba/spi@ff040000/ad9361-phy@0/

    Here is a clue --

    On the working zed+fmcomms, bootup msg:


    zed.180> dmesg | fgrep ad936
    [Sat Feb 6 23:19:07 2021] ad9361 spi0.0: ad9361_probe : enter (ad9364)
    [Sat Feb 6 23:19:07 2021] ad9361 spi0.0: ad9361_probe : AD936x Rev 2 successfully initialized
    [Sat Feb 6 23:19:07 2021] cf_axi_dds Analog Devices CF_AXI_DDS_DDS MASTER (9.01.b) at 0x79024000 mapped to 0xe08aa000, probed DDS AD9364
    [Sat Feb 6 23:19:09 2021] cf_axi_adc ADI AIM (10.01.b) at 0x79020000 mapped to 0xe0988000, probed ADC AD9364 as MASTER

    While on the zcu102 system (ADI kernel, device tree from fmcomms4 project):


    root@pynq:/home/xilinx/pyadi-iio/adi# dmesg | fgrep ad936
    [ 1.407019] ad9361 spi1.0: ad9361_probe : enter (ad9364)
    [ 5.098210] ad9361 spi1.0: ad9361_probe : enter (ad9364)
    [ 5.450784] ad9361 spi1.0: ad9361_probe : AD936x Rev 2 successfully initialized
    [ 5.473483] cf_axi_dds Analog Devices CF_AXI_DDS_DDS MASTER (9.00.b) at 0x99024000 mapped to 0xffffff8009425000, probed DDS AD9361
    [ 6.510063] cf_axi_adc ADI AIM (10.00.b) at 0x99020000 mapped to 0xffffff800cda0000, probed ADC AD9364 as MASTER

    Note the TX is misidentified as AD9361 in the zcu102 case.

    axi core versions are different.

    The probed DDS messages comes out of a kernel driver module drivers/iio/frequency/cf_axi_dds.c

    So that's about enough for tonight.  

  • 0
    •  Analog Employees 
    on Feb 11, 2021 6:54 AM 2 months ago in reply to rspanbauer

    This issue was fixed 3 months ago -

    While we're still working on the final 2019_R2 release, a pre-release SD card image can be found here:


  • I took a look at the commit, seemed to be just a change to the device tree.  I made that change in my dev environment, rebooted, and the test script is working as expected.  Appreciate all the help for both of you!  We can close this thread, it was the device tree issue as Michael noted.  Tnx  Rick S