Question 1

TES GUI Resolution Issue

Accepted Answer

The TES GUI can have resolution issues after a fresh install. This is a result of the PC system settings. Commonly the GUI will look like this with the tab on top of each other.

How to fix this issue: 
 
 Navigate to the source of the .exe. Its is called Argo.Navis.exe and can be found in the default location at C:\Program Files\Analog Devices\ADRV9001 Transceiver Evaluation Software 
 Right click on the .exe file and open the Properties menu. 
 in the compatibility tab select the Change high DPI settings button 
 In the High DPI scaling behaviour make sure this is set to System. 
 Click OK and re-open the TES GUI.

Question 2

Calibration Errors

Accepted Answer

The initial calibrations for the ADRV9001 enable optimum performance. See the TRANSMITTER/RECEIVER/OBSERVATION RECEIVER SIGNAL CHAIN CALIBRATIONS section in the user guide . The initial calibration uses internal loop back and test tones that have hardware requirements, such as Rx and Tx having 50 ohms termination during calibration, see user guide for more details. 
 The most common calibration errors during bring up are listed below with some general guidelines to help locate the root cause. 
 Error Codes and Messages 
 The error messages below are a few of the common error messages for calibration failures: 
 
 Error numbers in this range 8192 &ndash; 16,383 (0x00002000 &ndash; 0x00003FFF), give this error message: &ldquo;Error occurred during an Init Calibration. Check that no signal is being applied to the Rx ports. Check that correct external LOs are applied, and synchronized, where appropriate&rdquo; 
 Error numbers in this range 16,384 &ndash; 24,575 (0x00004000 &ndash; 0x00005FFF), give this error message: "Error occurred during a Tracking Calibration. Disable tracking calibrations, reset and program. If enabled tracking calibrations require external loopback, check loopback connections. If issue persists, contact Analog Devices for support " 
 Error number 9729 (0x00002601), Recovery action -2.In file drivers/iio/adc/navassa/devices/adrv9001/private/src/adrv9001_arm.c, in function adrv9001_ArmCmdErrorHandler, in line 2841, variable name mailboxErrCode.Error message Error occurred during an Init Calibration. Check that no signal is being applied to the Rx ports. Check that correct external LOs are applied, and synchronized, where appropriate. 
 Error number 11264 (0x00002C00), Recovery action -2.In file ../src/devices/adrv9001/private/src/adrv9001_arm.c, in function adrv9001_ArmCmdErrorHandler, in line 2840, variable name mailboxErrCode.Error message Error occurred during an Init Calibration. Check that no signal is being applied to the Rx ports. Check that correct external LOs are applied, and synchronized, where appropriate. 
 Error number 3 (0x00000003), Recovery action -101.In file ../src/devices/adrv9001/public/src/adi_adrv9001_arm.c, in function adi_adrv9001_arm_CmdStatus_Wait, in line 651, variable name device.Error message ArmCmdStatusWait() failed due to thrown ARM error. Is device in correct state for calling command? 
 
 General 
 If correcting the suggestion from the error message did not clear the calibration error then here a few more steps to make sure of: 
 
 Use Silicon Rev C. Verify the revision through API (adi_adrv9001_SiliconVersion) or the TES connection page. 
 Always use the latest SDK release. 
 When using the TES (Transceiver Evaluation Software), confirm the binary and the profile is from the same TES version.
 
 Latest TES and binary files location : Wideband RF Transceiver Evaluation Software | Analog Devices 
 How to program the SD card: a) Writing SD Card Image Manually (SDK23.1 and Higher) - Documents - TES GUI & Software Support ADRV9001 &ndash; ADRV9007 - EngineerZone (analog.com)

Check all power supply voltages for the ADRV9001 device.
 
 All power supplies require stability, it is critical for reliable operation. Check all power supplies always stay within the min/max range. Measure at the ball/cap next to ADRV9001 device and verify stability during calibration. Verify at the ADRF9001 device not the power origin. 
 All power supplies must be within specification all times. (See Table 5 in the data sheet)
 
 VDDA_1P0 Analog Supply : 0.975 V to 1.025 V 
 VDD_1P0 Digital Supply : 0.95 V to 1.05 V 
 VDDA_1P3 Analog Supply: 1.267 V to 1.033 V 
 VDDA_1P8 Analog Supply : 1.71V to 1.89 V 
 VDD_1P8 Digital Supply : 1.71 V to 1.89 V

Ensure that the Mode pin (L13) on the ADRV9001 is connected to VSSA and not left floating. 
 The Rx and Tx pins must be terminated with 50 ohms during calibration. 
 Confirm ARM and stream images are correct for custom boards and use the same version for the profile files.
 
 The ARM image is contained in the "initialize_binary_10 array in the code generated by TES. Each SDK release has its own ARM image. 
 The stream image is contained in the "initialize_binary_09 array in the code generated by TES. Each SDK release has its own stream image.

When using external LO, make sure it is synchronized to the device clock. 
 Check the integrity of SPI clock and data signals. Try reducing the clock and confirm if it improves the
 
 Refer to Serial Peripheral Interface (SPI) Timing section in the data sheet for clock and SPI timing. 
 Refer to Serial-Peripheral Interface (SPI) section in the Users Guide. 
 Refer to Hardware Abstraction Layer (HAL) section in the Users Guide.
 
 Refer to the customer platform section on SPI for details on creation of the customer files. Verify the host controller and the ADRV9001 have compatible configurations.

Verify the custom profile and hardware configuration with ADI Evaluation boards and TES. Ensure that the indicator on the Device Conficguration tab is green. 
 In case of failure with Linux drivers :
 
 Use the specific Linux driver version for the SDK you are using. 
 Make sure that the version of arm and Stream image are correct for given SDK version and is correct for given configuration.

Debug API Function

There is a debug API that can give more information, &ldquo;adi_adrv9001_Utilities_SystemDebugPreCalibrate&rdquo;. You can read about this API and other APIs in the ADRV9001_API.cfm guide. This is in the zip file for the SDK in the production folder.

Question 3

TES Connection Issues

Accepted Answer

For Full Recommended Setup Details 
 
 Read the User Guide provided at analog.com/ADRV9002 
 Under the ADRV9001 Evaluation Setup chapter we provide details on each element of the platform setup. Be certain that all elements of the setup (Host Computer, FPGA [ZC706 or ZCU102] and EVB) are configured exactly as specified in this document. If after confirming your setup is as detailed there, search through this document for the best match to your issue and attempt to run the debug steps we provide. 
 
 Connection Error 
 
 If the FPGA platform is connected through a router with DHCP enabled, the default IP address might need to be changed to the one assigned dynamically. This issue mostly affects the SW packages from v0.14 onwards and silicon revisions C0 and newer, Legacy SD card images (v0.12 and older) should not suffer from this issue as they did not support DHCP. The user will need to find the IP address assigned to the FPGA and use that in the TES Connection tab. 
 Not all versions of TES are compatible with every SD card image release or Device Driver release. Review the CHANGELOG.md and README.md files in the "ADRV9001 TES\" folder to determine which revisions of each package you should be using. A safe approach is to always use the latest release of TES (v0.15 and newer) with the latest SD card image and SW drivers. This works best on the latest silicon (C0 - released silicon) if you have access to that, however if you are using older silicon (B0 - pre-release silicon) you may need use the Legacy option in the SD card imaging tool provided here. 
 The ADRV9001 daughter card may be connected to the wrong FMC connector. Carefully review the User Guide to be certain you have the card on the correct connector as shown in Figure 1 or Figure 2. 
 
 Figure 1. ZC706 FPGA with ADRV9002 Daughter Board 
 
 Figure 2, ZCU102 FPGA with ADRV9002 Daughter Board 
 
 There may be issues with the users Firewall blocking TES from communicating with the FPGA. Review the Firewall settings and make sure they are not blocking TES from connection. This is port 22 for the SSH connection to the FPGA and port 55557 for the TCP connection from the TES. 
 Certain error messages can get &ldquo;stuck&rdquo; in TES log files. This can result in the TES flagging the same issue repeatedly even when there is nothing wrong. Completely uninstall ALL saved versions of TES and download all from scratch. Be sure to save any application critical edits made to the SDK or other files before deleting everything. 
 Our SW also expects that the ethernet address of the host computer is set to 192.168.1.2. Be certain that all elements of the setup (Computer, FPGA and Eval Board) are configured exactly as stated in the User Guide. 
 In the case where pinging the IP address works and there is still no connection it will be worth the PCs encryption settings. 
 
 ************** Exception Text ************** System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms. at System.Security.Cryptography.MD5CryptoServiceProvider..ctor() 
 To overcom this error message, change the encryption settings on the PC to disable the system cryptography FIPS algorithm and the MDMEnabled register.

Server Failed to Start

Using PuTTY start a new SSH session with the following settings (if DHCP is not being used): 
 
 IP address: 192.168.1.10 
 Port: 22 
 Username: root 
 Password: analog 
 
 Log into the FPGA and manually restart the ADRV9001 server at the following directory: 
 
 /home/analog/adrv9001_server/resources/Adi.Adrv9001.Server/ 
 Execute command: ./Adrv9001Server_{Silicon Revision}_{Server Version}

The server may fail to start due to issues with the ADRV9001 daughter card. This is usually the fault of:
 
 The daughter card is not getting a clk input. If the setup needs the onboard clk, ensure the clk switch at the top of the board is in the &ldquo;Internal&rdquo; position. Otherwise, keep the switch in the &ldquo;External&rdquo; position and double check your external clk supply. The &ldquo;On Board TCXO Enabled&rdquo; LED should indicate whether the onboard clk is successfully powered or not. 
 There may be some damage to the daughter card&rsquo;s onboard power-management circuitry. The &ldquo;Power Supply OK&rdquo; LED is used to indicate whether the card&rsquo;s power domains have been initialised successfully. If this LED is off there is likely an issue either with the ADP5056 chip used on the card, with one of the surrounding components or with the FPGA. Review our documentation regarding the daughter card&rsquo;s power supply and power domains and attempt to debug the board and the FMC connector. It may be necessary to replace the ADP5056 if it is damaged.

The server may also fail to start in the event that the FPGA did not boot up correctly. Sometimes this can be a benign issue, simply power cycle the FPGA if either the LEDs next to the FPGA power switch or the System OK LED next to the Fan Header on the ADRV9001 daughter card are not behaving as specified in the User Guide. 
 If the SD Card image has been corrupted this may also prevent server launch. Check the &ldquo;SD Card Image Corrupted&rdquo; section of this document for more details.

SD Card Image Corrupted 
 
 We provide a guide on writing SD card images here: https://ez.analog.com/wide-band-rf-transceivers/tes-gui-software-support-adrv9001-adrv9007/w/documents/15476/sd-card-image We recommend you read this guide through and ensure that no step fails for you. 
 At minimum we recommend having a 16GB SDHC card, Spec Version 4. This should ensure you're not running into memory constraints on your platform. 
 Sometimes the SD Card image will be corrupted during file download in our SD card imaging tool. This problem will present itself as an error message during the Write to Device step of the SD Card imaging tool. An error message will be given similar to: &ldquo;End of Central Reserve Cannot be Found&rdquo; on Windows10 computers (different error messages have been seen on Windows7 machines, but we have little information on this behavior). If this error occurs, exit the imaging tool and delete the corrupted SD card image on your computer. Run the SD Card imaging tool again, being certain that you ran it both with elevated privileges and with a very stable internet connection. 
 Firewalls can prevent our tool from downloading the SD card image. Be sure that the firewall is not interfering with the SD card imaging tool. 
 Certain encryption software used by corporations to protect their data can encrypt data written to external devices such as SD cards. Be certain that either the encryption software is not interfering with the data transfer or that you have a workaround if you cannot disable the encryption software. 
 If the FPGA fails to boot repeatedly, it may be the case that the SD card has been corrupted due to an ill-timed platform shutdown. Reimage the SD card and try again. 
 
 Can't 'Ping' FPGA 
 
 Normally you should be able to get a ping response from the FPGA (192.168.1.10) 
 If you can't get a response from this address, first try to ensure that you can ping 192.168.1.2 (your PC). If you can't get a response from this address then ensure that your port is set up as described in the user guide 
 If you still can't get a response from 192.168.1.10, try ping "linaro-developer", the default FPGA hostname. You may receive a response from an IPv6 address. This is a known bug. To resolve this, log in to the FPGA with this IPv6 address and manually assign the FPGA address to 192.168.1.10. 
 One way to do this is as follows:
 
 Log into FPGA with IPv6 address (or else use serial port) 
 Run $ ifconfig 
 We can see the &bdquo;eth0&ldquo; interface but no IP Address assigned: 
 
 Navigate to network directory using $ cd../etc/network 
 Here we will want to make an edit to the interfaces file: 
 
 Using 'vim' or otherwise, make the following edits to the file:
 
 Comment out the line ' iface eth0 inet dhcp' with a '#' 
 Add the following lines : 
 
 iface eth0 inet static 
 address 192.168.1.10 
 netmask 255.255.255.0 
 gateway 192.168.1.1

Save changes

Reboot platform and check that the correct IPv4 address has been assigned

General 
 
 The ADRV9001 daughter card requires an LVDS interface voltage of 1.8V. To achieve this, our SD card forces the ZC706 platform to operate outside of its normal operating parameters. If the SD card has not loaded properly, it is possible that the FPGA will provide a voltage to the interface that is sufficiently high enough to damage the daughter card. The System OK LED next to the Fan Header on the ADRV9001 daughter card will be RED if the interface voltage is too high. If you see this LED light up RED for a long duration, power down the FPGA and re-image the SD card. If this does not fix the issue, make certain that the FPGA is set up exactly as stated in the User Guide. Failing that, it is possible that either FPGA or the daughter card have some physical damage. 
 When the EVB and the FPGA are connected properly and the SD card is imaged correctly the LEDs will follow the following sequence after the FPGA is switched on:
 
 On the FPGA the GPIO LEDs next to the switch will flash in sequence (one LED off at a time) 
 on the EVB the overvoltage LED (DS702) will initially be red but will turn off quickly as the interface voltage on the FPGA is changed to 1.8V 
 The system ok LED (DS703) will start to flash green constantly. 
 The power good LED (DS901) will turn on green, this LED might be a bit feint but is ok as long as it is on. 
 The clock power and devclk_aux LED, both at the top of the board, will turn on. Devclk_aux will only be off if the switch is changed to the external clk setting.

Some setups will note that the fan on the FPGA no longer spins when connected to the FPGA fan header. This issue will not appear for everyone, but for those that do see this behavior, the solution is to connect the fan cable to the fan header on the ADRV9001 daughter card.

Question 4

SSI Debug with Loopback Test

Accepted Answer

The goal of this guide is to use the SSI Loopback functionality from Tx1 to Rx1 to verify that data is reaching the Tx1 interface without being corrupted. This guide is quite useful of people who have evaluated the ADRV9001 product and are now attempting to build their own platform away from the ZC706 FPGA. The following steps should be carried out first using our FPGA platform and then ported over to their own platform if the FPGA run is successful. 
 In the User Guide, under Data Interface: CSSI/LSSI Testability and Debug there is the following diagram. The loopback which has been circled in Red is the one we intend to use here.

Step 1:Set your Configurations tab 
 For this example, an FDD setup will be used, as shown below. Any setup which allows the Rx1 interface to send data while the Tx1 datapath is transmitting is acceptable, meaning that not all TDD setups will allow this test to run. Additionally, no tracking calibration that requires Internal Loopback or External Loopback can be used. As we&rsquo;re enabling the SSI loopback, no data will reach the Rx SSI via the Rx datapath. 
 
 The Dual Channel operation will be required for this debug operation. We&rsquo;re going to program the Tx1 channel to perform various transmissions and then monitor the output using both the Rx1 interface and a Spectrum Analyzer. The same steps would also work for Tx2 -> Rx2 under different setups. The only major change will be to the set_Loopback(&hellip;) command, we&rsquo;ll highlight this later. 
 
 Step 2: Set the Carriers tab 
 The only alteration made to this setup was to change the Tx Carrier Frequency to 1.6GHz. Do also run a quick check of all other tabs, the default configurations for this setup are fine so no edits are made here. One configuration that will be required is the Tx Data Source being set to the FPGA in the Radio tab. Using internal tone generation will power down the Tx SSI, which will prevent us from performing this test.

Having an IF set for the Rx1 channel will not affect this test at all, as there will be no mixing taking place. Any legal carrier frequency that you want to test here will work, 1.6GHz is just one usecase. 
 
 Step 3: Program the part 
 At this point it&rsquo;s no harm to quickly test the Tx transmission using the spectrum analyser as a sanity check: 
 
 At this point we can set the SSI Loopback. If you try receiving data now you should observe nothing on Rx1 or Rx2:

Step 4: Set the SSI Loopback 
 Stop all Tx and Rx operation. Now open the IronPython programming interface and load the SSI_Loopback.py script (it has been supplied with this guide in .zip format). Pay particular attention to the areas of code circled in red in the below images. These are the sections of code added to the default &ldquo;New File.py&rdquo; that opens when the IronPython coding interface is opened. 
 Ssi_Loopback.zip 
 
 If everything runs as expected you should see &ldquo;Loopback Set&rdquo; printed into the terminal window. *Note: For setups which allow Tx2 -> Rx2 loopback, we can change the &ldquo;channel_num = common_ChannelNumber_e(1)&rdquo; line to &ldquo;channel_num = common_ChannelNumber_e(2)&rdquo;. The channel type can similarly be changed from CMOS : &ldquo;channel_type = adrv9001_SsiType_e(1)&rdquo;, to LVDS : &ldquo;channel_type = adrv9001_SsiType_e(2)&rdquo; 
 
 Step 5: Program the Part Again 
 Start transmitting again. The spectrum analyser should see exactly the same thing as before: 
 
 Now start receiving while transmitting: 
 
 Notice how Rx1 (in Black) now sees exactly the same tone that&rsquo;s present in the Tx tab. Deselect Rx2 (the Blue line) in this tab now. 
 If we start changing the transmission, Rx1 should respond accordingly: 
 
 At this point we&rsquo;ve confirmed that data is reaching the Tx1 dataport through the FPGA without distortion. 
 
 Step 6: Produce C code and Compile on Platform 
 Produce C code from this session using Sample Code -> C99 . It&rsquo;s unlikely that the API we called in the IronPython interface has been saved into the log file, so we&rsquo;ll need to find the correct point to insert it. The loopback must be set in the Primed state after all calibrations are complete , but before the device enters the RF Enabled state . Navigate to your C code and open the main.c file: 
 
 We&rsquo;re going to add 1 extra #include and call the SSI Loopback API between the &ldquo;prime(&hellip;)&rdquo; call and the &ldquo;beginReceiving(&hellip;)&rdquo; call: 
 
 The arguments for the API are identical to those we used in the IronPython interface: 
 
 A pointer to the ADRV9001 device (Not used in IronPython) 
 Channel Number: 1 = Channel 1, 2 = Channel 2 
 Channel Type: 1 = CMOS, 2 = LVDS 
 Loopback Enable: 0 = False, 1 = True 
 
 Next, we will compile this code on your own platform. You will need to adjust the generated C code to suit your platform. Get the code to compile on your platform before proceeding. 
 Step 7: Confirm RF performance on Platform 
 We&rsquo;ll simply perform step 5 again. Transmit data to a spectrum analyzer. Confirm that it matches your expectations, and then inspect the data returned from the Rx1 datapath. That may have to be done offline, but that&rsquo;s fine. 
 What you&rsquo;re looking for is any glaring differences between the Tx1 input data and the Rx1 output data. Any differences here would indicate strongly that the Tx1 SSI has not been setup correctly on your own platform. Things to look out for are: 
 
 Reduced SNR 
 Increased / Decreased Tx signal bandwidth 
 The Tx Tone being at completely the wrong frequency 
 A Tx tone that moves when it shouldn&rsquo;t 
 
 Step 8: Extra Debug (if needed) 
 Pending the results of the previous 7 steps, you may or may not have narrowed down the possible causes for your issue. If you&rsquo;re still having issues the following considerations may help you home in on the problems you are experiencing. These considerations will go into how you have configured the Tx/Rx SSI ports on your own platform. If you monitor your SSI port during its interactions and the behavior does not match your expectations we will have found the source of the issue.

Rx SSI 
 
 In CMOS-DDR mode, with default SSI configuration: 
 
 Navassa RX SSI output should be something like Figure1; 
 Ps: Yellow - Clock, Purple &ndash; Strobe, Green &ndash; Data 
 Figure 1: CSSI-DDR default, Navassa Rx SSI output 
 
 &lsquo;cmosDdrClkInversionEn&rsquo; doesn&rsquo;t help on the SSI setup/hold time for DDR mode, it only effects on which clock edge (rising or falling) the system will sample the first strobe/data, refer Figure 2. 
 Figure 2: CSSI-DDR default -> set cmosDdrClkInversionEn = True 
 
 &lsquo;cmosDdrPosClkEn&rsquo; = True will add a quarter clock delay (refer Figure 3) but as Figure 1 shows Rx SSI clock output by default has quarter clock delay to strobe/data. So, another quarter clock delay will make the clock/strobe/data phase aligned. 
 Figure 3: CSSI-DDR default -> set cmosDdrPosClkEn = True

TX SSI 
 
 Tx SSI clock/Strobe/Data is controlled by users&rsquo; BBP, they should make sure the SSI setup/hold time at ADRV9002 SSI pad inputs meet the spec requirement. 
 &ldquo; cmosTxDdrNegStrobeEn &rdquo; is internal debug and Tx SSI only, users don&rsquo;t need to change the default value. 
 cmosDdrPosClkEn and cmosDdrClkInversionEn have the same functions as their Rx SSI counterparts, they can set cmosDdrPosClkEn = Ture to make a quarter clock delay and check if it helps 
 Another useful check is to call the &ldquo;adi_adrv9001_Ssi_Delay_Configure&rdquo; to set the clock/strobe/data phase relationship in ADRV9002.

Partner Forums

Partner Libraries

Debug: FAQ