项目

一般

简介

错误 #2760

3.0 DPD 校准问题debug.

由 梁 佐庆 在 4 个月 之前添加. 更新于 3 个月 之前.

状态:
已关闭
优先级:
高
指派给:
梁 佐庆
开始日期:
2025-02-05
计划完成日期:
2025-02-08
% 完成:

100%

预期时间:
20.00 小时

描述

在3.0 DPD集成过程中，遇到TX3->ORX3相位delay校准不通过得情况。 偶然发现有一个线索，2T2R的版本的第一路可以通过。然后就顺藤摸瓜，用2T2R的环境改成其它路的TX到ORX的，最后结果是校准通过。2T2R的程序可以在EVMT4上运行，所以怀疑4T4R的程序有冲突的地方。挨个文件比较。最后发现MASK和tracking的MASK不一样。
切换到4T4R，按照规则换成2T2R的类似配置，然后验证校准通过。
问题转到我本人的下一个开发步骤，验证通过DPD校准的情况下，DPD是否能收敛。

历史记录

#1

由 高 峰 更新于 4 个月 之前

可以描述一下，这个问题是如何产生的或者引入的，比如基线代码如何，不适配我们的硬件平台，还是我们修改其他特性的时候引入了这个问题

#2

由 梁 佐庆 更新于 4 个月 之前

  • 状态 从 新建 变更为 已解决

这个问题和tracking顺序有关，改成和2T2R一样的tracking顺序，问题解决。

#3

由 高 峰 更新于 4 个月 之前

  • 跟踪 从 任务 变更为 错误
  • 状态 从 已解决 变更为 进行中
#4

由 梁 佐庆 更新于 4 个月 之前

  • 状态 从 进行中 变更为 已解决
  • % 完成 从 90 变更为 100

1）tracking在初始化完成后应该关闭。和2T2R一样。
//adi_adrv9025_TrackingCalsEnableSet(adrv9025Device, 0x100FFFFFF, ADI_ADRV9025_TRACKING_CAL_DISABLE);
//adi_adrv9025_TrackingCalsEnableSet(adrv9025Device, 0x1100, ADI_ADRV9025_TRACKING_CAL_ENABLE);
2）tracking打开也和2T2R一样：
int32_t dpdTrackingCalEnable_TX3 (adi_adrv9025_Device_t *device, int enable ){
printf("Enabling DPD Tracking Cal on TX3\n");
recoveryAction=adi_adrv9025_TrackingCalsEnableSet (device, ADI_ADRV9025_TRACK_TX3_DPD, ADI_ADRV9025_TRACKING_CAL_ENABLE);
adi_adrv9025_TrackingCalsEnableSet (device, ADI_ADRV9025_TRACK_TX1_DPD, ADI_ADRV9025_TRACKING_CAL_DISABLE);
adi_adrv9025_TrackingCalsEnableSet (device, ADI_ADRV9025_TRACK_TX2_DPD, ADI_ADRV9025_TRACKING_CAL_DISABLE);
//adi_adrv9025_TrackingCalsEnableSet (device, ADI_ADRV9025_TRACK_TX3_DPD, ADI_ADRV9025_TRACKING_CAL_DISABLE);
adi_adrv9025_TrackingCalsEnableSet (device, ADI_ADRV9025_TRACK_TX4_DPD, ADI_ADRV9025_TRACKING_CAL_DISABLE);}
修改上述两个地方，校准问题得到解决。

#5

由 梁 佐庆 更新于 4 个月 之前

问题的根本原因是：思朗的tracking次序做DPD时应该进行上述修改。

#6

由 高 峰 更新于 3 个月 之前

  • 状态 从 已解决 变更为 已关闭

导出 Atom PDF