B5G_UE » FirstCall

通过在RFM1的代码打印发现：FAPI_UE_RA_CONFIG_REQ，（0x2c）已经被RFM1的SPU从SM空间取出，已经放入到ring Buffer中，但是运行在APE4 上的L1C，由于运行时间稍有迟滞，导致队列中的消息超过8个，后续的消息取出到非法空间中，导致消息丢失。

uint32_t msg_hdr[8] = {0};
    uint32_t msg_len[8] = {0};
  //从物理层的SM的软队列中出队消息,不是平台的队列
    while(deque_msg_buffer(l1c_que_index, &msg_hdr[msg_in_que], &msg_len[msg_in_que]))
    {
        msg_in_que++;
    }
加大一次性读出消息的个数到16，这和队列的最大长度一致

通过Trace发现L1C已经不工作了，

如果重新编译（添加、删除LOG），大概率 不再出现

L1C入口和出口，分别加统计量，用于判断：
①是L1C中间卡死导致trigger不起来
②还是trigger L1C 本身机制上出现了问题

通过在L1C入口加入口处，处理完 FAPI处和出口处，三个地方加TRACE，方法是每次读出DDR然后加一，存入DDR，通过TRACE捕获，发现入口的TRACE比 FAPI处和出口处多一， 通过二分法，定位到RACH DDR搬移数据的代码和这个现象密切相关。

通过保存在IM空间的全局变量在入口，FAPI处理完和出口处，通过每次执行一次加一的方法，发现三个地方的变量一致，故排除L1C程序被触发后，没有退出的可能性。

现在L1C入口和出口的耗时 直接 加上 PUSCH的耗时约为169 us, 而从L1C入口到PUSCH出口的耗时为 334us,这就是说中间的Trigger时延达到165us,原因待查

通过逐级注销，发现L1C如果不触发PUSCH，APE4核挂死的概率大大降低，目前怀疑点集中在PUSCH和 L1C触发PUSCH两个过程中

在UE_Pusch_Proc_Task0.s.c 文件中函数UE_Pusch_Proc0_Task（）有个对 RF射频DDR清零的代码：memset(DDR_UE_UL_TX0_DATA_ADDR, 0 ,245760); 对DDR的操作要用memset_ext(); 从代码分析看这段代码没有必要。