Post Go back to editing

Cannot reset ADRV9029 DPD when enable DPD Tracking Calibration

Thread Summary

The user encountered an error (Error number 3, Recovery action -2) while trying to enable DPD tracking calibration on ADRV9029 using the no-OS branch R2023_2. The issue is related to the adi_adrv9025_DpdReset function, and the current no-OS branch does not support DPD. The recommended solution is to use the main branch of no-OS, which includes the necessary updates and ORx data path support. The user should ensure the ORx data path is enabled in the HDL and use the latest API version for DPD configuration.
AI Generated Content
Category: Software
Product Number: ADRV9029
Software Version: R2023_2

Hello,

After bring up the ADRV9029 on our custom board, now we need to enable the DPD tracking calibration. I followed the DPD Tracking Calibration Bring Up Sequence (UG1727) but stuck at the adi_adrv9025_DpdReset function.

The log is: ERROR: Error number 3, Recovery action -2. In file ../src/noos/drivers/rf-transceiver/madura/devices/adrv9025/public/src/adi_adrv9025_dfe.c, in function adi_adrv9025_DpdReset, in line 279, variable name cmdStatusByte. Error message CpuCmdStatusWait() failed due to thrown CPU error. CPU time out .

For more information:

  1. I'm using no-OS branch R2023_2
  2. Device information: Silicon Rev : 0xb0; Product ID : 0x84
  3. ADRV9029 is successfully initialized with no-OS APIs. The log is:
    adrv9025-phy Rev 0, API version: 6.4.0.14 found
    tx_adxcvr: OK (9830400 kHz)
    rx_adxcvr: OK (9830400 kHz)
    adrv9025-phy Rev 176, Firmware 6.4.0.6 API version: 6.4.0.14 Stream version: 9.4.0.1 successfully initialized via jesd204-fsm
    tx_jesd status:
    	Link is enabled
    	Measured Link Clock: 245.761 MHz
    	Reported Link Clock: 245.760 MHz
    	Lane rate: 9830.400 MHz
    	Lane rate / 40: 245.760 MHz
    	LMFC rate: 7.680 MHz
    	SYNC~: deasserted
    	Link status: DATA
    	SYSREF captured: Yes
    	SYSREF alignment error: No
    rx_jesd status:
    	Link is enabled
    	Measured Link Clock: 245.761 MHz
    	Reported Link Clock: 245.760 MHz
    	Lane rate: 9830.400 MHz
    	Lane rate / 40: 245.760 MHz
    	LMFC rate: 7.680 MHz
    	Link status: DATA
    	SYSREF captured: Yes
    	SYSREF alignment error: No
  4. I used Ramarao's code as a reference to enable DPD
  5. The adi_adrv9025_DpdModelConfigSet function returns OK. I used adi_adrv9025_DpdModelConfigGet and the read back model is the same, except txChannelMask = 0x00
  6. I tested with CFR APIs and I think it's working fine. The CFR status is:
    CFR Parameters Readback:
    Tx Channel Mask:1 
    cfrMode:0 
    cfrTxDelay: 511
    cfrPeakThreshold:0.490000 
    cfrEngine1PeakThresholdScaler:0.980000 
    cfrEngine2PeakThresholdScaler:0.985000 
    cfrEngine3PeakThresholdScaler:0.990000 
    cfrCorrectionThresholdScaler:0.980000 
    cfrInterpolationFactor:2 
    cfrEngine1MaxNumOfPeaks:5 
    cfrEngine2MaxNumOfPeaks:5 
    cfrEngine3MaxNumOfPeaks:5
    
    CFR Status Readback:
    CFR_Error_Code:0 
    cfr Engine1 Peaks Detected:0 
    cfr Engine1 Peaks Skipped: 0
    cfr Engine2 Peaks Detected: 2
    cfr Engine2 Peaks Skipped: 0
    cfr Engine3 Peaks Detected: 2
    cfr Engine3 Peaks Skipped: 0
    cfr NumSamples Clipped: 1
    
    CFR Enable Read: 
    tx Channel Mask:1 
    cfr Engine1 Enable:1 
    cfr Engine1 Bypass Enable:0 
    cfr Engine2 Enable:1 
    cfr Engine2 Bypass Enable:0  
    cfr Engine3 Enable:1 
    cfr Engine3 Bypass Enable :0
    *** CFR Configured success***
  7. All other DPD APIs called after adi_adrv9025_DpdReset are failed with Error number 3, Recovery action -2

Is there anything else I need to do to enable DPD?

  • Hi  ,

    Are you sure that DPD is working? Have you checked the DPD status after enabling the cal? Furthermore, DPD should be enabled on a specific Tx channel, and therefore the fact that you have txChannelMask = 0x00 makes me wonder if the cal is actually working.

    When resetting DPD, you should use the same Tx channel mask as the one for which DPD was enabled:

    ret = adi_adrv9025_DpdReset(phy->madDevice,
                                phy->dpdTxChannel,
                                ADI_ADRV9025_DPD_RESET_FULL);

    Regards,

    G

  • Hi danmois,

    I have problem with DpdReset when I do the sequence to enable DPD. It's the step 9 in Table 263 UG1727. So I haven't made it to the DpdTrackingConfig yet.

    About the Tx channel used for DPD, I'm testing with TX1 only and txChannelMask = 0x01 when calling adi_adrv9025_DpdModelConfigSet.

  • Hi  ,

    The following branch (Linux driver, but can be translated to no-OS) is also based on the same table. It is work in progress that was not fully tested, but DPD was activated (expected DPD status) by the actions here: https://github.com/analogdevicesinc/linux/compare/main...madura_add_dpd

    An important thing to note is that the HDL and driver here also uses the ORx data path.

    Adding the ORx data path in no-OS is work in progress, and it will be available on the main branch the following days.

    Regards,

    G

  • Hi danmois,

    Thank you for the driver, but I'm not really familiar with Linux driver, so may I ask some questions:

    • Is the no-OS driver capable of enabling adrv9029 DPD? Or I have to use Linux for this function?
    • Do I need the ORx data path in the FPGA HDL in order to enable DPD, or the current example HDL (profile 51_nonLinkSharing, 4TX 4RX) is still okay?
  • Hi  ,

    1. currently not, the modifications in the Linux driver have to be ported here

    2. you will need a profile that has ORx enabled, since you will have to enable ORx during the first steps when performing the tracking cals. We did not actually try to implement a profile with ORx enabled and missing from the HDL. Could be a way to test things. Anyway, ORx will be implemented on the main branch the following days.

    Regards,

    G

  • Hi danmois,

    Thank you for the information.

    I have checked the madura_add_dpd branch and see that the API is upgraded to 7.0.0.14 with many version 2 APIs. Are those APIs what I need to ported to no-OS?

    But does the DPD APIs version 6.4.0.14 works with Linux branch 2023_R2 (Or with current main branch)?

    About the ORx path, I think it's enabled with profile 51_nonLinkSharing. The stream_image and ActiveUseCase_profile has ORx enabled. But the ORx data is just not sent to FPGA through JESD. Is that right?

  • Hi  ,

    ORx is being currently added to no-OS. The API has already been updated. It is recommended to use the main branch.

    Regards,

    G

  • Hi danmois,

    Thank you for your hard work! I checked the commit and have some questions:

    1. Does the DPD API version 6.4.0.14 work with Linux? Or just the new DPD API version does?
    2. Does the current HDL main branch (project zcu102_adrv9026) compatible with this new no-OS? Can I generate the xsa from HDL main branch, and then use this new no-OS API to enable the DPD function?
    3. What is the sequence to enable DPD/CFR using this new API? Could you please provide C/Python code example?
    4. I see that firmwares for both 2 CPUs are changed, but the stream_image is not affected. So I can still use TES to generate custom stream_image and use that image, right?
    5. If I want to still use no-OS branch 2023_R2, should I replace the old API with the new one (all the files that was changed in the last commit)?
  • Hi  ,

    1. Ver. 6.4.0.14 does not include DPD

    2. Current main HDL branch will work with: https://github.com/analogdevicesinc/no-OS/pull/2729 (will be included in the main branch the after review)

    3. Same as in the table you mentioned above in the User Guide.

    4. Yes, although new API version, the old stream_image can be used (new one is the same).

    5. I would recommend main branch. The new API is available only on the main branch. Moreover, the main branch contains fixes/additions that might be missing from 2023_R2 and make things more difficult than they already are.

    Regards! 

  • Hi ,

    Thank you for your information. I will get back to you after checking our custom board with the new API.