错误 #320
修改pru 128bit内4个32bit样点排序问题后,测试DU-RU外环回,还有CRC错误较多,X86一秒内就显示接收无数据等现象
由 杨 晋 在 超过 4 年 之前添加.
更新于 超过 4 年 之前.
文件
历史记录
由 匿名用户 更新于 超过 4 年 之前
操作:对ru 9371入口,9371出口数据进行分析
结论:此部分tx/rx时序正常,需要对rx上行其他模块抓数确认 
测试条件:DU-RU测试,使用vio切换到RU外环回。
采集数据:在CRC错误时采集数据AD9371输出的两天线数据,和cpri2ad9371_top模块的输出数据(小包宽度128bit格式,需处理),比较了一个半时隙的数据,可以比上。看了输出小包的头格式也正常。
晓阳画图AD9371输出的两天线数据是正常的,接下来待先在du内部采数分析。
由 匿名用户 更新于 超过 4 年 之前
操作: ru进行slot循环打桩,对ru及du进行rx采数,以及平台rx抓数
现象:
①ru/du slot的计数值可以对应
②平台采数的计数值不可以跟ru/du对应
③对平台非slot打桩,crc错的进行多次采数,发现时域偏移
分析: 问题出现在【fft上游,采数点】之间


由 匿名用户 更新于 超过 4 年 之前
现象:
①经确认,x86采slot打桩数据,均为连续,且0~15359循环,无跳变重复等情况
②打桩模式下,x86采数对应打桩数据不变
③du抓数,天线0/1的打桩计数不同
分析:之前的打桩数据变化或者说时偏变化,应当是切换打桩数据与正常ru外环引起。
计划:
①ru固定上电打桩版本,观察天线间计数差异
②对dma进行抓数
由 匿名用户 更新于 超过 4 年 之前
操作:
天线1的i路打桩0~15359,在ru、du,平台采数
采数结果:
①5次采数,平台的计数相位一致,但前三次时偏0,后两次时偏300多
②发现fh rx 的两个读使能出现不一致
下一步操作:
在ru /du 做统计,
a.前后slot第一点的计数相位变化
b.同天线的样点间,计数相位变化
1、在du统计发现franthaul_rx天线1相位变化。
2、新增加ru cpri入口和du cpri出口的子符号、符号连续统计,天线0和1偏移统计。 发现du cpri出口的天线0子符号有丢失,且和crc错误发生时间对应,此时ru cpri入口统计量正常。基本可判断crc错误是由于du CPRI天线0子符号丢失导致。
3、问题可能性:du fronthaul异常导致反压了du cpri,或 cpri自己异常。 接下来把cpri内使用到的特殊字符AEFE、1004屏蔽掉试试。
版本:ru fpga使用测试版本(天线1的i使用计数器替代,天线0和1的时隙前两个样点的i分别使用7ffe、7fff替代)
du fpga在fronghual的rx_antx_dis子模块增加了对天线0子符号丢失的异常保护,测试有效。 当子符号丢失二十多次,crc仍然是对的(测试了半小时)。
1、用天线0子符号丢弃采集du cpri入口数据(以太ip输出),进行UT测试,发现出问题的子符号包被认做tti数据(且产生很多个tti输出)。
2、查看数据是,自符号包前几个数据是(某一次采样)
90ab1234567890ab
0010feae12345678
0416410100007405
0a088304ffffffff
cc05ac01fa1be6ed
3、把ru上行打桩的天线0 1 i路时隙前两个样点的7fff、7ffe修改为其他值, du丢子符号包问题仍然存在,且现象一样。
crc问题挂起,先定位子符号被认作tti问题。
解决cpri把数据中ffffffff字段误判断tti的问题后,拷机12小时crc正确。
导出 Atom
PDF