B5G_UE

【问题描述】UU口上行双流发送PUSCH失败

【问题原因】wola输出天线1的RB位置错位，且偶数符号上的干扰分量非常大,天线0正常。

【解决方案】

【问题验证】

【解决方案】：完成2流的比特与符号级的IDE与在板对数。(思朗的UT无法对比OFDM模块的数据）。通过导出板上数据定位是IFFT4096导致第二根天线异常。

【问题原因】定位是第二根天线ofdm_ifft_inout1_ptr的DM2内存问题，引起IFFT4096第2根天线输出错误。（之前任征挪核解决发现问题单引入的，在ofdm_ifft_inout1_ptr的DM2申请前多加了申请DM2的内存，导致IFFT4096的输入地址对不齐，不符合IFFT4096微码输入要求，导致第二根天线输出异常）

问题1 IFFT4096第2根天线的RB位置不对,错位。
问题2 IFFT4096第2根天线在偶数符号上有非常大的干扰分量。即使IFFT前将第2根天线是输入清0，输出还是有非常大的干扰分量。(之前单流发送时，第二根天线的wola输出有较大分量也是同样的原因，修改后单流时第二根天线输出是0)

【解决方案】将初始化内存申请中ue_Ul_Init_Dm_Malloc中ofdm_ifft_inout1_ptr申请前的DM2内存申请代码删除，放入到DM2申请中。

【问题验证】IFFT4096第2根天线输出正常，问题1与问题2解决，第2根天线的RB位置正确，且偶数符号上不再有非常大的分量。从发端抓射频的2根天线的时域数据显示正常。但基站还是未解对双流PUSCH.

（之前他们解决挪核问题单引入的）

【问题验证】从发端抓射频的2根天线的时域数据，算法仿真能解对。DU log显示SNR是30左右，CRC ERR，升级基站版本抓数，抓数失败，定位中。

抓数失败原因是因为此时终端没有清msg1的buffer，残留的msg1buffer让基站认为一直在收msg1，就会调度很多msg3，基站按第一个pusch crc err抓的crcerr不是终端发的msg3的数据。

重新做基站抓数版本，按照2流并且snr大于20抓数，抓到了2流的pusch crc err的数据。仿真验证，只有天线0有数据，数据位置和抓数的配置参数是一致的，天线3没有数据全部噪声。

连线方式：
TX0-RX0
TX3-RX3
只有RX0有数据，RX3无数据

连线方式：
TX0-RX3
TX3-RX0
只有RX3有数据，RX0无数据
终端抓发送2天线的数据，都有数据且RB位置与参数一致。怀疑第二个天线TX3射频buffer没把数据送给基站。

在发端把天线0的数据，分别放到TX0/3射频buffer发送，基站侧抓数，也只有RX0有数据。

说明tx3射频buffer没把数据发到基站（发端之前在射频抓数，2个TX0/3buffer都是有数的）

【问题验证】在另外一套环境中，发端发2天线数据（卡RB起始与大小条件，收端确认RB参数更能确认是发出来的数据），收端抓取出来是2天线数据。说明是32-44环境问题，之前的44终端TX3buffer中的数据，没能成功发给基站RX3。

环境只验证了一次（发端是打桩全部发天线0的数据，为了验证基站收2天线数据是否都有数据），后基站坏了，待修好后继续验证。

【问题验证】平台的基站修好，使用平台环验证（之前的32-44环境终端的第二个通道有问题）。核对代码，之前L1C给的dmrsport=3,按照协议是port0,2。基站下发dmrsport的是5（bitmap），对应0,2。
走读思朗代码，L1C给的dmrsport=3最终代码算出的port是01，改代码强制改为5，代码算出的port是02，基站能解对2流 pusch.

总结2流问题：
问题1：之前他们合入的单子影响了IFFT4096第二根天线的DM2内存，导致IFFT4096以及IFFTDataTurn的微码输入地址不对齐，导致FFT4096第二根天线输出异常。
问题2：31-93以及32-44环境的终端的第二个通道有问题，不能把发端第二根天线的输出送到基站。
问题3：L1C给的2流的dmrsport的值不对（目前是判断2流，直接写死3），应该按照bitmap方式与基站对齐，去掉打桩并从dci0_1获取。

更换环境和修改L1C dmrs port 打桩写死的部分后， 双流代码自测试通过， 可以转测试， 但需等 bug 5301 解决后再做 研测

使用基站30+终端93上行双流接入ok，udp130M ok

通过验证，问题解决，上行双流发送PUSCH成功。关闭。