Why ADRV9002 Silicon revision information is 00?

Hello,engineers,

I purchased a new adrv9002 chip and welded it to my evaluation board. After connecting the evaluation board with TES, it shows that the silicon revision is 00.

I have the following questions:

1.Is there any silicon revision not mentioned except B0 and C0? (e.g. version 00 above)

2.If only B0 and C0 versions exist, does the above silicon revision 00 represent a fault? Is the failure due to the lack of firmware in the internal ARM kernel?

3.I notice that TES will no longer support B0 version (Reference: ez.analog.com/.../tes-connection-failure-with-adrv9002-evaluation-card-zcu102 ). Is there a way to upgrade the existing adrv9002 B0 version on ADRV9002NP/W1=0.03-3GHz to C0 version only using software?

Looking forward to your reply, thank you!

Parents
  • +1
    •  Analog Employees 
    on Sep 27, 2021 9:28 AM

    Hello Likeng,

    I will try my best to answer these questions:

    1. 00 is certainly not a silicon revision that we have listed, it's either B0 or C0.
    2. This irregularity could be caused either by a lack of FW or by damage to the device. If you can connect to and program the device then perhaps all is okay, but we've not encountered this before. Do let us know if the device appears operational!
    3. You cannot upgrade using SW, B0 and C0 have differing internal circuitry, hence the incompatibility between revisions of SIlicon and revisions of TES. It is strongly recommended that you upgrade to C0 silicon if possible, certain bugs were never fixed for B0 and many new features were never implemented on B0. Hence, we do not support it any longer.

    I hope this has helped you! Let me know if there's more I can help with.

    Best Regards,
    Oisín.

Reply
  • +1
    •  Analog Employees 
    on Sep 27, 2021 9:28 AM

    Hello Likeng,

    I will try my best to answer these questions:

    1. 00 is certainly not a silicon revision that we have listed, it's either B0 or C0.
    2. This irregularity could be caused either by a lack of FW or by damage to the device. If you can connect to and program the device then perhaps all is okay, but we've not encountered this before. Do let us know if the device appears operational!
    3. You cannot upgrade using SW, B0 and C0 have differing internal circuitry, hence the incompatibility between revisions of SIlicon and revisions of TES. It is strongly recommended that you upgrade to C0 silicon if possible, certain bugs were never fixed for B0 and many new features were never implemented on B0. Hence, we do not support it any longer.

    I hope this has helped you! Let me know if there's more I can help with.

    Best Regards,
    Oisín.

Children
  • HI Oisín!
     Glad to get your reply!  Your response has been a great help to us!
     
     At present, we can successfully use TES to connect the ADRV9002, but it is a pity that there are still problems when we try to use TES to program the chip, including 0.15 and 0.16 versions, and their feedback content is inconsistent.


     Use version 0.15 TES connection and try to program the results


     Use version 0.16 TES connection and try to program the results

    It is impossible to determine whether the failure was caused by the ADRV9002 hardware damage, welding problems or simply a lack of FW.
     
     Here are a few questions:
     1. In the case mentioned above, TES can be used to connect the chip at present, can it represent:
     (1) There is no problem with the chip hardware (except the internal firmware)?
     (2) There is no problem with the welding of the chip (at least including SPI interface)?
     2. Is the action of "TES reads Silicon revision" just that TES reads the internal register of the chip through SPI interface?
     3. If there is no problem with the chip hardware itself welding to the chip, just because of the missing FW, does ADI provide a way to write B0 or C0 FW to the ADRV9002(version 0.03~3G)?
     
     Thanks again for your help!

  • 0
    •  Analog Employees 
    on Sep 28, 2021 3:18 PM in reply to Likeng

    Hi Likeng,

    Okay, this is an interesting set of issues! I haven't seen all of this before, but we'll try answer all that we can!

    1. TES probably won't be able to differentiate if there's a Hardware issue or a Firmware issue. If the ARM is failing to boot then we may have a problem, the SPI interface is used to interact with this processor and setup the device according to your application. Whether or not the SPI interface is damaged, if the ARM isn't functional then there might not be anything we can do except get a new device and try again.
    2. Testing of the SPI interface might be possible via the IronPython interface. After connecting to the device press "View" in the top menu, then select IronPython. If it's your first time using this interface you will need to provide an IronPython "Lib" folder, which is part of the IronPython install, available at this link: https://ironpython.net/download/ (select version 2.7.11). Once the environment is ready, you can use the Doxygen file available in the SDK under the production folder to find APIs to test the SPI interface (adi_adrv9001_spi_Verify(...) should do the trick). We're currently in the process of getting our newest User Guide published, there have been some complications, but here is the new section on testing SPI Access:
    3. If we have a way of flashing the ARM registers with information I'm not familiar with it. Perhaps you could try using the Force Update Platform and Force Update Boot options in the File menu in TES, but I can't be sure they'll work. 

    Like I said before, we've never encountered this issue to the best of my memory. Do let me know if any of these steps made any difference! My gut feeling is that there was some damage during welding that has wiped hose registers, which may be the end of that device.

    Best Regards,
    Oisín.