【发布时间】：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。
标签： embedded stm32 bootloader