[参考译文] CODECOMPOSER：调试速度极慢

更新：我发现其他似乎也会遇到此问题的线程：

e2e.ti.com/.../msp430f5529-ccs-debug-window-slowing-micrcontroller-clock

e2e.ti.com/.../ccs-msp430g2553-clock-speed-is-different-when-debugging

第二个链接特别有趣。 他们能够找到速度减慢的原因：在调试视图中、启用了对 CPU 周期进行计数的时钟。 禁用时钟解决了它们的问题。

我尝试在调试视图中禁用时钟、这样也解决了我的问题。 我将返回到正常速度运行。 但这是 TI 应研究的一个错误。 为什么显示 CPU 周期数会导致程序执行速度异常慢？

尊敬的 Adevries：

遗憾的是、这不是 CCS 的一个错误、而只是 MSP430器件上所执行调试系统的固有属性、这是因为它具有很高的侵入性。  

您好！

我无法向您指出这一点、因为有多个因素会使调试速度变慢。 JAG 连接上的 SBW 当然是一个因素、因为 SBW 只是与 JTAG 拼接在一起的时间、所以本质上速度要慢得多。 您使用的调试工具在 JTAG/SBW 连接速度方面存在限制、而且噪声特别大/电容式 SBW 连接也需要降低速度。 这些线路上的调试通信量可能会成为一个因素、这就是关闭 CPU 时钟周期计数可以加快速度的原因。 调试具有侵入性、因此它会使 CPU 时钟速度变慢。 无论频率设置如何、我始终估计出1MHz 的有效时钟频率、但结果可能会有所不同。 此外、由于侵扰性、设备中的所有组件都有机会在很长一段时间内(相对于 MCU)进行同步、因此如果您启用了大量中断、则它们将全部堆叠在各个之上、随时可执行、 这可能会导致您无法返回到主循环。 您还可能会在代码内遇到竞争条件、如果调试未激活则不存在。您可以通过使用自由运行模式而不是一个断点来限制这个效果。  

您好！

我当然可以看到、由于这里的相对时间刻度、情况确实如此。 与 设备的时钟周期时间相比，SBW 事务需要很长的时间，并且设备可能 在消息之间停止，这取决于您是否混乱断点。 减少 SBW 流量应该会有所帮助。

您还可以使用具有自由运行模式的断点来跳过某个耗时的部分、或仅在您关心的程序部分进行调试。 或者、对于需要调试其他时序关键方面的部分通信数据包的情况、我建议不要使用调试器、而是使用"GPIO 调试"来确定 代码中发生了什么情况。  

Jace、您好！

我比较了在显示 CPU 时钟周期和不显示 CPU 时的 SBW 流量、在显示 CPU 周期时看到的流量约为24倍。 太疯狂了。

好吧,我想我确信:显示 CPU 周期会显著增加 SBW 流量,如果你的 SBW 已经运行缓慢,它会使事情明显变慢。

我对此有两个跟进问题：

1.如何确定 SBW 的通信速度? 是否在调试器每次尝试与 MCU 通信时进行了协商？ 它是 Code Composer Studio 中的设置吗？ 还有其他问题吗？

2.除了显示 CPU 周期外，是否有其它调试功能可以显著增加 SBW 流量？ 打开内存浏览器之类的东西不应影响平均执行时间、因为这不会不断更新、只有在程序暂停时才会更新、对吧？

您好！

SBW 速度为标准速度、可在 CCS 中选择、但如果所连接的调试器未指定、则会自动协商。  

我无法提供完整的列表、但任何高级调试功能都会增加流量。  

为什么像计数 CPU 周期之类的东西会导致~500倍的减速？

我的理解是、对于 MSP430器件、有两个用于计数 CPU 周期的选项。

1.使用 目标器件内嵌入式仿真模块(EEM)中的周期计数器、当 MSP430在断点间全速运行时、可以由 MSP430计算 CPU 周期数。 例如、 MSP430x5xx 和 MSP430x6xx 系列用户指南(修订版 Q)的"EEM 配置 "部分显示 MSP430x5xx 和 MSP430x6xx 系列包含一个周期计数器：

2.如果 EEM 不包含周期计数器、则调试器必须通过一次单步执行 MSP430一条指令来计算 CPU 周期数、并提供查找表来确定已单步执行的每条指令的周期数。 MSP430F2xx、MSP430G2xx 系列用户指南(修订版 K)的 EEM 配置部分 没有提到周期计数器：

即、对于 MSP430F2274-EP、我认为是 EEM 中没有周期计数器、这会在 CPU 周期计数器被启用时导致运行速度极慢。

我在调试固件时多次使用 CPU 周期计数器，以前从未遇到过此行为。

它是在哪个设备上？