[参考译文] TMS320C6657：upp 停止/启动 DMA 问题

谢谢 Yordan、以下是更多信息：

我每次都以相同的方式配置 UPP 和 DMA。 我已经为3个连续运行捕获了 UPP 寄存器值(如下)。  在第一次运行中、UPP 按预期运行、其中我切换测试点以显示 UPP DMA ISR 何时被服务。  输出波形的周期与预期的一样、基于40条线、每条线32字节、大约4ms

下一个迭代、即使我将 DMA 配置为每行32字节的40行(如第一次运行中所示)、窗口中断周期会翻倍至大约8ms、这种行为会持续到我循环通电为止、 在这里、我们可以看到第一次按预期运行、并在后续运行中将窗口中断时间周期加倍。  

下图指示了每个连续迭代所使用的设置。  配置后、启用 UPP 后以及停止 UPP 后(每次运行3组值)、我捕获 UPP 寄存器值。 请注意、我截断了寄存器标签上的 UPP 前缀... IE UPPIA 只是 IA。  

状态寄存器(IS0、IS1、IS2)中有一些线索(我正在假设)。  我现在只是不确定如何对它们进行处理。  我认为每次运行后都需要重置 DMA、以便为每个 UPP 运行启动一个全新的 slate、但我看不到有关如何执行此操作的任何信息。

尊敬的 Eric：

我花了一些时间来捕获具有范围的数据。  今天早上我遇到了一些代码灾难、下午的大部分时间我都要恢复。  我现在正在不断获得 UPP 行为、但这不是我根据自己的设置所期望的(或希望的)。

我使用的是单数据速率。

我添加了一些测试代码、用于启用通道 I 的 EOLI (线路末端中断)  在 ISR 中、当我获得 EOLI 中断时、我只需切换测试点。  话虽如此、我的代码也发生了变化、我看到了以下内容：

1. 首次 UPP 传输
   1. EOLI 每100us 发生一次、它与被选的"UPP_START"信号保持一致。
   2. EOLI 发生40次迭代、产生4ms 窗口中断(也可以通过在 ISR 中切换测试点来验证窗口中断)
   3. 我能够在窗口中观察/计数40个 EOLI 中断
   4. 整个数据块已成功接收(我使用的是测试/计数模式、因此易于验证)。
2. 第二次后续 UPP 传输
   1. EOLI 每200us 发生一次、因为它缺少一条"线"。  我能够查看 EOLI 切换测试点、但它错过了其中一个 UPP_START 脉冲

这是我的"艺术家"对我在示波器上看到的"遗漏"起始脉冲的解释。  请忽略任何极性问题、因为这是当前内存中的问题。  在这些启动脉冲中、UPP 接口确实缺少一个、这一点很明显。

"丢失"的启动脉冲似乎是问题的根源。  是否有任何原因导致 UPP 缺失这些信息？  

我想状态机会识别"UPP_START"信号并适当对齐样本。  我在16位模式下运行 UPP、并且能够验证每个窗口中是否有16个时钟、这意味着在16个时钟下32字节行大小的每个时钟有2个字节 (这是我的 UPP 配置的)。  

下面是用于控制 UPP 的方法。  有3个基本函数

配置：

1. 执行 uppSwReset (通过 UPPCR 使能位使能 UPP)
2. 按照该顺序加载 CTL、ICR、IVR 和 TCR (请注意、ICR 是根据外设用户指南提供的32位单次访问加载)

开始：

1. 对 DMA 进行编程  
2. 启用中断
3. 通过 UPPCR 寄存器使能位启用 UPP

停止：

1. 禁用中断
2. 执行 uppSwReset (通过 UPPCR 使能位使能 UPP)

我对 uppSwReset 有点担心、希望这能解决问题、但我没有运气。  我还在这些函数运行后捕获了寄存器值。  我是下图中的结果。  您将看到三组寄存器设置、其中第一组为配置、第二组为启动、第三组为停止。

我已经稍微修改了源代码、结果没有变化。 我切换到单通道、单数据速率、但我仍然看到缺失的线路。

该线程似乎表示 UPP 状态机需要连续时钟或前后计时。
e2e.ti.com/.../426296

这是准确的吗？

我们有一个 OMAP-L138、它悬挂在同一总线(逻辑 上是相同的总线、但它们是由 FPGA 中的同一源驱动的独立物理总线)。  此 OMAP 在读取非连续样本时没有任何问题。  OMAP 的外设信息/寄存器集看起来与 C6657相同。

Mark、您好！

我在 C6657中的 UPP 实现中拥有的所有文档都表明该器件需要一个连续时钟。 如果您查看输出时钟的说明、您将看到它是一个没有任何输出控制的简单时钟分频器。 SoC 设计人员可能已利用此功能在数据进入器件时对其进行流水线处理。 您是否在两次传输之间没有重新发送 UPP 的情况下尝试过相同的测试？

此致、

Bill

您好 Bill、

我有一些更多信息/详细信息。  

我进行了以下更改。

1. 使时钟保持连续(在我们的 FPGA 中)
2. 在 UPP 驱动器中启用了"启用"行

我仍然得到相同的结果。  

进行了比较

1. 黄色= UPP_START
2. 青色= UPP_ENABLE
3. 品红色= UPP_CLOCK
4. 绿色=针对每个下线中断切换的测试点

此处的捕捉显示了"错过"的启动脉冲：

下面是启动和使能信号的设置和保持时间的图示。  

1. 在每种情况下、每个信号都有足够的时间分配。  
2. 在启动/使能断言时、时钟有一点不连续性、但似乎这不应影响状态机。  在此之前、有大量的时钟。 这种不连续性是不同"采样率"的一个因素、没有一个很好的整数除法来从 UPP 中获取数据。  
3. 在1个完整时钟周期内、Start 为高电平
4. 对于16个时钟脉冲、使能信号为高电平(我们将系统配置为16位接口、每条线路32字节、 这将产生32字节/ 2字节(16位)的每个 upp 时钟= 16个时钟。
5. 另外请注意、尽管 FPGA 中的所有这些 UPP 接口发生了变化、OMAP-L138在正确识别样本方面仍然坚如磐石。  缺少"START 信号"不会出现问题、也不会在配置中使用"Enable (启用)"线路。  
6. 当我尝试在没有在 C6657上配置使能线路的情况下运行时、我在数据库上得到了一组0。
7. 这就像是 C6657无法锁存到新 DMA 线路的 START 信号。  

有什么想法会导致 C6657上的 UPP 丢失这些下线中断、即使所有这些更改都是如此？

我认为"start"信号应该向 DMA 控制器指示它应该开始抓取样本、但它似乎不像我预期的那样工作。  

取得一些进展。

之前、在 C6657软件中配置 UPP 总线之前、该总线处于活动状态(由 FPGA 驱动)。 我发现、如果在配置 UPP 并等待采样(DMA 已编程、中断已启用)之前未启动总线(由 FPGA 驱动)、那么我不会丢失这些启动脉冲。

我觉得 C6657对于 UPP 的运行方式非常挑剔。 OMAP-L138没有单一问题、因为我在调试阶段(没有额外的时钟、到额外的时钟、到连续时钟)。

更新：

在经过一段运行时间后、同样的情况再次发生。  它看起来可能是这个启动条件。  我将继续挖掘。  

您好 Bill、

我有4个任务

2正在解析串行数据(低开销类数据、低 SYSBIOS 优先级= 5)

1处理样本的优先级中等 (SYSBIOS 优先级= 10)

1处理 UPP (从 DMA 缓冲器获取样本、并在 EOWI 之后初始化下一个 UPP 传输)。  这是最高优先级任务(SYSBIOS 优先级= 15)

  UPP ISR 只是将事件发布到此任务。 它根本不会进行任何"重起吊"。

我要做的一件事是、但我不确定它是否"可接受"是对 UPP 进行编程、而不是驱动时钟。  

我配置所有 UPP 寄存器以及中断和 DMA、然后在大约35到40ms 之后、UPP 总线首先驱动使能和启动线路、然后驱动时钟信号(以满足设置/保持时间)。  如您在先前的图中所见、传输会继续进行。  

您好 Bill、

我做了另外一个实验、因为我尝试在 OMAP 器件和 C6657之间对齐窗口中断。  与 OMAP 相比、C6657窗口初始中断(通过切换测试点表示)四处走动。  OMAP 似乎每次运行时都能始终如一地捕获它的第一个窗口。  为了解决此问题、我启用了 EOLI (线路末端 I 中断)、并在传输过程中首次发生 DMA 状态寄存器。

在4次捕获会话后、我看到了以下状态寄存器设置(第一个 EOLI 之后)
注意：我将 UPPIS1寄存器拆分为表示线路计数和字节计数的高16位和低16位

我希望看到线数为1或2。  似乎正在进行"过时"的传输(可能是从上次传输停止开始)。  

1. uppSwReset 不应该清除这些旧状态(重置线性计数)？
2. 我是否可以从 UPIS2获得任何信息、以了解为什么有一些预先存在的行已"转移"？