Closed strongly-typed closed 5 years ago
Ok, seems to be more related to OpenOCD.
Using program
instead of flash write_image erase
causes the warning
Warn : no flash bank found for address 0x10000000
and subsequently the verify
does not work. 0x10000000
is the CCM SRAM.
@chris-durand got a similar error on a STM32F7 board some days ago. I think it was a OpenOCD related bug; programming actually works, only verification fails.
Yes, can confirm that even with the old command (flash write_image
) the verify_image
does not work. Now running OpenOCD Open On-Chip Debugger 0.10.0+dev-00527-g724fddcb (2018-09-07-12:21)
Does the flash verification work with OpenOCD 0.10.0+dev-00527-g724fddcb (2018-09-07-12:21)
?
No, it doesn't. (But the code is on the chip and is doing very well.)
I can program an verify a STM32F103 (on a blue pill)
➜ src git:(master) ✗ scons program
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
.----OpenOCD--- build/release/src.elf
'-------------> stm32f103c8t
Open On-Chip Debugger 0.10.0+dev-00527-g724fddcb (2018-09-07-12:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
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
none separate
program_debug
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.202623
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080018e0 msp: 0x20000be0
** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20000be0
wrote 4096 bytes from file build/release/src.elf in 0.294507s (13.582 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000be0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000be0
verified 3952 bytes in 0.138989s (27.767 KiB/s)
** Verified OK **
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000468 msp: 0x20000be0
shutdown command invoked
scons: done building targets.
Removing the verify
argument from the OpenOCD command would fix the issue:
proc modm_program { SOURCE } {
- program $SOURCE verify
+ program $SOURCE
reset halt
But we better investigate why OpenOCD is trying to verify (and program?) SRAM at 0x10000000
.
Hm, I thought verifying would make programming more safe, but if this is the broken status of OpenOCD, then maybe we should remove it?
I'm closing this, please open a PR if this OpenOCD bug is too annoying.
HA! This isn't a bug in OpenOCD 🤦♂️. #AlwaysBlameOtherSoftwareFirst
This happens when placing the vector table into RAM (which is done by default on F3/F7) and the linkerscript didn't define the .vector_ram
sections as (NOLOAD)
, so OpenOCD tried to verify it, which is of course difficult, since the memory is only copied during startup. PR is in works.
Working example modm at 4ae989ee0
Non-working example, after updating modm to ea7a3008a