[参考译文] MSP430FR2355：在 BSL 脚本中发出 SET_PC 0xFFFE 后、处理器不会复位。

将 PC 设置为应用起始地址意味着器件始终不会复位、BSL 的残余配置仍将处于活动状态。 如果您的应用依赖于这些值、则不能保证这些寄存器为它们的加电默认值。

请查看 另一主题。 您可以通过 BSL 进行软件调用的 POR 或 BOR、因为您无论如何都可以将其解锁。

感谢你的评分

换句话说、BSL 脚本程序不会从位置0xFFFE 挑选复位矢量。 这意味着每次软件升级后改变0xFFFE 位置的向量、我必须手动编辑脚本文件(或许是使其自动化)并使用 SET_PC 命令中0xFFFE 位置的向量。

我刚刚检查了 MSP430F5252的 out.txt 文件、保存在0xFFFE 处的地址完全不同(肯定不是0xFFFE)、但是 SET_PC 0xFFFE 在该处理器上完全正常工作。 在此模式下、 5xx ，  当然。 是否存在以下可能性： 模式 FRxx 器件处理方式是否不同？

谢谢 Seth！ "妈的,我知道了。" 我确实确保所有寄存器都设置为已知值、即使 POR 之后再也不信任"默认"值。

我留给最后解决办法的权变措施是看门狗复位。 希望这能起作用。 但是,我不想让一只无限制的狗四处游荡。 我宁愿有一个可靠的地址、也不会改变。

我将尝试此方法 该链接。 谢谢！ 不过、SET_PC 看起来更优雅。 才能将其启动。

尊敬的 ***：

如 David 所说、 0xFFFE 是复位中断表地址、该地址中的内容位于项目的复位处理程序中。 所以、将 PC 点设置为 0xFFFE 不是正确的跳转方式。

为什么不使用指针来读取地址的内容(0xFFFE ),然后将其分配给 PC 指针来实现跳转。

B.R.

萨尔

尊敬的 Seth：

感谢您发送编修。 我应用了正确的顺序后、它在 FR2355器件上具有完美的表现：

@0121
A5
@0120
04
q

但是、即使 PMMCTL0的地址相同、F5252器件上也使用同样的技术失败。

我们将遵循 Sal 的以下建议、对 FFFE 处的向量解析代码并为 bsl-scripter.exe 使用 In Out 定制包装程序

真正错误的是、SET_PC 0xFFFE 在 F5252的任何条件下都能正常工作、即使它是一个错误的跳跃。 这可能是巧合。

您好 ***：

触发复位以退出 BSL 模式更为可靠。

JiaQiang Yao 说：

但是，即使 PMMCTL0的地址相同，同样的方法在 F5252部件上也会失败。

 闪存器件和 FRAM 器件的协议可能存在一些差异、请参阅以下用户指南：

https://www.ti.com/lit/ug/slau319af/slau319af.pdf?ts = 1709871960334

它还描述了两个退出 BSL 模式的方法：

B.R.

萨尔

谢谢 Sal。 我将使这篇帖子暂时保持开放状态、然后在我们缩小范围以找到最终解决方案时将其关闭。 BSL 退出时的复位至关重要、与其说是为了方便远程升级、不如说是为了保持闪存中的数据完整性。

当然、 我将使该主题保持打开状态。

可能值得确认以下几点：

• 将 PC 设置为 位于矢量0xFFFE 的地址 不会导致  MCU 中的 PUC / POR/BOR 复位。 0xFFFE 处的地址是用户软件的入口点。
• 没有可跳转的地址(或在 BSL 脚本程序中设置 PC)导致 PUC /POR/BOR 复位。 因此：
• 在 MCU 中导致复位的唯一方法是：
  • 通过 RESET 引脚进行硬件复位。
  • 在寄存器(看门狗或  PMMCTL0)中放置错误的密码或值
  • 或者说其他方式？
• 在 BSL 编程不安全之后运行用户代码、因为许多外设寄存器已针对 BSL 的使用进行了修改。
• 在 BSL 编程后运行用户代码的唯一安全方法是下电上电或 导致  PUC / POR/BOR 复位。

尊敬的 ***：

是的、这是一个 MCU 中输出 BOR 复位的软件复位、它通常用于跳转到应用代码。

为了触发 BOR、我认为代码中有一种方法：

B.R.

萨尔

请执行。 谢谢！