两路McBSP的数据输出存在相对位移的问题，猜测可能与EDMA event Queue有关？

目前采用的开发平台为L138，DSP端采用sysbios，ARM端采用Linux，异常现象出现在DSP端，DSP端需要同时使用McBSP0、McBSP1作为射频数据收发和McASP作为音频数据的收发，相关参数如下所示，这些接口的收发均采用EDMA3 PingPongBuffer方式，DMA数据搬移采用A-sync，信道控制器0，事件队列均配置为队列0。

上述端口主要有以下两个应用场景：

1、采集音频，处理后送入射频，McBSP1_Tx、McBSP0_Tx、McBSP1_Rx、McASP_Rx四个端口会同时开启；
2、射频接收，处理后送入音频播放，McBSP1_Rx、McASP_Tx两个端口会同时开启。

测试过程中发现如下现象：
1、在场景1中，同时开启McBSP0_Tx、McBSP1_Tx、McBSP1_Rx、McASP_Rx时，McBSP0_Tx、McBSP1_Tx两路输出的数据在长时间运行过程中会逐渐产生相对位移，且McBSP1_Tx相对慢于McBSP0_Tx（从DAC和TxPll的输出可以看出波形相对位移，正常情况下两路应该是同步输出的）；
2、在现象1的基础上，关闭McBSP1_Rx后，同时运行McBSP0_Tx、McBSP1_Tx、McASP_Rx不会存在现象1所述的产生相对位移的问题；
3、在现象2的基础上，开启打印调试功能后，存在现象1所述的产生相对位移的问题。

针对该问题也进行了一系列的调试，例如：
1、以现象1为基础，观察到两路的FS是完全同步的，不存在时钟偏移问题，排除了McBSP0_Tx、McBSP1_Tx两路时钟的影响；因此，比较怀疑McBSP数据线送数过程存在delay。由于采用DMA送数方式，进一步分析EDMA的工作机制，考虑事件队列串行输出可能存在阻塞的问题，因此以现象1为基础，将McBSP1_Rx的事件队列安排在队列1（优先级较低），却不会产生现象1的问题，因此判断该问题可能与事件队列阻塞有关。但此时场景2下的McBSP1_Rx的接收似乎不再顺畅，音频播放卡顿，可能是该试验中降低所用事件队列优先级的原因。

2、以现象3为基础，在线仿真观察QxEy寄存器，发现事件队列一直被事件15（SPI0 Transmit）占据，排查后发现，arm端的打印调试功能会在log输出的过程中将log信息存储到flash，在这过程中使用到SPI0，关闭log存储功能后，现象3不再出现，这进一步验证了我们关于事件队列阻塞McBSP0_Tx、McBSP1_Tx数据输出的猜想。

3、为了进一步确认事件队列阻塞数据输出的猜想，我们以现象1为基础，同时开启log存储功能，在线查看了事件队列状态寄存器，发现QSTATn.WM寄存器为3，QSTATn.NUMVAL为0，QSTATn.THRXCD为0，考虑到事件队列长度为16，最多只用到3项，似乎不是之前以为的事件队列占用太多的问题，又或许，即便WM为3，还是会对McBSP数据线产生影响？

4、同时，为何调试过程1中将McBSP1_Rx转到事件队列1后在场景2下会不再顺畅？针对该问题，我们以现象1为基础，开启打印输出，但关闭log存储，并将McBSP1_Rx转到事件队列1进行在线调试，此时事件队列0仍然有较多的事件15（SPI0 Transmit），可能是arm端文件系统有写数据的任务需求，而事件队列1主要由事件4（McBSP1 Receive）占据，可见也确实是在接收，但从最终输出音频结果看却是卡顿的，此时音频McASP仍在队列0，所以应当不会是音频播放的问题，只能是放到队列1的McBSP接收的问题。

根据数据手册，事件队列的优先级不由QUEPRI决定，而是由SYSCFG.MSTPRI1决定，目前系统的EDMA3_0_TC0、EDMA3_0_TC1优先级都已经是最高的了，但两个队列之间的优先级会有多大影响？优先级的工作机制又是怎样的？

因此，结合上述现象和已有的调试过程，请各位帮忙分析测试过程中出现异常现象的根源在什么地方？是否是事件队列的阻塞问题？又是否与队列优先级有关？如果有关，那么队列优先级的工作机制又是如何？在该应用中如何合理安排？还有EDMA的吞吐量极限是多少？

Shuyang Xia：

回复 Tony Tang:

非常感谢您的回复，目前该问题已经解决。

之前由于多个外设使用EDMA的事件队列0，造成一定程度的资源竞争，根据您的建议，McBSP开启FIFO后，该问题得到有效改善。

目前，各个McBSP仍旧使用EDMA的事件队列0，SPI写Flash也依然开启，相之间均不会有影响，正如您所提到的，由于 McBSP的FIFO按32bit word，原16位的数组需要进行扩展到32位，系统的运算负荷略有提高，开启cache后也相应解决。