Question

tl; dr：将固件刷新到0x00000000而不是0x08000000，我输了吗？

您好，

我的设备基于STM32F103CBTx，它带有专有固件并具有读取保护功能。我通过连接到PA13和PA14的ST-Link v2 SWDIO和SWCLK连接到此命令：

sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg

我不记得我是如何移除闪存保护的，但它起作用，因为原始固件不再起作用了。然后我创建了一个简单的hello world固件，它可以上下拉动三个gpios并闪烁它。 gpios以700毫秒的间隔上下拉动。

闪烁后，我再也无法连接openocd了。我忘了指定偏移量，手册说偏移量默认为0，因为它工作，我想而不是引导加载程序，我的糟糕的hello世界正在快乐地拉上一些随机引脚......这可能吗？我发现的所有其他线程都说引导加载程序是写保护的。

这是我的最后一次接触：

> halt
halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
> flash write_image erase fw.hex
flash write_image erase fw.hex
auto erase enabled
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 4096 bytes from file fw.hex in 0.285697s (14.001 KiB/s)
> reset
reset
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms

高度赞赏任何指示。

编辑：我现在得到的，还尝试了另一个st-link：

%  sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg 
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.244356
Error: init mode failed (unable to connect to the target)
in procedure 'init' 
in procedure 'ocd_bouncer'

Answer 1

将固件刷新到0x00000000而不是0x08000000，我输了吗？

不，这根本不重要，它们是一样的。

复位后，MCU加载0中地址SP的字，以及4中地址PC的下一个字。 BOOT0和BOOT1引脚控制哪个内存映射到0x00000000。通常，BOOT0为低电平，0x08000000的闪存在0x00000000处镜像。

而不是引导加载程序我的糟糕的hello世界正在快乐地拉上一些随机引脚......这可能吗？我发现的所有其他线程都说引导加载程序是写保护的。

工厂bootloader确实是写保护的，openocd不能覆盖它。

但是，您的应用程序可能通过在SWD或GPIOA->CRH中写入错误的值来重新配置AFIO->MAPR引脚，从而阻止openocd工作。这是导致这个问题的最常见原因。

幸运的是，有一种方法可以恢复。

重置后连接

如果在启动openocd时控制器的复位引脚保持低电平一段时间，则会阻止应用程序启动，并弄乱GPIO配置。

当

时，Openocd可以自动执行此操作

告知这样做，行reset_config srst_only srst_nogate出现在配置脚本的某处。
MCU复位引脚连接到调试器硬件，官方ST-Link / V2上的引脚15。

或者您可以通过您的主板提供的任何方式手动完成。如果你很幸运，它有一个复位按钮，如果没有，你必须找到一种方法以某种方式接地MCU复位引脚。

将复位引脚拉低
启动openocd
等到出现Info : Target voltage行。也许还要一秒钟。
释放复位引脚。

这需要一些试验和错误，你会在练习中变得更好。

然后，您可以刷新改进的应用程序，小心避免重新配置SWD引脚。

stm32 factory bootloader可能被openocd覆盖了？

1 个答案: