Stlink: 尝试闪存到 STM32L052K8 会损坏闪存

这是一个奇怪的问题，我无法立即说出导致问题的原因。 我认为 L1 加载器与 L0 芯片兼容，因为它们几乎相同。

这似乎有点奇怪 - 如果有任何调试标志或我应该打开以提供更多信息的东西，请告诉我。

尝试使用 st-flash 而不是 elf 来刷新平面二进制文件。

尝试将闪存读回文件并进行比较，或使用 gdb 或示例进行检查
x/32x 0x8000000

您应该会看到向量表的开头...
你的二进制文件从哪里来，你怎么知道它是好的？

还考虑到您的地址似乎在 RAM 中，您的 BOOT 引脚的状态是什么？

我会看看 - 无论如何，我一直想学习如何刷新 .bin 文件，而不是使用调试器上传 .elf 文件。

该代码是 ST 的示例之一，但我将再看看向量表所在的位置。

BOOT0 引脚被拉到地，所以我认为它不应该启动到 RAM。

我会在一两天内回答这些问题——谢谢你的建议！

好的，我尝试将 L0 测试程序（特别是 ST 的 LSI 初始化示例）刷入 L031K6 Nucleo-32 板，效果很好。

然而，在 L051K8 上，我仍然观察到这个问题。 主要区别在于我使用通用 USB 加密狗对 L051K8 板进行编程，并使用 L031K6 Nucleo 板的板载 ST-Link/V2-1 调试器。 我尝试更新 USB 调试器上的固件，但这没有帮助。

我验证了向量表在两种情况下都正确放置了arm-eabi-none-nm ： 08000000 R g_pfnVectors

使用st-flash write main.bin 0x08000000将 .bin 文件刷入 L051K8 会引发错误，但仍报告成功。 但是，之后连接到芯片显示程序卡在 0xFFFFFFFE 处。

这是st-flash的输出：

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

但是使用 ST 的 GUI 实用程序查看闪存，我确实看到 .bin 文件的十六进制从 0x08000000 开始； 它看起来像程序开始时的向量表。 并且写入的内存看起来以 0x080047E0 结尾，这对于程序的大小来说似乎是正确的。

我不知道 - 如果这不是其他任何人可以复制的东西，我想它可能是我正在使用的芯片或板。

你好，

蓝丸板（STM32F103C8X）的同样问题
在使用“arm-none-eabi-gdb”的每个程序之后，我都成功了，该程序在板上运行良好，但是当我再次尝试对其进行编程时，我遇到了以下问题：

st-util

[ abdullatif@Host-001 ~]$ st-util
st-util 1.5.0
2018-05-04T23:47:27 INFO common.c：正在加载设备参数....
2018-05-04T23:47:27 WARN common.c：Flash 类型无效，请检查设备声明
2018-05-04T23:47:27 INFO gdb-server.c：芯片 ID 为 00000000，核心 ID 为 00000000。
2018-05-04T23:47:27 信息 gdb-server.c：在 *:4242 收听...
2018-05-04T23:47:40 INFO gdb-server.c：发现 0 个硬件断点寄存器
2018-05-04T23:47:40 信息 gdb-server.c：GDB 已连接。

数据库

[ abdullatif@Host-001 build]$ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
版权所有 (C) 2018 Free Software Foundation, Inc.
许可证 GPLv3+：GNU GPL 版本 3 或更高版本http://gnu.org/licenses/gpl.html
这是免费软件：您可以自由更改和重新分发它。
在法律允许的范围内，不提供任何保证。 输入“显示复制”
和“显示保修”的详细信息。
这个 GDB 被配置为“--host=x86_64-pc-linux-gnu --target=arm-none-eabi”。
键入“show configuration”以获取配置详细信息。
有关错误报告的说明，请参阅：
http://www.gnu.org/software/gdb/bugs/ 。
在线查找 GDB 手册和其他文档资源：
http://www.gnu.org/software/gdb/documentation/ 。
如需帮助，请键入“帮助”。
输入“apropos word”以搜索与“word”相关的命令...
从 Stm32blink.elf 读取符号...完成。
(gdb) 目标扩展远程：4242
远程调试使用：4242
0x00000000 在 ?? ()
(gdb) 负载
加载部分 .isr_vector，大小 0x10c lma 0x8000000
加载失败
(gdb)

如果我要让电路板再次工作，我必须用“st-flash”刷新引导加载程序。

我不相信 F103 问题与我所看到的相同； 这个工具似乎很好地支持它，即使在空白芯片上也会出现 L0 问题。

本期原标题有误，抱歉； 该行为发生在以下两个设备上：

• STM32L052K8

• STM32L082KZ

我看了src/chipid.c ，看到设置只参考了L0x1和L0x3芯片的参考手册； L0x2 芯片有什么主要区别吗？

以下差异似乎完全为我解决了这个问题（使用 STM32L052K8），但我猜这不是一个理想的解决方案：

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

该更改删除了特定于L0特定行为，用于从使用与 ID 0x0417关联的通用L0x3标签标识的芯片进行批量擦除。

我不知道为什么L0特定的逻辑可能会导致这些“Category-3” L0x2芯片出现问题； 它似乎适用于 STM32L031 Nucleo 板，其中芯片的 ID 为0x0425 ，标识为“第 2 类”设备。

STM32L151CC 有类似问题。
它抛出相同的错误并在验证步骤中失败。
使用 ST-Link Utility 手动验证内存显示闪存已正确写入。
设备上未设置读/写保护。

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff ：请验证问题在版本 v1.5.1 中是否仍然存在。

当然，很高兴检查 STM32L0 2 类芯片是否仍然发生这种情况。

不过，我的大部分电路板都存放在自动取款机中，所以我可能要等到 5 月份搬完为止。 对于那个很抱歉。

@WRansohoff ：有任何更新吗？

嗨，我对 STM32L433RC 有同样的问题。
我正在使用 st-util 1.6.1

尝试擦除 MCU 的闪存
使用这篇文章： https :

也许你忘了在 STM32Cube 上标记 SWD/JTAG 引脚