[参考译文] MSP430FR50431：如何在启动时自动跳转到 BSL？

是的、您理解正确！ 感谢您的见解。

"即使您这样做、您的应用如何知道在产品投入生产时退出 BSL 并恢复正常运行？ 遗憾的是、FR5x 没有可简化此过程的超时时间。"

我们有一个主单元、可以从传感器读取数据并执行其固件的 OTA 更新。 这意味着器件在我们的应用中可以始终进入引导加载程序、然后在枚举过程中按需退出。 即、器件始终可以在 BSL 中启动、然后主器件会被告知退出。  

当复位矢量为零时、引导加载程序输入的功能缺失、我必须看错了表。


我认为您建议的解决方案不是愚蠢的、而是应该涵盖大多数情况；仍然有一些代码段(例如、复位矢量和编译器生成的代码跳转到 main)、在损坏时、阻止进入 BSL。

如何在自定义段中放置代码？
我查找一些代码、看起来我应该执行类似的操作

__attribute__((section("mySection"))) void foo()

但不确定... 是否有有关如何将函数放置在自定义段中的示例？ 我找不到任何！

编辑：此外、您必须在上载新代码之前执行完全擦除、否则 BSL 会卡住...因此数据仍有可能损坏...

尊敬的 David：

感谢您的回答。 我还有几个问题要问您。

我不确定这是否正确。 BSL 指南指出：

我的意思是、您可以在编程前擦除打算写入的段、以避免需要整体擦除。 我们需要对此进行实验以确认。 请告诉我您是否可以进行此实验、否则我可以进行此实验、并在本周晚些时候返回给您。

如果这确实起作用、那么我们可以考虑修改链接器文件以获得所需的行为。 如果我们无法执行部分擦除/写入操作，那么将  conditionalBSLStart()存储在单独 的存储器位置没有任何好处，您也可以将其放在 main()的开头。

这个主单元是否只有 SDA/SCL 到器件的连接？ 为什么该主器件无法执行硬件调用序列。

此致、

Evan

我们有一个系统、该系统由连接到该单元的主单元和传感器组成。 这些传感器通过 I2C 接口进行连接。 主装置实际上无法访问传感器的任何其他引脚。 这就是主器件无法执行硬件调用序列的原因。  

如果我理解正确、为了不执行批量擦除、我们需要为 BSL 提供正确的密码。 由于此密码与中断矢量表相同、我们需要知道其内容。 这是否随代码变化而变化？ 因为如果不是这样、这意味着代码可能会通过 I2C 转储、并且所提供的安全性极低。 如果它确实发生变化、我们需要跟踪中断矢量表如何查找各个固件 版本。 我想我们可以集成一个脚本、它将解析每个固件版本的 BSL 密码、作为 CI/CD 流水线的一部分、但我们需要以某种方式访问它、整个工作流程变得有点混乱。  

理想情况下、当我们打开电源时、我只需要一些跳转到 BSL 的东西。

这有道理吗？ 我们不能只是注入一个直接跳转到 BSL 的小型汇编代码？  

感谢您向我解释这一点。 只是想确保我们不会意外跳过最简单的选择:)  

您对 BSL 密码正确无误。 它是中断表的前16个字、因此如果您的代码发生变化、以至于中断表发生变化、那么 BSL 密码将发生变化。  

如果您只想在器件启动时跳转至 BSL、为什么不只将其添加到 main 的顶部(或者将其添加到 PRE INIT)？

__disable_interrupt(); // disable interrupts 
((void (*)())0x1000)(); // jump to BSL

此致、

Evan

感谢您的回复！
嗯... 让我来思考一下。

我的主要目标是防止器件的毛皮。  

首先、BSL 会批量擦除整个存储器。 如果在此阶段断电、器件会被惊慌。 我不相信提议的解决方案会如此令人不敢相信！

然后、我们开始刷写器件。 如果在此阶段断电(或出现另一个不可恢复的问题)、则器件会被欺骗 、除非我们实际设法在一切顺利进行的同时刷写主函数。

当然、如果我尝试从引导加载程序跳转到 main、我也会陷入无限循环、因为 main 会跳回到引导加载程序。 我需要跳转至不同的地址来解决这个问题(无 pun 预期)。


显然、我还可以使用可用的 GPIO 仅在启动时有条件地跳转到 BSL。。。 例如：如果主器件同时将 clk 和数据保持在低电平，则跳转到引导加载程序。

我想、如果我还订购了以确保尽快刷写主函数的方式刷写的存储器部分、这将降低数据损坏的风险、但仍然无法完全消除！

一种万无一失的解决方案是能够告诉 CPU 在上电后跳转到引导加载程序。 这是可行的吗？

恐怕不是这样、因为即使我设法诱骗编译器更改入口点、相关的跳转指令也会在整体擦除期间被擦除。

如果这是不可能的、我想我只做我所说的事情、在这里我有条件地从 main 跳转到 BSL。 这仍然意味着90%的代码可能会被破坏、这种情况仍然有效。 我想这是我能做的最好的事情、对吧？ 如果我对操作进行了正确排序、则固件可能损坏的时间应很短...

您是否确认必须进行批量擦除？ FRAM BSL 指南使您似乎可以加载特定区域、如果 您首先擦除这些区域。 我将对此进行实验、因为如果该结果为真、则您可以在 BSL 加载程序不会触及的区域中创建条件 BSL 调用函数。  

如果您需要执行批量擦除、那么您将面临您所讨论的问题。  

Evan

我需要解锁 BSL。 如果我错了、请纠正我的错误、但为了执行此操作、我需要执行批量擦除或提供正确的密码、如前面所述。 提供正确的密码意味着流水线变得复杂、正如我之前所说的那样。  


为了确保我拥有正确的密码、我需要：


-询问设备的固件版本；这已经实现，因此不会出现问题
-交叉参考固件版本和之前构建的 CI/CD 伪影，以获取当前在设备上运行的二进制文件

-调用 Gitlab API 以获取以前构建的工件

-处理伪影、提取 BSL 密钥

-将此密钥发送到主单元以使用它解锁 BSL


这是一场噩梦、我想避免这种情况。

我只会坚持尽量减少出现严重错误的可能性、并在下一个修订版本中修复整个硬件中的问题、除非我们能够提出一些有关如何正确解决问题的绝妙想法。 非常感谢你的帮助！

是的、这似乎有点噩梦

还是等待、是否可以获取 BSL 代码、对其进行编辑、然后刷写固定版本？

我认为，我们确实需要 某种核查。 执行下载的二进制文件校验和的命令、根据提供的校验和对其进行检查、仅当其匹配时才会跳转到应用程序；否则、它会强制器件在复位时始终进入引导加载程序。 我认为这种行为不仅符合我的需求、而且对每个人来说都是非常好的默认行为。

嗯、根据我编写引导加载程序的经验、可以在一天之内完成。 很久以前就应该这么做了、因为在尝试连接原始 BSL 时、解决缺少的文档需要我大约2周的时间。 D：我认为我们将使用原始 BSL 部署设备，然后对定制 BSL 执行 OTA。  

最后一个问题：只需使用 BSL 刷写不同的固件、就可以更改存储器布局(包括各个部分的访问定义)、对吧？ 或者、我是否必须为此使用 MSP-FET 编程器？

非常感谢您的帮助！

正确、这是由由寄存器控制的 MPU 配置定义的。 BSL 和 FET 之间不应存在差异。

Evan