[参考译文] TMS320C6414：McBSP EDMA -问题

请允许我附加两张图片作为问题的图示。

最底部的黄色信号是一个显示 ISR 处理时间的信号。
其他信号包括 McASP0  BCLKX (位时钟)、FSX (FrSyncTx)、DX (TX-DATA)。  

第一幅图像展示了一个良好的情况、显示 ISR 需要大约350ns 的处理时间(包括等待全部3 x 2事件在 CIPR 中挂起)：

在 ISR 中、它等待 CIR 中的所有6个事件都挂起、在正常情况下、几乎同时发生。  

第二幅图说明了一个问题-案例：出于某种原因、ISR 需要更多的时间来处理(846而不是350ns)：

下一帧将完全丢失(请参阅右侧的黄色信号)、保持高电平。  

满载、

您能否澄清一下有关您的系统操作的几个方面？

[引用 USER="malden2507]EDMA 的所有三个 McBSP 端口。 RX 和 TX (REVT、XEVT)通过通用乒乓技术同时处理。[/QUERPLET]

我看到的一种常见乒乓技术是、在前一个数据缓冲区传输完成时、有一个完整的数据缓冲区准备好传输、并在允许填充另一个缓冲区的同时处理一个接收数据缓冲区。 此技术允许完成所有处理的整个128通道帧周期。 您的方法似乎有所不同、您能解释一下您的乒乓缓冲方法吗？

[引用 USER="malden2507]DSP/BIOS 未使用、仅 CSL 和 EDMA_INT (errupt)执行整个信号处理。 EDMA_INT 是应用程序中的唯一中断。[/quot]

此说明听起来好像 DSP 上的整个应用程序正在为 EDMA_INT 提供服务、因此没有其他任何东西可以中断信号处理代码。 是这样吗？

"整个信号处理"的结果是什么？ 这是否会消耗最新的接收数据并生成下一个要传输的数据？ 如果是这样、那么新的发送数据是否会在信号处理所处的同一数据帧内发出？ 这就是我从这样一个事实中暗示的意思：运行 ISR 的时间过长会导致整个128通道传输帧失败。

为了帮助您识别和调试问题、我建议至少有4个可能导致此问题的方面：
正在处理的算法中的某项操作需要额外的一对一时间、这就是导致 ISR 时间延长的原因。 这是不可能的、因为您早就知道了这一点。
EDMA 内部操作因系统中的其他操作而停止。 这可能来自高速缓存活动或内存端点的内存冲突。 从您的系统描述中看、这不太可能、但需要考虑一些因素。
ISR 与下一组 EDMA 传输之间发生了一些交互。 某些关键时序窗口不能满足、因此错过了 EDMA 事件、直到下一帧才会发生数据传输。
EDMA 速度或 DSP 速度无法跟上 McBSP 数据速率。

尝试缩小问题源范围的"简单"操作是改变 McBSP 数据的时钟速率。 如果运行速度慢10-25%，并且问题仍然存在，或者如果问题完全消失，则任一结果都将有助于找到或消除问题的根源。

您还可以尝试改变 DSP 的速度、尽管这通常更困难、尤其是由于存储器时序也发生变化、使其运行速度更快。

还可以尝试降低 ISR 期间执行的信号处理代码中的处理要求。 良好的测试方法是简单地注释掉代码的一部分、并简单地减少处理的通道数。 减少正在处理的通道数量的优势在于代码将仍然具有与之前相同的存储器签名、并且即使处理时间更短、您也可以观察 ISR 持续时间的变化。

每个 TDM 通道的数据长度是多少？

您正在使用哪些存储器目标端点(内部、外部)？

在 ISR 执行时、还有什么正在运行？

在 ISR 的同时、EDMA 的其他用途可能是什么？

这是我提出问题和意见及建议的起点。 我通常会建议 ISR 运行速度更快、EDMA 效率更高、或者修改代码系统架构以留出更多的 ISR 时间。 但是、您的澄清和测试结果将有助于更清楚地指出查看的位置。

此致、
RandyP

Randy、您好！

以下是您的问题的答案。

• 乒乓技术：
  是的、我们确实使用了乒乓技术、但从单个 TDM 通道或时隙的角度来看、缓冲器深度仅为1 (1D 传输用于128通道 TDM、即仅每通道1个样本-为了音频延迟)。 例如、在读取一个128样本帧期间、另一个由 EDMA 填充。
  
  
• 中断 生成：
  我在第一个帖子中犯了一个错误(我同时查看了蓝色的已删除/编辑的部分)。
  应用程序不使用 EDMA 中断、而是使用事件生成的 CPU (XINT)中断。
  发送中断(XINT)模式-由一个新的帧同步生成。
  
  
• 没有其他任何东西可以中断信号处理代码。 是这样吗？
  是：XINT 中断具有最高优先级(另外只有一个具有较低优先级的软件中断)。
  
  
• 可以通过以下方式描述该问题：
  尽管发生了新的 TX 帧中断、但有时/很少会在中检测到任何事件
  EDMA 通道中断挂起寄存器(CIPRL)-传输完整代码(TCC：3x2)未设置！

同时、我们假设外部时钟可能会混乱。

此致、
Malden

Randy、您好！

请回答以下问题(与同一主题相关)：

您对我的以下想法有何看法？

C6000 McBSP 手册提到了意外的接收/发送帧同步、并提供了控制位 RSYNCERR/XSYNCERR 来发出专用的未同步中断。

在 SPCR (McBSP 的串行端口控制寄存器)中、我们通常使用 XINTM (发送中断模式)位：
2h：XINT 由一个新的帧同步生成。
因此、我们为每个(外部提供的)帧提供一个 XINT 中断。

我准备的“测试功能”包括只为其中一个端口准备特殊设置，例如 McBSP2，以使 XSYNCERR“可见”。

我准备了以下“测试功能”。

请确认我是否理解所有内容、以及 XSYNCERR 的 XINTM 设置是否可用于检查外部提供时钟的质量。  

此致、
Malden