This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:Code Composer Studio
尊敬的先生/女士:
我之前使用的是 CCS 8.3。 迁移到 CCS 9.2时、我无法使 XDS110与 IWR6843板一起工作。 我在9.3中也重复了同一问题。 测试连接始终返回以下故障:
执行以下命令: %CCS_base%/common/uscif/dbgjtag -f %boarddatafil文件%-RV -o -S 完整性 [结果]--- [打印电路板配置路径名]--------------- \TEXASI~1\CCS\ ccs930\0\0\BrdDat\testBoard.dat -- [打印重置命令软件日志文件]----------------- 此实用程序已选择100或510类产品。 此实用程序将加载适配器'jioxds110.dll'。 库构建日期为2019年11月25日。 库构建时间为'16:55:29'。 库软件包版本为'8.4.0.00006'。 库组件版本为'35.0.0'。 控制器不使用可编程 FPGA。 控制器的版本号为'5'(0x00000005)。 控制器的插入长度为"0"(0x00000000)。 此实用程序将尝试重置控制器。 此实用程序已成功重置控制器。 ---- [打印重置命令硬件日志文件]----------------- 扫描路径将通过切换 JTAG TRST 信号进行复位。 控制器是具有 USB 接口的 XDS110。 从控制器到目标的链路是直接的(不带电缆)。 该软件配置为 XDS110功能。 控制器无法监控 EMU[0]引脚上的值。 控制器无法监控 EMU[1]引脚上的值。 控制器无法控制输出引脚上的时序。 控制器无法控制输入引脚上的时序。 扫描路径链路延迟已精确设置为"0"(0x0000)。 ---- [发生了错误,该实用程序已中止]----- 此错误由 TI 的 USCIF 驱动程序或实用程序生成。 值为'-233'(0xffff17)。 标题为"SC_ERR_PATH_Broken (SC_ERR_PATH_COMPLETE")。
解释是 :JTAG IR 和 DR 扫描路径不能循环位、它们可能会被破坏。 尝试扫描 JTAG 扫描路径失败。 目标的 JTAG 扫描路径似乎因 卡在一个位置或卡在零位置故障而损坏。
[结束:德州仪器 XDS110 USB 调试探针_0]
如果我使用相同的.ccxml 文件重试、在 CCS 8中、测试成功。
我已经尝试将 TCK 频率降低到2.5MHz、但没有成功。
在 v9.3中创建新的.ccxml 文件也不起作用。
一些闲置和调试告诉我以下情况。
我在 testboard.dat 上的两个版本中注意到的一点是、在 v8中、子路径_0和子路径_2是反向的、第一个子路径_2、然后是子路径_0、而在 v9.3中、第一个子路径_0、然后是子路径_2。
我可以通过将 iwr6843.xml 从版本8复制到版本9.3来更改它、但没有成功。
另一件事是、对于 v9.3、它包含以下行: debugssm_0 family=debugssm irbits=4 drbits=1 subpaths=2
其中、在 V8.3中: debugssm_0 family=debugsm irbits=0 drbits=0 subpaths=2
您能帮我使调试在 CCS v9.3中工作吗?
此致、
Sjors
Sjors、
遗憾的是、我没有开发板来完成所有验证步骤、但肯定有许多其他开发板在 CCSv9和更高版本中使用了它、没有任何问题。
testboard.dat 文件中的内核交换是大约一年前集成到 CCS 的器件支持包组件中的错误修复的一部分、因此说明了您看到 CCSv8和 CCSv9之间存在差异的原因。
"Path Broken (路径损坏)"错误可能由多种原因引起、包括跳线设置、但由于这适用于另一个版本、我认为这不是问题。
TCLK 速度将是其中一个差异、但对于 XDS110架构而言、2.5MHz 是相当保守的(对于 CCSv8.3、它是默认的)。
我将尝试获取一个基板来测试这一点。
此致、
拉斐尔
尊敬的 德苏萨:
非常感谢您的重播。 我还执行了该测试、发现它运行正常。 这似乎是定制硬件的问题。
此致、
Sjors
尊敬的 德苏萨:
此问题似乎与此设计中未连接的 nTRST 有关。 CCS 8附带的 FW 似乎可以在未连接 nTRST 的情况下正常工作、而 CCS 9.2及更高版本则需要 nTRST。
通过在开始调试之前复位 IWR 芯片、我能够使其正常工作。
XDS200确实有一个用于 nTRST 功能的配置选项。 XDS110没有此 GUI 按钮、是否可以使用 board.dat 文件推送此信息?
您能评论一下这一发现吗?
此致、
Sjors
Sjors、
我不确定我是否完全关注您的帖子、但有几点意见:
nTRST 引脚只复位 JTAG 状态机、而不复位器件。 您可能正在考虑与系统复位相对应的 nRESET 引脚、是这样吗?
在这种情况下、我认为 CCSv8和 CCSv9之间的更改出现在特定的调试设置或器件初始化脚本(GEL 文件)中、而不一定出现在驱动程序上。
请查看 CCS 用户指南的第7.2.4节、检查可能会影响您所看到的这种行为的选项。
https://software-dl.ti.com/ccs/esd/documents/users_guide/index.html
您可以检查器件的 GEL 脚本、这些脚本可能会影响器件的各种复位和初始化状态。 专门针对 AWR/IWR 器件、右键点击 Debug 视图并选择"Show All Cores"。 突出显示 CS_DAP 内核并转至"Scripts"菜单-那里应该有一些初始化函数。
有关每个内核加载的 GEL 脚本的列表、请转到菜单 Tools -> GEL Files。
希望这对您有所帮助、
拉斐尔
尊敬的 Rafael:
在设计中、nTRST 未连接、我知道它与芯片的 nRESET 不同。 但是、对于 JTAG 状态机、触发 nRESET 的效果与触发 nTRST 的效果相同。
在 GEL 文件中、我找不到两个版本之间的任何差异。 我检查了加载的文件、这两个版本都是相同的、并且目录比较显示未对使用的文件进行任何修改。
在加电时、nRESET 保持较长的低电平的平均时间内、这似乎解决了大多数问题。 我可以重新加载固件、而无需对电路板进行下电上电。 我可以多次点击"Target Configuration"视图中的"Test Connection"按钮、而不会出现任何问题。 唯一的故障是在从 CCS8切换到 CCS9时更新编程器固件。
谢谢你们的支持、我的问题现在已经解决了。
Sjors