[参考译文] CCS/TM4C129ENCPDT：调试超时错误

正如海报提到的"20x4"(实际上是4x20) LCD -当"足够长的空闲时间"时关闭 LCD 背光将减少(可能)不需要(不使用时)的电流消耗。

从任何 USB 端口汲取过多电流可能会"损坏该端口"-虽然这非常"方便"- USB 端口在功耗方面受到很大限制-并且一定不能过载！

正如供应商查尔斯所说的那样、"从未听说过也从未看到过此类问题"-我们也有这样的新消息。   受干扰的电源很可能会解决此类问题。

"小心、正确"地配置"实际电源"(这样应用时不会损坏"继续" USB 连接-这种连接可实现调试和编程)证明了确认"正确的电源作为解决方案！"的最佳方法

[引用用户="Charles Tsaaaae">我在论坛中进行了一些搜索、但没有真正找到与您报告的问题类似的相关帖子。我之前已经调查过此错误；请参阅 Cortex_M4_0：错误：等待目标加电/轮询硬件资源时超时。 该错误似乎对使用的调试探针类型很敏感。

我想、当程序运行时、CCS 调试器会定期轮询目标的状态、在某些情况下、状态轮询失败并出现调试错误。

当正在运行的程序在紧密循环中轮询外设时、最有可能从内存中发生错误。

[引述 USER="CB1_MOBILE]]我可以报告、在(超过) 10年的 J-Link 使用(至少5年在日常使用中、仅通过 SWD 过去7年)中、公司/我(从不)注意到任何这样的"超时"[/QUESPLET]回顾我之前的帖子：

a) Stellaris ICDI 出现错误("错误：等待目标加电/轮询硬件资源时超时")

b)遇到 Segger J-Link 错误("错误：STAT [JLINKARM_IsHalted()调用]失败！")

c) XDS110未出现错误。

在 Segger J-Link 的情况下、降低 JTAG 频率的行为似乎使问题得以解决-请参阅 https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/518418/1885271#1885271

[quote user="CB1_MOBIN">似乎确认 Chester 的"调试探针限制"报告是(可能)原因...[/quot]不确定问题是否是"调试探针限制"、而是 CCS 调试器、调试探针和目标上运行的程序之间的交互。 为了获得明确的解释、我认为当错误发生时、我需要尝试捕获 JTAG/SWD 信号。

[引用 USER="Chester Gillon">不确定问题是否是"调试探针限制"、而是 CCS 调试器、调试探针和目标上运行的程序之间的交互。   为了获得明确的解释、我认为当错误发生时、我需要尝试捕获 JTAG/SWD 信号。[/引用]

这两个点你已经介绍了"山顶！"   高度分析-并完美地描述(两者)"问题"(它实际上看起来是"交互")、然后继续指定"真正的诊断方法(捕获并比较(两者)"正常/失败"事务期间的 JTAG/SWD 事务)...  

虽然我的报告(没有提到 w/J-Link 的这种"超时")比传闻要多(很少)，但它是"长期"(建议)，但却未能作为事实得到证实。

根据您的想法(尝试故意"挑起"(不需要的)超时行为)、我们可以加入以使用(两者)供应商的 ICDI 和现代 J-Link 探针创建相同的"紧密循环(轮询) MCU 外设"代码块。    (我应该能够同时运行至少3个 J 链路-通过不同的 PC -连接到3个'123 LPad.")    这似乎(合理地)具有结论性意义，可以确定通过不同的调查所引入的"有罪程度"(如果有)。   (虽然我们的系统已预先设置为 SWD (仅限)-我们已"解放"了其他2个用于 GPIO 的引脚...)

正如您和我在这里已经注意到的、该供应商的 MCU 似乎(不好意思)特别容易出现"JTAG 丢失"的情况。   (然而、无论是通过"技能"、运气、还是我们独家使用的"J-Link & SWD"、Fire/I (几乎)从未记录过此类问题。)   

我曾认为、专门创建各种"JTAG/SWD "事务-可能会让人对"是什么触发了 JTAG 丢失？"有深入的了解   (除了微不足道的事情、"PC0-3的重用 和对 SysClock 的计数。")   同样、通过数字的力量、我们的"独家"J-Link 使用似乎"抵制"了这个问题、但我们却读到(无休止地) ICDI 用户成为受害者。   (虽然... "罗马睡觉" (发誓我听说(有人)说...)

如果能够识别"JTAG 故障触发器"并开发出(部分)防御、则会对许多人"有所帮助"。    (或者我们可以花时间/精力来"像销毁一样！" (笑声) (笑声)  然而-这已经完成了。)

[引用 user="Chester Gillon">回顾我以前的帖子：

a) Stellaris ICDI 出现错误("错误：等待目标加电/轮询硬件资源时超时")

b) 遇到 Segger J-Link 错误("错误：STAT [JLINKARM_IsHalted()调用]失败！")

c) XDS110未出现错误。我使用以下软件进行了另一种查看：

- Windows 10下的 CCS 7.3.0.00019
- TI 仿真器7.0.48.0
- SEGGER J-Link 支持(Windows) 6.20.9.0

虽然之前显示错误的程序是"在紧密环路中轮询外设"、但它也是以115200波特连续输出来自 UART0的数据。 创建了随附的在 EK-TM4C1294XL 上运行的示例、并通过调用 TivaWare UARTCharPut()在 UART0上输出连续字符。 其中、目标 TM4C1294NCPDT 上的 UART0连接到板载 Stellaris ICDI 上的"Stellaris 虚拟串行端口"。  e2e.ti.com/.../TM4C129_5F00_peripheral_5F00_poll_5F00_tight_5F00_loop.zip

结果是：

结论是：

a)之前曾遇到"错误：STAT [ JLINKARM_IsHalted()调用]失败！" 2016年6月、使用 CCS 6.1.3、使用最新的 CCS 7.3和 Segger J-Link 不再重复该错误。

b)使用最新的 CCS 7.3仍可通过 Stellaris ICDI 获得"Cortex_M4_0：错误：等待目标加电/轮询硬件资源时超时"、但仅当 Sellaris 虚拟串行端口也被用于接收来自目标的串行字符时。 因此、怀疑错误的原因是 Stellaris ICDI 固件和/或软件驱动程序。

非常感谢-非常"干得好"并进行了报告。

请注意、每个调试会话的"持续时间"可能会起作用。   (海报仅列出"跑了一段时间后"、这就剥夺了他人(完全)复制他的报告的机会...)

从正在进行的报告中、"JTAG 已丢失"报告-到目前为止、这是需要注意的领域。   (并继续明显避免(赦免)、这使得"低悬果"(例如禁止激励性"相似")(不必要/不合理)能够吸收供应商时间/资源。)

您今天的报告使供应商的 ICDI 实施受到怀疑-也指出了 ICDI、因为它"主要可疑"导致可怕的"JTAG 丢失/锁定"。    同样、在(近)日常使用中具有五个 J-Links -我不能忘记我们最后一个、"JTAG/SWD 锁定！"   (公平地说、我们的用法通常通过 SWD 来实现、并且我们(正确的)使用4家供应商的 ARM MCU。然而、'4C123每天(接近)都在使用。)

[引用 USER="CB1_MOBIT)]请注意，每个调试会话的“持续时间”可能会起作用。   (海报仅列出了"运行一段时间后"-这就剥夺了他人(完全)复制他的报告的机会...)在对多少个调试会话执行测试时遇到"Cortex_M4_0：错误： 等待目标加电/轮询硬件资源时超时"错误、设置运行的程序后、使用 CCS GUI 手动刷新 UART0寄存器约一分钟、然后停止并开始另一调试会话。

在 Stellaris 虚拟串行端口打开的情况下使用 Stellaris ICDI、使程序在 CCS 调试器中运行、CCS 调试器以2Hz 的频率对计数器进行采样(这在目标继续运行时使用 DAP 通过 JTAG 访问存储器)。 在该测试中 、在运行几秒到18分钟后出现"Cortex_M4_0：错误：等待目标加电/轮询硬件资源时超时"错误。

为了尝试确定问题是在 Stellaris ICDI 固件中、还是 CCS 调试器将测试程序移植到了 IAR Embedded Workbench for ARM 8.11.2 (免费代码大小受限版本)下运行。 该程序在过去的四个小时内无误地运行、并在 Stellaris 虚拟串行端口上输出。 然而、当 IAR 与 Stellaris ICDI 一起使用时、当目标正在运行时、无法访问存储器、"Live Watch"选项呈灰色显示。 因此、使用 IAR 进行的测试没有结果、因为不确定 IAR 调试器是否在程序运行时执行 JTAG 访问。