[参考译文] TMS320F2800157-Q1：DCCAP：在边界条件下无法正确捕捉

您好、Jay、

感谢您的跟进！ 我不能完全确定正在发生什么-或者更确切地说,我可以告诉你似乎正在发生什么,但我不知道为什么它导致了这个问题。

DCCAP 影子功能可能正在 CTR=ZRO 时将值0加载到 DCCAP 影子寄存器中、并且中断触发和 DCCAP 实际读取之间的软件延迟导致 CTR=ZRO 后发生读取。

正如我说过的-我不确定当时 DCCAP 有效寄存器中为什么有一个0。 实际上、我在之前的讨论中没有注意到您的系统启用了 SHDWMODE、这意味着 DCCAP 实际上不应该保存您要寻找的值、直到在 PULSESEL 选择的下一个事件之后。 您的系统行为与我对 DCCAP 的理解不符-我需要花时间进一步调查并确定可能导致这种情况的原因。

您能否提供的配置  DCFCTL、DCCAPCTL 和(如果使能) VCAPCTL 寄存器？ DCFCTL 对我的问题来说是这三个最重要的。

此致、
Jason Osborn
注意：此帖子的要点以粗体显示。

感谢 Jason 的回应。 很抱歉不完整的详细信息。

在我的配置中、中断未启用、我将异步读取 DCCAP 寄存器。 PWM 计数器现在仅处于向上计数模式(之前处于 UP_DOWN 模式)。  

此外、 CAPMODE = 1、并且 CAPCLR 只在从 DCCAP 读取值后被清除。 在一个 PWM 周期内 DCXEVT 只发生一次、且 DCCAPCTL.SHDWMODE = 0。 未使用 VCAPCTL。

由于使用了 CAPMODE =1、PULSESEL 没有任何影响。  

我想我现在已经提供了足够的细节。 如果需要更多详细信息、请告知我。

此致、

Jay、

请注意、如果 CAPMODE=1、SHDWMODE=0、PULDESEL 仍应控制 DCCAP 值何时更新。

只需确认一下、您是否在从 DCCAP 读取值之前检查了 CAPSTS？

第二个问题、DCxEVTy 脉冲的持续时间是多长？ 如果时间过短、可能会丢失。

此致、

Jason Osborn

您好！

1) 1)是的、我正在从 DCCAP 读取值之前检查 CAPSTS。

2) DCxEVTy 与基于该事件的其他操作发生的时间一样长,所以我可以确认它的持续时间不是太短。

谢谢你。 此致、

Jay、

DCxEVTy 操作是通过同步还是异步 DCxEVTy 源执行？ 即 DCxCTL[EVTyFRCSYNCSEL ]= 0 (同步)？ (这是默认行为)。 我想确认捕获控制逻辑的同步没有丢弃任何内容-总体而言、似乎并不是造成它的原因、但最好确认这一点、而不是忽略某个潜在原因。

此外、我是否应该假设 DCFCTL 中到目前为止未提到的任何寄存器、例如 DCFCTL[EDGEFILTSEL]、都是其默认值？

此致、
Jason Osborn

大家好、Jason、

对于我的应用、DCxEVTy 是异步发生的。 并且可以出现在(0+某些偏移)到(周期)之间的任何位置。 如前所述、 仅当 DCxEVTy 在 TBPRD 附近发生时才会产生问题(如果 TBPRD =500、则当事件在480个计数附近发生时、DCCAP 提供错误的值等)。  

不清楚您突出显示的同步块的效果。 (如果您能对此提供一些见解将非常好)

供参考：DCFCTL.ALL = 5； DCCAPCTL.ALL = 1

此致、

您好、Jay、

如果之前没有对齐、同步块基本上会强制信号对齐到时钟边沿。 最简单的方法是在下一个 TBCLK 时钟边沿前将其视为一个缓冲器。 如果信号以与时钟异步的方式发生、这可以缩短信号-在某些应用中这可能是一个问题、但其原因听上去并不是这样。

如果 DCFCTL.ALL=5、则包括 DCFCTL[Blanke]= 1。 DCFWINDOW 的值是什么？

我也要花时间在我的最后做一些测试

此致、
Jason Osborn

谢谢 Jason。 好的、可以着急、慢慢来。  

仅供参考：DCFWINDOW：100计数，PWM 频率：100 KHz，系统时钟：120 MHz。

此致、

大家好、Jason、  

如果您已完成一些测试并有任何更新、请告知我。

我还在寻找好的解决方案。

谢谢你。 此致、

您好、Jay、

很抱歉响应出现延迟。 我已经确认了你在我结束时描述的行为-我希望及时跟踪造成这种行为的原因、并在那时更新您的信息、但我无法做到。 我将与更多的同事取得进展。

此致、
Jason Osborn