Post Go back to editing

ARM boot timed out while trying to bring up the ADRV9002

Iam trying to bring up the ADRV9002 with the Production Stage – ANSI C API Driver Code,

Below are the details of the setup:

1. ADRV9002BBCZNP/W1=0.03-3GHz C0 silicon revision board and ZCU102 Rev 1.1 board is used.

2. Ver. 0.16.0 ANSI C API Driver Code is compiled and loaded in ZCU102 and ZCU102 FPGA is SPI master

2. We have taken the Sample C code by running the TES GUI Ver. 0.16.0 in the ZC706 platform. This sample C code is compiled and loaded in ZCU102 board.

3. SPI level functionality is working (adi_adrv9001_HwOpen is success)

The functions up to adi_adrv9001_arm_Start is working fine.

But adi_adrv9001_arm_StartStatus_Check function is returning "Timed out waiting for ARM bootup to happen".

What may be the reason for this issue.

  • Hello Saravanan,

    Could I ask why you take code from TES executed on a ZC706 and port it to a ZCU102? Why not connect TES to the ZCU102 and generate code that way? The generated code from TES will probably not look any different for either platform, however our Stream images and ARM images will most likely be different for the two platforms. This may be a source for your issue.

    Other alternatives are that the profile you're using has sample rates and clk settings that are causing the ARM to time out. If this is the case, you could try using code for a "default" setup (like a basic DMR or LTE setup from TES) and seeing if the device programs on your ZCU102.

    In either case, do let me know what works for you in the end!

    Best Regards,

  • Hello Oisin,

    When we tried to work with TES GUI Ver. 0.16.0 in the ZCU102 platform, we are not getting the spectrum output. The problem is already reported in the forum and it is available in the link

    For this reason we have taken the Sample C code by running it in the ZC706 platform.

    As suggested, we will take the Sample C code in default setup and verify whether the device programs successfully.


  • Hello again,

    If that issue is still not fixed, then I would be pressed to believe that either the ZCU102 is not working or your SD card image for the ZCU102 is corrupted or incorrect.

    Are you running separate SD cards for each platform? Using a common SD card will not work, as such we provide dedicated SD card images for the ZC706 and the ZCU102. If you are sharing an SD card across the 2 devices, keep your current SD card in the ZC706 and purchase a new SD card for the ZCU102, imaging it as per our documented instructions in the documents forum:

    Alternatively, if you have been using separate images for each device, do you have a second ZCU102 to try with? Perhaps the ZCU102 you have been trying is damaged in some way?

    Do let me know how you get on!

    Best Regards,

  • Hello Oisin,

    As suggested we have taken Sample C code(ZC706) in default setup but same error is coming while running the program.

    We have taken Sample C code in ZCU102 also(we are to able to program successfully, only spectrum output is not correct), here also same error is coming in same function.

    There may be some issue in ZCU102 itself, but since SPI is working successfully ZCU102 may not be a reason.

    please share the list of possible reasons for this ARM error message. We also want to know whether the SSI lines RX_DCLK_OUT, RX_STROBE_OUT, RX_IDATA_OUT and RX_QDATA_OUT will start functioning even if the ARM is not working.

  • Hello Saravanan,

    I brought your issue to the team again, one of our lead engineers came back with the following:

    • ZCU102 + CE + TES (ADI FPGA HDL)
      1. User can program successfully
      2. Sees issue with DMA Timeout indicating issue on SSI
        1. Check RxSSI Clock/Data/Strobe on scope and verify they are correct
    • ZCU102 + CE + Compiled Code (Using ADI FPGA HDL?)
      1. ArmStart Status Check issue
      2. User mentions "This sample C code is compiled and loaded in ZCU102 board."
        1. I'm not clear here on two things
          1. Are they using ADI FPGA HDL as-is?
          2. How is the code loaded on ZCU102? Are they running a custom application on ZCU102?

    Could you clear up these points and try these bits of debug? We may be able to clear your issue up with a little more info!

    Best Regards,

  • Hello Oisin,

    For the ZCU102 + CE + Compiled Code query,

    1) We are using ZCU102 Rev 1.1 evaluation kit and the ADRV9002BBCZNP/W1=0.03-3GHz C0 silicon revision board

    2) We are having our own BSP and Linux OS for ZCU102 APU processor

    3) We have developed our own ZCU102 FPGA logic to interface with ADRV9002. Mainly SPI and other IO lines are controlled by it.

    4) We have taken Ver. 0.16.0 ANSI C API Driver Code and compiled in custom ZCU102 Linux OS. This driver code is like library.

    5) To configure and program the ADRV9002 we have taken the Sample C code from the TES GUI Ver. 0.16.0. This code has the API configuration sequence which will call the C API Driver function calls. This Sample C code from the TES GUI also compiled for custom ZCU102 Linux OS.

    The above mentioned ARM error message is coming while running this code.

  • Hello Saravanan,

    Apologies for the long delay, I brought your issue to the Software team but it's rather a difficult issue for them to address.

    Given that you're operating on a custom FPGA image it's hard for them to speak to what may be causing your issue. However from the experience we have on hand, the best advice we can provide is to double check your SPI interface voltage and speed to make sure they're within our operating limits. It's strongly recommend that you check all signals sent and received from your platform via external scope: RxSSI Clock/Data/Strobe, etc. It may well be the case that the issues faced with the Rx output spectrum are tied to this issue too, if any interface settings are out of spec or not in line with the device configuration this type of issue is to be expected.

    Other things to check are the Clk source (internal or external, check them either way) and confirm the Clk signal matches the setup being used. Check the power domains, make certain the device is powered correctly and that the interface voltages do not exceed 1.8V.

    You can check your FMC connections, make sure the appropriate signal is being routed to the appropriate pin in the FMC. Even polling FMC signals on a scope is a great piece of debug if you're not getting any traction.

    Aside from those it's very difficult to provide extra debugging info. 

    Do come back and report on any other bits of progress of issues you are facing. 

    Best Regards,

  • you can check the spiwritemode when you write stream_image and arm_image。mabey your platform can not use the ADI_ADRV9002_ARM_SINGLE_SPI_WRITE_STANDARD_BYTES_252。you can try ADI_ADRV9002_ARM_SINGLE_SPI_WRITE_STANDARD_BYTES_4

  • Hi Team, 

    Is this issue resolved? we are facing similar issue in our custom hardware. Please post the solution if any. 

  • Hi,

    Sorry, we missed your comment here. It's best to create new questions as old threads can get lost.

    Could you please create a new question and explain your issue in detail for us?