Nucleo L3 programming fails

[modm-io]

Nucleo L3 programming fails

[salkinium]

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.

[strongly-typed]

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.

[rleh]

@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.

[strongly-typed]

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)

[rleh]

Does the flash verification work with OpenOCD 0.10.0+dev-00527-g724fddcb (2018-09-07-12:21)?

[strongly-typed]

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.

[rleh]

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.

[salkinium]

Hm, I thought verifying would make programming more safe, but if this is the broken status of OpenOCD, then maybe we should remove it?

[salkinium]

I'm closing this, please open a PR if this OpenOCD bug is too annoying.