STM32 通过引导加载程序闪烁失败 (UART1)

Posted 2023-02-19

【中文标题】STM32 通过引导加载程序闪烁失败 (UART1)

【英文标题】：STM32 flashing through boot loader fails (UART1)

【发布时间】：2017-11-07 11:56:35

【问题描述】：

我有一个 STM32F103，我通过其 UART 端口（使用引导加载程序）使用不同的 MCU远程重新刷新。它工作得很好，我有多个设备已成功刷入正确的代码。但偶尔会出现一个设备停止工作，因为闪存的 STM32 代码不是正确的。整个 bin 文件使用另一个 MCU 刷新，但 STM 被“变砖”（不完全变砖，只是代码错误）。当我使用我的 PC 重新刷新设备时，一切都恢复正常了。为什么十六进制写入STM会失败？

简介：

*使用 UART bootloader 烧写 STM32F103

*有时这种方法会失败，因此 STM 停止工作。

*有没有办法检查写入代码空间的数据是否有效？

*STM 没有变砖，它只是闪存内部的错误代码。当我从代码空间读回闪存时，这比应该闪存的文件小。

*我在系统启动模式下使用STM。 [AN2606]

【问题讨论】：

这是你的引导程序还是内置的？你怎么能把内置的砖砌成一个？这听起来像是一个软件/工具问题而不是一个 SO 问题。您是否编写了自己的引导加载程序和/或工具来与 ST 引导加载程序通信？还是您只是在使用现成的工具？

您好 old_timer，我在系统启动模式下使用 STM，使用内置的引导加载程序。正如我在上面的编辑中提到的，我（刚刚）读回了闪存，发现 STM 闪存代码与我拥有的代码（bin 文件）的大小不同。它似乎短了大约 200（ish）字节。

断点在哪里？是否处于明显的边界？ （闪存块，最后一个完整的消息/数据包不起作用，还是中间一个等？）

更小意味着您读取 0xFFs 该代码应该在哪里？

没有明显的断点。我的第二个 MCU（NRF51822）从 SD 卡读取要闪存到 STM 中的文件，并执行 AN2606 中提到的步骤。我们确保整个文件都被刷新（我们在一个 for 循环中逐个扇区写入闪存）。只有在我们确定整个文件通过 UART 发送后，NRF 才会退出闪烁循环。是的，较小意味着其余数据为 0xFF。我们使用 STLink Utility 读取闪存，读取到闪存中出现 0xFF。

【参考方案1】：

您可以使用 boot-loader 命令读取写入 STM32 闪存中的数据，就像将数据（bin 文件）写入闪存一样。这样，您可以检查写入闪存的数据（或新代码）是否与原始二进制文件相同。只有这两个匹配才能重新刷机成功，否则您可以重新尝试刷机STM32。

【讨论】：

这很聪明。是的，我能做到，谢谢。