From AD9361 to ADRV9009: ZCU102 No-OS Project Migration – Practical Experience & Lessons Learned

Real-world migration experience from AD9361 to ADRV9009 on ZCU102. Hardware architecture differences, No-OS project structure, JESD204B configuration pitfalls, RF performance optimization, and production testing insights.

During a wireless communication project last year, our team decided to upgrade from the AD9361 platform to the ADRV9009. We assumed that with our prior experience, the transition would be smooth — but we encountered quite a few challenges on the ZCU102 development board. This article documents the practical details you won't find in textbooks, particularly the differences that experienced AD9361 developers tend to overlook when moving to the new platform.

1. Hardware Architecture Differences and Migration Strategy

While both the ADRV9009 and AD9361 belong to Analog Devices' RF transceiver family, their internal architectures differ more than you might expect. The most notable distinction is that the ADRV9009 features a dual-channel design, with each channel containing independent receive and transmit paths. This means the No-OS driver layer must handle a more complex initialization sequence.

Key differences comparison:

The most error-prone part of the migration is clock configuration. The AD9361 only requires configuring the main PLL, while the ADRV9009 needs coordination across three clock domains:

1. RF clock (RF PLL)
2. Data converter clock (ADC/DAC clock)
3. JESD204B transceiver clock

// ADRV9009 typical clock initialization code snippet
talise_setClockConfig(&device, {
    .clkPllVcoFreq_kHz = 9830400,
    .clkPllHsDiv = 1,
    .clkPllVcoDiv = 2,
    .clkPllVcoBypass = 0
});

2. No-OS Project Structure Deep Dive

ADI's No-OS project structure appears similar at first glance, but the details differ significantly. Taking the ZCU102 platform as an example, here are the key changes in file organization:

Critical directories to check:

• drivers/rf-transceiver/talise/ — Contains ADRV9009-specific firmware and API
• projects/adrv9009/zcu102/ — New reference design directory structure
• hdl/projects/adrv9009/ — Hardware description layer file location changes

The most easily overlooked file is talise_arm_binary.h, which contains the firmware image for the ADRV9009's integrated ARM processor. This requirement didn't exist in AD9361 projects, but in ADRV9009 it must be correctly loaded:

# Makefile dependencies to add
ADI_DEPS += talise_arm_binary.h talise_stream_binary.h

3. JESD204B Interface Configuration Pitfalls

The ADRV9009 mandates the use of the JESD204B interface — a new challenge for AD9361 users. GTY transceiver configuration on the ZCU102 is particularly critical. Common issues include:

1. Link training failures — usually caused by clock synchronization problems
2. Poor eye diagram quality — requires adjustment of pre-emphasis and equalization settings
3. Firmware loading timeouts — ARM processor initialization not completed

Debug command sequence:

# Check JESD status in Vitis debug terminal
xsct% targets -set -nocase -filter {name =~ "*ARM*#0"}
xsct% mrd 0x80040000  # Read JESD status register

JESD troubleshooting checklist:

4. RF Performance Optimization

ADRV9009 RF performance tuning is significantly more complex than AD9361, primarily in these areas:

Receive chain optimization focus:

• Digital Pre-Distortion (DPD) calibration
• Automatic Gain Control (AGC) strategy selection
• IQ imbalance compensation
• RF bandwidth and filter settings

A typical receive path configuration flow:

// Configure receive channel parameters
talise_setRxGainControlMode(device, TAL_AGC_MODE_FAST_ATTACK);
talise_setRxRfBandwidth(device, 100000000);     // 100 MHz bandwidth
talise_setRxSamplingRate(device, 245760000);    // 245.76 MSPS

// Run calibration
talise_runInitCals(device, TAL_CAL_ALL);

5. From Prototype to Production: Lessons Learned

In the final phase of the project, we encountered several issues that only emerge during mass production:

1. Temperature stability: ADRV9009 performance varies significantly with temperature, requiring:
   • Implementation of temperature compensation algorithms
   • Addition of thermal cycle calibration to production testing
   • Storage of calibration parameters in non-volatile memory
2. Firmware upgrade strategy: The ADRV9009 ARM firmware may need field updates. We developed:
   • A UART-based bootloader
   • Secure verification mechanisms
   • A rollback scheme
3. Production test optimization: Traditional AD9361 test methods no longer apply. We switched to:
   • Python-based automated test framework
   • Batch RF parameter calibration
   • Digital pre-distortion compensation database

# Example: Automated test script snippet
import pyadi

dut = pyadi.adrv9009('192.168.1.100')
dut.calibrate()
results = dut.run_tests({
    'TxPower': [-40, -30, -20],
    'RxSensitivity': [70, 85, 100]
})
generate_report(results, 'production_test_001')

6. Quick Project Validation

If you want to shorten development cycles and accelerate project validation, we recommend the following boards:

• XC7Z100 + ADRV9009 SDR with Preloaded Firmware
• XC7Z100 + AD9371 SDR with Preloaded Firmware