[参考译文] CC2652R7：SysCtrlSystemReset 不会&&#39；始终复位为 BIM、从而导致代码错误

您好 Edward Colby、

您可以将调试器连接到正在运行的目标（无需复位器件）、请按照我们的 SDK 文档将调试器连接到正在运行的目标部分中的步骤执行操作、具体步骤如下。  

调试—SimpleLink CC13XX/CC26XX SDK BLE5-Stack 用户指南 2.2.11.00 文档

谢谢、
Alex F

您好 Alex、

感谢您的回答。

我一直能够按照 SDK 文档并推断它们以连接到 CCS20 中运行的目标（这些文档似乎基于 CCS11.2 或更早版本）。

连接到正在运行的目标是非常有帮助的 — 这是一段时间以来我一直在努力的事情。  

不幸的是,它只允许我观察问题,我还没有找到原因或修复.

发出 SysCtrlSystemReset() 似乎会导致重置、但 SoC 不会返回 BIM 代码。 尽管并不总是会发生这种情况、但我 能够通过与 XDS110 的物理连接到位、电路板自由运行并通过蓝牙触发复位、或者通过按钮服务例程来实现这种连接。

如果我的硬件复位、所有内容都会正确恢复。

将调试器连接到无电目标会暂停目标、让我可以检查状态。
PC 每次在 0x1000118e 停止。 这似乎是一个 BX 指令。
AON_PMCTL.RESETC.RESET_SRC 指示 6 — 按预期进行软件复位。

如果我在调试器中点击“继续“、目标将继续运行、执行 BIM 代码并按预期继续应用。

我已经检查了硬件、LF 和 HF 时钟的行为都符合我的预期。

是否有任何需要从 PC 始终位于该地址的信息？
或者、您可以建议一种解决方法吗？

我们生产了多种产品、此问题可以为我们解释保修问题。 我们将大量推出新产品、直到我了解这个问题后、我才能够发布该设计。

抱歉、向后浏览 ROM 代码可获得更详细的信息：

我们似乎停滞不前的一点是

0x1000118e      BX  LR、带有包含 0x100011d1 的 LR

据此、我推断 ARM 将要切换到 0x100011d0 处的拇指代码。 单步执行这正是接下来发生的情况。

此指令之前是：

0x1000118c   WFI   这是等待中断 NOP、这将解释系统停止的原因。 不清除的是中断是 ROM 代码等待的内容。 如果我们有 ROM 代码的映射、我们可能能够解决这个问题。

此时、这看起来像是 HIB 错误问题。 我的错误,没有阅读足够的这一点之前,得到这很远。 问题似乎与已连接的调试器有关。

您好 Edward Colby、

感谢您的更新、只是为了进行确认、但当您在调试模式之外运行器件时、问题本身不存在？

谢谢、
Alex F

您好 Alex、

我们正在努力确认这一点、但到目前为止、只要我们在任何调试器连接和调用 SysCtrlSystemReset() 之间执行外部硬件重置、我们似乎就没有问题。 这似乎与记录在案的 HIB 问题相符。

我们 担心、我们可能会在现场看到产品出现这种行为。 该产品具有无线充电的电池、可以进入电池几乎为空充电而导致冷启动的状态。 有时、这似乎会导致产品完全无响应。 这种情况下发生率较低、因此很难确定行为的原因。

是否有在 TCLK 线路上提供上拉/下拉电阻以确保线路在启动期间完全受控的情况？或者是否有其他防止生产代码上 HIB 行为的建议方法？ -禁用 JTAG、测试逻辑复位等?

您好 Edward Colby、

我们可以尝试检查的一件事是、是否有任何东西阻止设备通过 SysCtrlSystemReset() 进行预设重置。 如果器件的无线电/电源/时钟或某些外设保持电源域处于唤醒状态、并且未正确关闭、则可能会阻止我们的系统复位、并在持续需要复位状态的情况下“保持“。  

我建议在这里让器件正常运行、直到它无响应、然后使用 XDS110 调试器连接到正在运行的目标、然后检查无线电和您使用的任何其他外设的状态；我们主要是尝试查看是否有任何东西主动阻止复位功能。  

您是否也碰巧有看门狗？

是否有理由在 TCLK 线路上提供上拉/下拉电阻以确保线路在启动期间完全受控？或者是否有其他建议的方法来防止生产代码上的 HIB 行为？ -禁用 JTAG、测试逻辑复位等?[/报价]

如果可能存在硬件问题、我们可能需要创建另一个线程来对此进行调查、以便我们可以指定硬件工程师来提供帮助。  

谢谢、
Alex F