Other Parts Discussed in Thread: UNIFLASH
器件型号: MSPM0G3519
Thread 中讨论的其他器件: UNIFLASH
我的应用中需要由软件触发的 POR 复位来执行固件更新、但是当触发软件 POR 时、电路板不会重新启动。
我还使用看门狗进行了测试、以强制复位、但行为是相同的:器件保持锁定状态、只有在完整下电上电后才能恢复。
当电路板处于该锁定状态时、连接调试器会显示调用堆栈指向 0x100000xx 范围中的地址。
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.
Other Parts Discussed in Thread: UNIFLASH
器件型号: MSPM0G3519
Thread 中讨论的其他器件: UNIFLASH
我的应用中需要由软件触发的 POR 复位来执行固件更新、但是当触发软件 POR 时、电路板不会重新启动。
我还使用看门狗进行了测试、以强制复位、但行为是相同的:器件保持锁定状态、只有在完整下电上电后才能恢复。
当电路板处于该锁定状态时、连接调试器会显示调用堆栈指向 0x100000xx 范围中的地址。
尊敬的 Owen:
通过 CAN 收到命令后、应用程序会显式调用 DL_SYSCTL_resetDevice(DL_SYSCTL_RESET_POR)。
调用后、电路板似乎已关闭、但不会重新启动。 器件在 CAN 上停止通信、并且不会恢复执行。 如果让看门狗过期、我会看到完全相同的行为。
当器件处于此状态时、连接调试器并加载符号以了解执行受阻的位置。 当我停止核心时、调用栈指向类似的地址 0x010026AC。 如果我尝试重新启动调试会话、 Reset_Handler 永远不会执行(不会达到置于复位处理程序上的断点)。
关于 RSTCAUSE:我通常在初始化过程中读取 RSTCAUSE 寄存器。 但是、在这种情况下、器件在看门狗或软件 POR 后永远不会重新启动、因此执行永远不会到达初始化阶段。 因此、发生这些事件后无法读取 RSTCAUSE。
系统使用的外部高‑频率时钟是 40MHz 。
您好、David:
您使用的高频时钟在规格范围内、因此我不怀疑原因是这样。
使用 DL_SYSCTL_resetDevice () 发出复位命令的逻辑是什么? 我想知道应用程序代码是否反复发送 POR 并导致器件锁定?
设备处于该状态时、能否读取该设备的诊断代码? 为此、您可以在 CCS 中启动无工程调试:
我创建了一个示例、用于在 RSTCAUSE 是软件触发的 POR 时使 LaunchPad 上的绿色 LED 闪烁、您可以找到所附的示例代码。
e2e.ti.com/.../por_5F00_reset.c
e2e.ti.com/.../por_5F00_reset.syscfg
此致、
Owen
您好、
关于复位逻辑:这非常简单。
当收到特定的 CAN 命令时、我根据操作码输入切换情况、在这种情况下、我直接调用 DL_SYSCTL_resetDevice (DL_SYSCTL_RESET_POR)。
为了排除反复发出 POR 的可能性、我还尝试了在重置调用后立即添加 while (1)、但行为不会改变。 因此、从应用程序的角度来看、只应触发一次 POR、以响应该特定的 CAN 操作码。
我还按照您的建议执行器件诊断代码读取、当电路板处于锁定状态时、在 CCS 中进行无工程调试。
在“GEL Output“选项卡中获得的输出为:
CS_DAP_0:尝试 CS_DAP 连接
CS_DAP_0:器件诊断读取= 0x0004210A
我还想补充一点、过去我已经专门使用 LED 执行了一项测试、以验证复位行为。
在软件触发的 POR 之后、LED 不会再次开始闪烁、表明应用程序在复位后不会恢复执行。
您好、David:
器件诊断读取解码如下:
0x0004210A:错误类型-->引导加载程序调用状态
0x0004210A:调用状态-> BSL 引脚
0x0004210A:引导错误-->无效
0x0004210A:引导阶段-->引导加载程序启动
这让我想知道您是否使用辅助引导加载程序、以及它是否可能在固件更新期间被擦除/修改。
此外、您是否打算在发出软件触发的 POR 后调用引导加载程序?
此致、
Owen
您好、
但是、当前测试的固件中未启用此行为。 目前、我正在运行一个仅调试的固件、其中 未启用 CSC 策略、未启用闪存交换策略、不 存在辅助引导加载程序。
使用这个固件、我期望在软件触发的 POR 或看门狗复位后、MCU 只需重新启动并再次开始执行主应用程序、就像标准复位一样。
您好、David:
指向 0x010026AC 的调用栈意味着该器件位于引导 ROM 中、因此它可能正在运行或尝试在该器件上运行默认的引导加载程序。
您能否检查一下存储器区域在 0x00000000 处的样子(矢量表)。
此外、如果您无意进入 ROM 引导加载程序、请确保不要将 PA18 悬空或将其拉高。 这可以完全解决该问题。 使用的是定制电路板还是 LaunchPad (EVM)?
是否使用引导加载程序插件?
如果您说关机后再开机解决了问题、则设备是空的还是已发布固件更新?
此致、
Owen
您好、
感谢您发送编修。 我最终理解了问题的可能根本原因:复位期间的 BSL 引脚行为。
在我们的定制电路板上、PA18 配置为输入并通过串联电阻进行路由。 这意味着它可以在复位期间悬空并被采样为高电平、可能会调用 BSL。 我将评估在该引脚上添加一个‑Ω 下拉电阻器的情况。 同时、我通过禁用 BSL 解决了问题;或者、启用快速引导模式也可以解决问题。 使用这些设置、POR 和看门狗复位现在都能正确地重新启动电路板。
剩下的问题是、在禁用 BSL(或启用快速引导)的情况下、即使仅连接和加载符号时、调试也不再起作用、这在修改 NONMAIN 区域时通常是必需的。
禁用 BSL 时、是否有方法进行调试?
您好、David:
在禁用 BSL 的情况下、您应该仍然能够进行调试。
需要澄清的是、您是否注意到在发出 POR 后调试似乎不起作用? 在这种情况下、POR 会将器件与调试器断开、因此您可能需要重新连接。 下面是我调试和运行我之前分享的代码后的 IDE 屏幕截图:

如果情况并非如此、您能否详细说明调试器如何无法工作? 是否加载了不正确的符号(由于已发出固件更新)?
此致、
Owen
您好、
感谢您的澄清。 我来更好地描述一下我遵循的确切顺序以及故障发生的位置。
首先使用 UniFlash 执行批量擦除、然后使用选项“Erase main and NONMAIN memory“对固件进行编程。 完成此步骤后、电路板将正常运行并按预期运行。
然后、在 CCS v20 中、打开 Target Configuration 并启动 Project‑less Debug。 当我尝试连接到目标(如你的屏幕截图所示),几秒钟后,我总是得到以下错误:
JTAG 通信错误:(错误–615 @ 0x0)目标未能看到正确格式化的 SWD 标头。 与目标的连接可能不可靠。 尝试降低 TCLK 设置、然后重试。 (仿真包 20.4.0.3756)
您好、David:
在我之前发送的示例代码中、一旦发出软件触发的 POR、就会看到此消息。 但是、之后我可以连接。
能否确保在 NONMAIN 配置中保留这些设置以允许调试:
我还会确保您退出 Uniflash。 在 CCS 中连接到 Uniflash 时、无法连接到器件(反之亦然)。
此致、
Owen