AD9739a driver vs current hdl core version

I'm in the process of bring up the AD9739a fmc eval board on a Xilinx zcu104 eval board.  After struggling a bit working through device-tree issues, the driver is reporting:

  cf_axi_dds a0000000.axi_ad9739a: Major version mismatch between PCORE and driver. Driver expected 9.00.b, PCORE reported 173.222.\xad

My question is given the ad9739a was introduced quite a while ago, has the ADI Linux driver been kept current?  

FWIW, I don't have a zc706 to do a basic functionality test of the ad9739a reference design, and I'm not quite desperate enough yet to install ISE and test the '605 eval board design.

Tnx -- Rick S

Parents
  • 0
    •  Analog Employees 
    on Mar 18, 2021 9:17 PM

    Hi,

    The Linux driver should work.

    Is 0xa0000000 the actual address of your cf_axi_dds core? This is definitely incorrect if you have started from our ad9739a_fmc_bd (https://github.com/analogdevicesinc/hdl/blob/master/projects/ad9739a_fmc/common/ad9739a_fmc_bd.tcl#L47 ).

    Thanks,
    Dragos

  • I did a bit more debugging and found that accesses to the ad9739a core address space are returning 0xdeaddead, thus the oddball version number.  This seems to be somehow related to the ad9739a not responding on spi0.1, which almost certainly is some device tree error I've introduced.  Next step is to put a logic analyzer the the P4 pins to verify whether CS, Clk, etc are toggling at all.  I've had the CHIP_ID come back correct (0x24) on a few runs, but haven't quite figured out why I'm getting 0x00 or 0xff at times.  More debugging.  Tx for the response.

  • 0
    •  Analog Employees 
    on Mar 20, 2021 5:53 AM in reply to rspanbauer

    The problem shouldn't be related to the SPI communication issues. You should be able to access the cf_axi_dds's registers even without having the AD9739A connected. Make sure that the address specified in the devicetree (e.g., https://github.com/analogdevicesinc/linux/blob/master/arch/arm/boot/dts/zynq-zc706-adv7511-ad9739a-fmc.dts#L74 ) matches the one specified in the Vivado project.

    Thanks,
    Dragos

  • Thanks Dragos.  This is looking like a bad level translator on the AD9739A fmc board.  A took a minor detour to work out why I wasn't getting Vadj = 1.8V on the zcu104, and once past that issue, it was clear from some probing that even with good logic levels at the input of the 3308 level translator, the SSEL1 line was ending up 2/3 the way between the supply rails.  The DAC chip seems to be OK; I loaded the ADI dac suite and interrogated the 9739 via the onboard SPI/USB microcontroller.  So now it's just a waiting game for the replacement level shifters to show up later this week.  

    On the 1.8V issue, apparently the zcu104 will default to 1.2V if the first stage boot can't read the FMC eeprom (according to the 9739a FMC board wiki,there is no eeprom on that board).  I wasn't sure if the LVDS data plane would work at 1.2V if I needed to terminate the clock or such, thus the detour to exploring why the zcu104 was serving up Vadj at 1.2V.  

  • Just to wrap this question up, what I had to do to get the AD9739a working on the zcu104 was:

    1. I modified xfsbl_board.c in the Xilinx first stage boot distro to assert Vadj=1.8V.  Without an eeprom on the board, the zcu104 defaults Vadj = 1.2V.  I still need to verify that this change was necessary; TBD, but it looked like I needed the board at 1.8v to use termination + hit the voltage margins.

    2. The spi /csn signal generated by the Mpsoc appears to be open drain, and there is no pullup on the AD9739a FMC.  This made it appear as though the level shifter wasn't working properly.  I added a couple of "PULLTYPE PULLUP" in the constraints file to have the mpsoc pull these lines up.  That allowed the drivers to reliably access the AD9739a (the ADF4350 is write only, so there is no direct way to check its spi asserted settings took).  Before this change, the ad9739a driver would fail when it read CHIP_ID as 0x00 or 0xff.

    3. Getting the device-tree settings correct: I didn't realize this initially, but the ADI dac core needs an offset of 0x4000 in the device-tree configured (by Vivado) address.  The relevant hdl is the COMMON_ID processing in ADI/hdl/library/command/up_dac_channel.v.  Once I understood this, the issue accesses to the core returned 0xdeaddead was fixed.  This was the issue that provoked the original question in this thread.

    4. Another issue was the Vivado generated device-tree settings for the ADI dmac - the compatible driver was listed as xlnx,axi-dmac-1.0.  In the example dts for the zc706 reference design, the compatible driver entry for the dmac was correctly set to adi,axi-dmac-1.00.a, but I missed this.  Of course, once corrected, ADI linux needed to be configured for the ADI dmac:  CONFIG_AXI_DMAC=y

    The board will occasionally boot up and complain about RX data lock failures.  I still have to figure that one out.

    With all that worked out, the board is generating tones from its dds.  This was the first time I ported an ADI core, and learned quite a bit.  

Reply
  • Just to wrap this question up, what I had to do to get the AD9739a working on the zcu104 was:

    1. I modified xfsbl_board.c in the Xilinx first stage boot distro to assert Vadj=1.8V.  Without an eeprom on the board, the zcu104 defaults Vadj = 1.2V.  I still need to verify that this change was necessary; TBD, but it looked like I needed the board at 1.8v to use termination + hit the voltage margins.

    2. The spi /csn signal generated by the Mpsoc appears to be open drain, and there is no pullup on the AD9739a FMC.  This made it appear as though the level shifter wasn't working properly.  I added a couple of "PULLTYPE PULLUP" in the constraints file to have the mpsoc pull these lines up.  That allowed the drivers to reliably access the AD9739a (the ADF4350 is write only, so there is no direct way to check its spi asserted settings took).  Before this change, the ad9739a driver would fail when it read CHIP_ID as 0x00 or 0xff.

    3. Getting the device-tree settings correct: I didn't realize this initially, but the ADI dac core needs an offset of 0x4000 in the device-tree configured (by Vivado) address.  The relevant hdl is the COMMON_ID processing in ADI/hdl/library/command/up_dac_channel.v.  Once I understood this, the issue accesses to the core returned 0xdeaddead was fixed.  This was the issue that provoked the original question in this thread.

    4. Another issue was the Vivado generated device-tree settings for the ADI dmac - the compatible driver was listed as xlnx,axi-dmac-1.0.  In the example dts for the zc706 reference design, the compatible driver entry for the dmac was correctly set to adi,axi-dmac-1.00.a, but I missed this.  Of course, once corrected, ADI linux needed to be configured for the ADI dmac:  CONFIG_AXI_DMAC=y

    The board will occasionally boot up and complain about RX data lock failures.  I still have to figure that one out.

    With all that worked out, the board is generating tones from its dds.  This was the first time I ported an ADI core, and learned quite a bit.  

Children
No Data