[参考译文] CCS/TM4C129ENCPDT：使用XDS110时单步执行速度慢？

您好，

我不确定您的情况可能会发生什么-不久前，我发布了几个特定操作的基准测试，性能相当具有可比性。请查看以下页面中的详细信息。

http://processors.wiki.ti.com/index.php/XDS_Performance_comparison 

只是为了仔细检查，我用不同的程序运行了几个会话(其中一个显示在下面的短片中)，我无法发现任何差异。 我使用的是带有7.4 的Windows 10/64版本1603 -但我不记得任何修复过并影响了此特定设备/调试探头组合的相关内容。  

e2e.ti.com/.../2018_2D00_02_2D00_01_5F00_16h20_5F00_02.mp4

我会继续在这里调查此事，如果我发现任何相关信息，我会报告。  

此致，

拉斐尔

您好，

我刚刚在另一台装有Windows 10/64 Built 1709的计算机上测试了相同的设置，它运行得很好。

此致
拉斐尔

我们是否应该修改上面列出的任何设置？

在我们的设置中，我们还应检查哪些内容？ 例如，在CCS中，在Windows中，在我们的硬件或软件中？

使用XDS110时，单步执行速度极慢，无法解决问题。 我们如何继续？

您好，

我刚刚在另一台装有Windows 10/64 Built 1709的计算机上测试了相同的设置，它运行得很好。

此致
拉斐尔

[/引述]

由于您之前提到您使用的是CCS版本7.4 ．0，我们使用的是版本7.2 ．0，我们继续进行并将安装升级到7.4 ．0。 同时，Windows还安装了一些更新。

然后，我们将程序加载到TM4C129ENCPDT中，并使用ICDI (使用经过修改的EK-TM4C123GXL板)单步执行代码部分。 然后，我们将相同的程序加载到相同的部分，并使用XDS110调试探测器单步执行同一代码段。 我的同事同意，单步执行的速度有明显和显著的差异。 ICDI界面工作正常，每个单步只需很短的一秒时间，而XDS110只需一秒以上，在某些情况下，单步显然需要几秒钟。 这与早期CCS版本的结果相同。

我们查看了XDS性能比较wiki页面，很明显XDS110的性能应该相当好。

我们的配置中一定有一些问题导致了这些问题，但我们无法确定可能是什么问题。

Windows 10版本1709 Build 1.6299万.214
Java版本1.8 ．0_161
代码编辑器工作室版本7.4 ．0.0.0015万

请询问您是否需要任何其他信息。

我将包括我们设置的屏幕截图：

调试速度与固件下载速度相似，使用CC2640 Launchpad (XDS110)，CCS 7.4 ，使用i7 Windows 7桌面。
同一启动板在不同的i7 Windows 10台式机上快速刻录和调试。 我似乎无法发现配置的差异。
缓慢突然出现：Windows 7桌面快速刻录了LaunchPad，直到停止，刻录和调试过程变得非常缓慢。
已尝试切换USB电缆-不好。

可能是12ev12pm提供的屏幕截图提供了足够的信息，使TI员工可以在配置中发现错误。

另外，是否有TI命令行工具绕过CCS和项目配置来测试XDS110通信速度和错误？

我高兴地看到，这一问题终于得到了一些反应，尽管这只是一份关于更多问题的报告。

迄今为止，我未能找到这种缓慢调试的原因。 我让我的老板以任何成本订购XDS110，他对我继续使用ICDI感到失望。 但是在这样缓慢的调试速度下，当XDS110每一步需要10秒以上的时间，而这是ICDI在一小部分时间内步过的功能时，使用XDS110是不可行的。

我们购买XDS110是因为它支持Trace，而ICDI不支持。 我打算再获得几个XDS110，因为(也与ICDI不同)它们具有唯一的标识符，因此每个CCS项目都有一个标识符，每个项目程序都有正确的标识符。 现在，我不得不不断地跳着这一令人沮丧的舞步，打开和关闭电路板，在它们之间插入和拔下ICDI， 打开/关闭CCS项目，因为ICDI没有唯一的标识符，CCS有时会混淆，并从错误的项目中派来高管，这可能会损坏主板，除非我关闭除一个项目之外的所有项目，否则我将进行闪存编程。

所以，底线，这是一个很大的失望，我真的很感谢帮助诊断这个问题。

调试 器中的单步操作在XDS110上非常缓慢。 每个单步执行时间从一秒到几秒不等。

使用 CCS/SIMPLELINK-CC2640R2-SDK中的GEL代码：更快的调试步进？ 要测量使用不同调试探测器在TM4C129NCPDT中对程序执行步进的平均时间，请执行以下操作：

探头	连接	平均步长时间
Stellaris ICDI	JTAG @ 1MHz	44毫秒(测量超过1000步)
SEGGER J-Link	JTAG @ 4MHz	9毫秒(测量超过1万步)
SEGGER J-Link	SWD @ 2MHz	11毫秒(测量超过1万步)
XDS110	JTAG @ 2.5MHz	136毫秒(测量超过1000步)
XDS110	SWD @ 2.5MHz	140毫秒(测量超过1000步)

因此，虽然XDS110比Stellaris ICDI或Segger J-Link慢，但XDS110的平均步长时间仅为140毫秒，比您的情况快。

使用的软件是：

- Windows 10 Pro版本1709 OS Build 1.6299万.248
—CCS 7.4 ．0.0.0015万
- TI仿真器7.0 ．100.1
－SEGGER J-Link支持(Windows) 6.30 ．3.0

我不知道会导致XDS110的步长时间从1秒到几秒的配置设置。

如果您启用 调试服务器日志记录 并发布日志文件，例如XDS110单步执行速度较慢，这可能会确定导致操作速度较慢的软件的哪个部分。

亲爱的切斯特：

感谢您的回复。 尽管您的图表显示XDS110的时间为140毫秒，而不是ICDI的44毫秒，但您认为这不会导致我所经历的明显差异。

我不知道调试服务器日志记录。

在我的下一个调试会话中，我将借此机会收集一些日志信息并将其发布在此处。

再次感谢

大家好，

我在CC1310 Launchpad上使用CCS 7.4 ．0.0.0015万 时遇到同样的问题。 它完全无法使用。 我从调试服务器附加了日志。

此致，

Mikee2e.ti.com/.../6433.ds1.zip

感谢您的回复和发布调试日志。

似乎我们中至少有三个存在这些缓慢调试问题。

我尚未发布自己的调试日志，但该日志在我的待办事项列表中，我将很快发布。

大家好，

请对消失表示歉意。 我在过去几个星期里在这里感到非常的忙，但是昨天和今天我找到了一些时间来测试一些其他的假设和理论。 遗憾的是，现在我无法说出发生了什么，因为我无法在任何主机上再现这种情况。

测试环境和配置包括：
- TI仿真器软件包7.0 ．100.0 与CCDS110固件版本2.3 ．0.11 on 7.4 0
- XDS110单机版，带MSP432P401R，TM4C1294NCPDT，CC3220SF和CC1350
- XDS110嵌入到CC1350，CC1352，CC2640R2F，CC3220SF，MSP432P401R和MSP432E401Y的启动板中
- Windows 7/64，Windows 10/1609和Windows 10/1709，以及Ubuntu 16.04 和macOS High Sierra，但不完整

虽然我没有在步数操作之间获得秒数，但我注意到的可能影响此操作和其他操作的细节如下：
-在后台运行的防病毒/反恶意软件硬盘扫描会影响整个调试体验(启动，终止，程序加载，步骤，内存和反汇编显示，图形等) 这显然会影响系统上的所有其他内容。
- CCS后台进程(如项目迁移，工作区刷新，崩溃报告作业)和C/C++索引器(在较小程度上)导致CCS本身总体减速，但仅在有限的时间内完成这些操作。 在所有这些操作中，C/C++索引器是需要较长时间才能完成的。 这些进程对IDE的时间和影响很大程度上取决于工作空间中打开的项目的数量，以及源文件是本地文件，联网文件还是版本控制文件。
-连接到主机的多个XDS110不会影响步进操作性能。
-数据密集型视图(一个或多个内存浏览器视图，显示多个项目的表达式或变量)的数量和大小会显著影响步骤操作的速度。 与没有任何打开视图的调试会话相比，目标和主机之间的通信量增加时会出现这种情况。
虽然我也测试了C单步操作，但我将所有比较与装配单步操作进行比较，因为它们是准确了解单步操作性能的共同标准。 C中的一个步骤可能会在机罩下执行大量装配操作。
-我没有使用活动ISR测试代码；仅在我过去见过的极少数情况下，它们实际上影响了调试器的性能(而没有任何一个具有Cortex内核)。
-我在设置设备的系统时钟之前和之后都测试了步进操作(在我使用的示例代码中提供此功能时)。 虽然我没有看到明显的差异，但不匹配的配置总是有可能导致调试探测器与设备不同步。

OP显示的屏幕截图上的其他设置不会影响步骤操作的性能。 此外，任何安装的系统JVM都不会影响CCS的运行，CCS本身也附带有它自己的功能，以避免任何潜在的不兼容性。

感谢您发送调试日志。 虽然他们只报告东道方的更高级别的交互，而不是在线的低级交互，但他们可能会帮助将任何其他想法带到桌面上。

如果怀疑电缆或连接有问题，请尝试进行我在以下POST中提到的测试：
e2e.ti.com/.../244.7276万

遗憾的是，此时此刻我真的无法说出发生了什么，但希望调试服务器日志能够为该问题提供更多的信息。 在此期间，我将尝试查看可能导致这种情况的其他条件。

对此造成的不便，我深表歉意。
拉斐尔

大家好，

如果怀疑电缆或连接有问题，请尝试进行我在以下POST中提到的测试：
e2e.ti.com/.../244.7276万
 

[/引述]

我使用 以下命令行运行了dbgjtag实用程序，该命令行是从您上面的帖子中复制的：

C：\ti\ccsv7\css_base\common\uscif>dbgjtag -f @xds110 -RV -o -S brokenpath，Repee=1万

我假设运行此测试需要连接到XDS110的目标。 我第一次在没有目标的情况下运行它，它立即退出，并出现SC_ERR_PATH_BLO肯 错误。 所以我接下来将它连接到我们的开发板。 当我用目标运行它时，它挂起了很长时间(毕竟是1万 测试)并产生了以下输出：

C：\ti\ccsv7\css_base\concif>dbgjtag -f @xds110 -rv -o -S brokenpath，Repe=1万

--- [打印主板配置路径名]------------------

xds110.i

--- [打印reset-command软件日志文件]------------------

该实用程序选择了100或510类产品。
该实用程序将加载适配器'jioxds110.dll'。
库的构建日期为'EC 112017'。
库的构建时间是'12:04:14'。
库软件包版本为7.0 ．100.1。
库组件版本为35.35 ．0.0。
控制器不使用可编程FPGA。
控制器的版本号为'5'(0x0.0005万)。
控制器的插入长度为'0'(0x0万000000)。0万。
此实用程序将尝试重置控制器。
此实用程序已成功重置控制器。

——— [打印reset-command hardware log-file (重置命令硬件日志文件)]------------------

扫描路径将通过切换JTAG TRST信号重置。
控制器是带USB接口的XDS110。
从控制器到目标的链路是直接链路(不带电缆)。
该软件配置了XDS110功能。
控制器无法监控EMU[0]引脚上的值。
控制器无法监控EMU[1]针脚上的值。
控制器无法控制输出引脚上的正时。
控制器无法控制输入引脚上的正时。
扫描路径链路延迟已完全设置为'0'(0x0000)。

——— [在JTAG IR上执行中断路径扫描测试]---------------

此测试将使用64个32位字的块。
此测试将应用1万次。

使用0xFFFFFFFF执行测试。
使用0x0万执行测试。
已正确扫描所有值。

JTAG IR中断路径扫描测试已成功。

——— [在JTAG DR上执行中断路径扫描测试]---------------

此测试将使用64个32位字的块。
此测试将应用1万次。

使用0xFFFFFFFF执行测试。
使用0x0万执行测试。
已正确扫描所有值。

JTAG DR中断路径扫描测试已成功。

C：\ti\ccsv7\css_base\con\cuscif> 

在此期间，我尝试晃动USB电缆，XDS110和目标板，看看松动的连接是否起了作用。 尽管作出了这些努力，但试验还是成功了。

同时，通过搜索我前面提到的SC_ERR_PATH_BREAD错误， 我找到了此e2e帖子：

https://e2e.ti.com/support/arm/automotive_processors/f/1021/t/656760</s>65.676万

这导致了此维客页面：

http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems

该页面未维护，但链接到此页面：

http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html

现在，我正在研究该文档，看看我还能想出什么其他办法。

我将很快检查您提到的其他可能性。

我忘了提及：

除了在电缆摇晃等情况下通过测试之外，我认为连接松动不是问题的原因，因为XDS110的调试速度(每一步所需的时间)一直很慢。 这不是一时的快，而是下一次的慢。

我是否可以使用该目录中的dbgjtag实用程序和/或其他实用程序执行其他有用的测试？

另外，如何确定XDS110的固件版本是否正确？

您好，

>>除了在电缆摇晃等情况下通过测试之外，我认为连接松动不是问题的原因，因为XDS110的调试速度(每个单步操作所需的时间)一直很慢。
我的主要理论是，连接片状会导致过多的数据重试，从而导致数据通信的整体延迟。 我原本希望dbgjtag可能表明这可能是问题所在。

考虑到这一点，我又有了一个想法：如果您的定制主板使用外部电源，您能否验证主机PC电源--> USB端口--> XDS110-->主板-->主板电源-->主机PC电源-->主机PC电源之间是否没有接地回路？ 我已经看到这些接地回路会产生噪音，导致不稳定，有时甚至完全无法连接到设备。 在同一主题中，请注意测试设备(示波器，函数发生器等)的任何接地鳄鱼夹，它们通常与出口处的接地相连。

>>如何确定XDS110的固件版本是否正确？
通常从正确的安装目录发出命令xdsdfu -e。 查看下页的第7节：
processors.wiki.ti.com/.../XDS110

另外两个非常松散相关的想法是：
-更新CCS的TI仿真器组件(转到菜单帮助-->检查更新，您应该会看到一个名为7.0 仿真器．188.0 的组件)
尝试以下页面第4和第6部分中显示的提示：
processors.wiki.ti.com/.../Troubleshooting_CCSv7

此致，
拉斐尔

如前所述，我遇到了类似的问题，但使用的是CC1310 Launchpad。 我现在已在Ubuntu 16.04 LTS上全新安装了CCS 7.4 ．0.0.0015万 ，并且存在相同的问题。 我之前使用的是Windows 10。 一个可能是指针的东西是，我正在使用外部makefile并使用调试器加载生成的.elf。 我将-g标志传递给链接器，以创建.elf中的符号。 我正在尝试使用CCS调试容器应用程序。

此致，

Mike

我们正在研究先前发布的信息，并将很快回来报告我们的发现。

另外，是否有TI命令行工具绕过CCS和项目配置来测试XDS110通信速度和错误？[/QUOT]我不知道。

执行此类测试的一些选项包括：

1)使用调试服务器脚本(DSS)。    调试探测器性能比较的步骤比较是使用DSS执行的。 我似乎找不到使用的DSS脚本，但询问 它们是否在https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/66.8747万中可用。 使用DSS将绕过CSS GUI。

2)使用 通用目标接口(GTI) API创建程序。 刚刚7.0 为CCS 7.4 发布的TI仿真器GTI API.API 188.0 已公开并包含一些示例(请参阅 CCS安装目录>\ccsv7\CCS_base\emulation\doc\GTI_API.zip)。 使用GTI API会绕过CSS GUI和调试服务器，但需要更多的目标硬件知识。