[参考译文] CCSTUDIO-THEIA：调试期间、CIO 似乎始终处于启用状态。

尊敬的 Flemming：

是的、您的理解是正确的。 CIO（控制台 I/O）断点分配完全由调试器配置控制、而不是由应用程序代码控制。 调试器 C$$IO$$ writemsg C$$EXIT abort仅在调试设置[1]中启用了“Enable CIO function use“（启用 CIO 功能使用）选项时、才会在两个特殊标签（在中）和（在中）设置断点。 在应用程序中具有 CIO 相关的代码不 会导致调试器自行分配这些断点。 该 .out 文件不受此设置的影响、如您所确认的那样。

在 C28x CPU 上、正好有 两个 可用于断点的硬件分析单元 (AU1 和 AU2)[2]。 CIO 在启用时会消耗 1-2 个这样的寄存器、因此在从闪存进行调试时将其禁用至关重要。 单步执行还需要一个硬件断点、这就解释了在断点用尽时它会失败的原因。

问题：CCS Theia 可能不尊重 AddCIOBreakpointAfterLoad

遗憾的是、 我在 CCS Theia 20.4.1/20.5.0.28 中找不到记录在案的已知问题或修复问题。 但是、证据强烈表明调试器未正确应用 AddCIOBreakpointAfterLoad=0 中的设置 launch.json、即使文件内容按预期更改也是如此。

存在一个相关的先例：在较旧的 CCS 版本（v11.0 及更低版本）中 、调试器在从闪存执行时会自动获取 ERAD 模块的硬件断点所有权，从而防止用户控制 — 这已在 CCS v11.1 [3]中修复。 您的问题可能与基于 Theia 的 CCS 中的回归类似、在这种情况下、无论配置如何、调试器都会分配 CIO 断点。

您可以尝试一下

1.检查其他 CIO 相关设置 launch.json

launch.json 可能并不是控制 CIO 行为的唯一场所。 同时验证：

• “对于 TI 编译器、在程序退出处停止（需要断点）“ —这是一个单独的设置、也会使用硬件断点。 确保 在 CIO 设置[1]旁边取消选中它。
• 检查 .ccxml 目标配置文件 中是否有任何可能覆盖的 CIO 相关属性 launch.json。

2.通过“Debug“视图中的“Program/Memory Load Options“进行验证

在 CCS Theia 中的有效调试会话期间、尝试直接访问调试属性：

• 在 Debug View→ Properties → Debug → Program/Memory Load Options 中右键点击内核
• 确认 未选中“Enable CIO function Use（要求设置断点）“[4]
• 此外、确认 未选中“halt at program exit for TI compilers (require a breakpoint)“

此运行时检查可以揭示调试器是否实际应用了 launch.json 设置。

3.验证 ERAD 模块的状态

由于 F2800157 具有 ERAD 功能、请检查调试程序或您的应用程序代码是否正在声明 ERAD 所有权、这可能会消耗额外的断点资源[2][3]。 如果应用配置 ERAD、则可能与调试程序的断点管理相冲突。

4.将 CIO 代码置于 RAM 中（如果需要 CIO）

当您确实需要 CIO 时、将与 CIO 相关的 RTS 段放入 RAM 中可使调试器使用软件断点而不是硬件断点、从而释放两个硬件断点[1]：

SECTIONS
{
.text:cio : { rts*.lib<trgmsg.obj exit.obj>(.text) } > RAM
.text:rts : { rts*.lib(.text) } > ROM
.text > PMEM
}

5、提交错误报告

鉴于 launch.json 正确反映了您的设置、但调试器不接受该设置、 这看起来是 CCS Theia 回归。 我建议在 TI E2E CCS 论坛上提交一个错误 、其中包含您的 launch.json 内容、CCS 版本详细信息和观察到的断点行为。

为了帮助完善这项建议、了解以下信息会有所帮助：

• .ccxml 目标配置是否包含可能覆盖的 CIO 相关设置 launch.json
• 您的应用代码是否配置 ERAD 模块（这可能独立使用断点资源）

1. TI SDK - CIO 断点要求和 printf 技巧
2. C2000 ERAD — 硬件断点资源
3. E2E 常见问题解答 — CCS 调试器处理的 ERAD 所有权（已在 CCS v11.1 中修复）
4. E2E 常见问题解答 — 在用于 XIP 调试的调试属性中禁用 CIO

此致、

Zackary Fleenor

感谢您的详细回答、Fleenor。

在我最初的问题中 、我并没有很强烈地指出、如果我执行代码并使用 CIO、而 CIO 在 调试属性中被设置为禁用、那么 CIO 输出确实会出现在 CIO 控制台中。 换言之、我相信调试器一直有 CIO 处于活动状态。

一次回答一个项目符号：

1.我可以发现使用断点的所有其他设置已被验证为已被禁用。

2.检查运行设置（右键点击 Debug View→ Properties → Debug → Program/Memory Load Options 中的内核）时 、我会看到   选中了“Enable CIO function use (requires setting set a breakpoint)“、这是意外的。

进一步测试我发现如果我在 main() 有一个断点、然后转到核心并在运行时禁用 CIO（并按“保存“）、那么我的 CIO 调试文本不会出现在 CIO 控制台中、并且允许我设置两个断点。   目前、这可能是一个临时的权变措施、尽管在每次调试运行时这是一个令人讨厌的额外手动步骤。

3.  据我所见,链接的资源,包括[4]都与这个问题无关。 我仔细阅读了所有内容、没有发现任何冲突。 我们不使用 ERAD。

4、请详细说明这一点。 您说的是我看到的内容、可以从闪存执行正常代码、并且只将实际使用 CIO 的函数放入 RAM 中、从而释放两个硬件断点吗？ 这不仅对我们的员工而且对 您的所有用户都非常有用。

我在尝试 下面的时没有注意到什么不同、因此我想我需要一些特殊的方法来配置 CIO、而不会触发断点？

很重要
｛
codestart：> flash_boot

/*将 CIO RTS 处理程序放置在 RAM 中、以便 CIO 可以避免消耗硬件断点。 */
.text:CIO :{ rts*.lib(.text )}> RAMLS0, ALIGN(8)
.text:rts :{ rts*.lib (.text )}> flash_app, align(8)
.text :> flash_app, align(8)

（注意，显然我有时无法将格式化代码插入此编辑器）

5.我相信这是我的 bug 关系。 我可以与 TI 员工分享 launch.json、但不会公开。 请告诉我如何操作。

嗨、弗莱明、

您的后续测试基本上确认了该问题：CCS Theia 20.4.1/20.5.0.28 在调试会话启动时未从 launch.json 中应用 AddCIOBreakpointAfterLoad=0 设置。 即使您的配置明确禁用了 CIO、运行时属性也会显示 CIO checked（已检查 CIO）。 这是调试器端回归。

我们知道的

您的理解是正确的—CIO 断点分配完全由调试器配置控制、而不是由应用程序代码[1]控制。 C28x CPU 恰好有 两个 用于断点[2]的硬件分析单元 (AU1 和 AU2)、CIO 可以消耗其中的 1–2 个。 该 launch.json 文件正确地反映了您的设置AddCIOBreakpointAfterLoad=0()、但调试器在启动会话时将忽略该设置。

关键证据：当您检查 运行时 调试属性（右键点击 CORE→Properties→Debug→Program/Memory Load Options）时、即使在工程配置中被禁用、也会检查 CIO。 这可确认该 launch.json 值未传播到活动调试会话。

您的临时解决方法有效

您发现的解决方法—在中设置断点 main()、然后在运行时核心属性中手动取消检查 CIO 并按保存—可在该会话的剩余时间内正确释放这两个硬件断点。 这与调试器管理 CIO 的方式一致：在 C$$IO$$ C$$EXIT 运行时禁用 CIO 时、在和被删除的断点[3]。

关于在 RAM 中放置 CIO 代码

建议将 CIO RTS 处理程序放置在 RAM 中的原理是：软件断点可用于 RAM 中的代码 （因为 RAM 是可写的）、而 闪存需要硬件断点 （因为闪存在运行时无法使用断点指令写入）[3]。 理论上、如果 CIO 陷阱函数 (,)trgmsg.obj exit.obj驻留在 RAM 中、调试器可以使用软件断点作为 CIO、而不是消耗硬件断点资源

但是、 我无法确认它实际上具体适用于 C2000/F2800157 CIO — 无论代码位于何处，调试器的 CIO 机制可能仍需要硬件断点、因为它使用特定的陷阱机制而不是标准代码断点。 您的测试在将这些段放置在 RAM 中时没有差异、这与这种可能性是一致的。

建议的后续步骤

1. 继续使用手动权变措施 （在每个调试会话运行时禁用 CIO）、直到有可用的修复。

2. 我会将其归档为正式错误。 如需 launch.json 私下分享、您可以使用 TI E2E 论坛上的“发送私人消息“选项、或直接向我发送电子邮件至 fleenor@ti.com。 请提供以下信息：

   • 您的 launch.json 内容
   • 受影响的 CCS 版本 (20.4.1 和 20.5.0.28)
   • 要重现的确切步骤（在设置中禁用 CIO→开始调试→检查运行时属性→CIO 仍处于启用状态）
   • 确认在运行时手动禁用的变通办法可以解决该问题

3. 验证您的 .ccxml 目标配置 不包含可能覆盖的 CIO 相关属性 — 尽管考虑到运行时行为，这几乎肯定是 launch.json CCS Theia 错误、而不是配置冲突。

为了帮助 TI 缩小回归范围、了解以下内容会有所帮助：

• 此问题是否通过最小项目（例如，使用单个空项目）重现 main() printf、以将其与应用程序特定的因素隔离
• 20.4.1 和 20.5.0.28 的确切 CCS Theia 内部版本号（完整版本字符串）
• 早期的 CCS Theia 版本（例如 20.3.x）是否表现出相同的行为、这将有助于识别何时引入回归

1. C2000 ERAD—硬件断点资源
2. C2000 ERAD—分析单元 AU1 和 AU2
3. XIP 调试 — 禁用 CIO 和程序退出断点

此致、

Zackary Fleenor

您好 、Zackary、

我 上周通过私人消息向您发送了请求的文件。

请 提供指向您的公共跟踪器的链接、我们可以在其中关注此问题并为其投票。

尊敬的 Flemming：

可在此处找到机票： https://sir.ext.ti.com/jira/browse/EXT_EP-13385

此致、

Zackary Fleenor

嗨、弗莱明、

我们的 SDTO 团队提出的一些后续问题：

• launch.json 文件是否会为正在用于调试的同一 CPU 内核设置 AddCIOBreakpointAfterLoad 属性？
  
• 如何启动调试会话？ 这是通过右键点击工程并选择“Debug Project“来完成的、还是选择了 ccxml 文件、然后选择了“Start unsigned Debug“？

他们还就 C$EXIT 提供了以下澄清：

C$$EXIT 与 CIO 无关。 有一个单独的设置可配置在 C$$EXIT 处使用硬件断点。 它紧跟在 CIO 设置“对于 TI 编译器、在程序退出时停止（需要断点）“上方。

此致、

Zackary Fleenor

谢谢你。

我刚刚   以私人邮件的形式重新发送 TMS320F2800157-Q1.ccxml 和 launch.json 文件、这次使用.txt 扩展名、因为这些文件显然只是在没有警告的情况下被删除。

问题。

1.据我所见、它是同一个 CPU 内核 — 全部由 CCS 编写。 如果您无法在我共享的文件中验证这一点、请让我知道如何验证/设置这一点。

2. 右键点击工程并选择“调试工程“即可启动调试会话。

关于 C$$exit、 “halt at program exit for TI 编译器（需要断点）“未选中、因此没有分配断点。

也感谢您提供跟踪编号。

此致、

弗莱明

尊敬的 Flemming：

谢谢、我收到了这些文件、我们正在与 SDTO 团队一起审查该问题。 请随 TT 一起跟进、以获取反馈/进展。

同时、我将继续关闭此 TT。 如果您未在 TT 中看到任何进展、请随时创建另一个主题来讨论其他问题或上报。

感谢您的耐心。

此致、

Zackary Fleenor

尊敬的 Flemming：

请参阅 SDTO 团队的以下评论：

此致、

Zackary Fleenor

只是为了 公开完整性。 由于线程临时锁定了几天,我把它写给了 Zackary Fleenor 作为私人信息:

调试时、将工程设置为 DCMaxX (DCmax) ：

  可提供 TMS320F2800157-Q1.ccxml (DDmax) 配置以及同一工作区中的静态库。

我从未看到 选择了 TMS320F2800157-Q1.ccxml 配置、但在调试工程中的文件时、我可以看到所选配置有时会更改为某些静态库。 因此、我已将通过右键点击我要调试的主工程来始终启动调试会话变得非常简单。

功能请求：如果可以将可用调试目标中的工程列入黑名单、那会很好。

Flemming — 您能提供您的 launch.json 文件吗？

忽略我的上一个请求。 我们在错误报告中看到它。

我从未看到 选择的 TMS320F2800157-Q1.ccxml 配置、但在调试工程中的文件时、我可以看到所选配置有时会更改为某些静态库。 因此、我已使它成为通过右键点击我要调试的主工程来始终启动调试会话的基本操作。

在 launch.json 文件中、似乎为库工程创建了几个启动。 不需要自行调试库工程。 您可以手动删除这些启动。

我会删除 launch.json 文件中的所有启动图像、并让 IDE 为可调试的工程生成新的启动图像。

谢谢您、Ki。

我很清楚库工程不是独立调试的、但遗憾的是、CCS 坚持要求每隔一段时间将库添加到启动配置中。 我会定期修整启动配置文件、因为它们不属于这些文件、但我还在寻找一种方法来确保 CCS 不添加它们。

添加似乎是非常随机的,有时只是一个库,其他时候是几个。

如果 CCS 中有强制规则、最好不要将静态库工程添加到启动文件中。

听起来您说、尽管没有显式尝试为库工程启动工程调试会话、但无论如何都会为其创建启动。 是这样吗？ 您的某些可执行工程是否依赖于库工程？

是的、Ki、完全正确。

这也是我同事遇到的问题、因此不仅仅是“我的奇怪设置“。 :-)

我们使用的工程结构在同一工作区中有一个可执行文件和多个静态库。  

可执行文件与库有依赖关系、并且所有库都不具有任何依赖关系。

在调试过程中,通过断点或单步进入库,调试目标（在本例中应该是 DCMaxX (DCmax))  有时会更改为指向显示哪个源代码的库。 我不认为它总是改变启动文件,虽然,但我没有具体测试。

为避免这种意外设置（自然会失败）的后果、我始终右键点击可执行工程并选择 debug（调试）、而不是使用菜单或热键。 （虽然我真的很想念能够安全地使用热键！）

我明白了。 感谢您的确认。

工程部门一直在研究原始问题。 它们似乎无法重现问题。 他们想知道您是否可以完全删除您的启动（可能会删除整个 launch.json 文件，并让调试器重新生成它）、然后重试、当出现问题时、请提供新的 launch.json。

另请注意、CCS 21.0 将于下周初推出。 请尝试使用该版本（如果可用）。