2

I am trying to flash my firmware into STM32L152, but instead I have:

Open On-Chip Debugger 0.10.0+dev-00312-g1a3cbbf3 (2018-03-02-20:11)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v6 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 1.769170
Info : stm32l1.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800b324 msp: 0x20007ffc
STM32L: Enabling HSI
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
** Programming Started **
auto erase enabled
Info : Device: STM32L1xx (Cat.3 - Medium+ Density)
Info : STM32L flash size is 256kb, base address is 0x8000000
Warn : no flash bank found for address 0x00000000
wrote 0 bytes from file build/firmware.bin in 0.003700s (0.000 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20007ffc
Error: checksum mismatch - attempting binary compare
diff 0 address 0x00000004. Was 0x25 instead of 0xb5
diff 1 address 0x00000005. Was 0xb3 instead of 0xa7
~~~~ Lot's of those ~~~~
More than 128 errors, the rest are not printed.
** Verify Failed **
shutdown command invoked

firmware.cfg

source [find interface/stlink.cfg]

set WORKAREASIZE 0x8000
transport select hla_swd

source [find target/stm32l1.cfg]

init_reset halt

program build/firmware.bin verify reset exit

The funny part, is when trying to program firmware.elf, everything is ok. Of course, firmware.bin is generated from firmware.elf, so they share the same linker script (or I am wrong on this part?):

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K } ...

I've also tried OpenOCD 0.10.0 and 0.9.0.

artless noise
  • 21,212
  • 6
  • 68
  • 105
joe.kovalski
  • 300
  • 1
  • 4
  • 14
  • 1
    the first byte in the file firmware.bin is going to come from what is the first byte at 0x08000000 in flash. so if you use the .bin you need to specify the address 0x08000000. Side note if you have even a single byte of .data your .bin file will be padded. say you have 10 bytes of .text and your variables are all .bss, flash.bin will be 10 bytes, but if you have 10 bytes of .text and 1 byte of .data your .bin file will be 0x18000001 bytes or 402653185 even though there are only 11 relevant bytes in the file. – old_timer Mar 12 '18 at 22:52
  • note this line in the openocd output: Info : STM32L flash size is 256kb, base address is 0x8000000 – old_timer Mar 12 '18 at 22:53

1 Answers1

5

wrote 0 bytes from file build/firmware.bin

The firmware.bin lost its offset information, as it is in a raw binary format. You would be better off trying to flash the firmware.elf file directly.

Alternatively you can try putting the correct flash memory offset into the OpenOCD command:

program build/firmware.bin 0x08000000 verify reset exit
Turbo J
  • 7,563
  • 1
  • 23
  • 43
  • Thanks, I'll test this as soon as I get my physical board back, but I am a bit curious, is it a good practice to flash elf files for production instead of bin? – joe.kovalski Mar 02 '18 at 21:55
  • 1
    The .elf may contain debug symbols and similar information one may not want to share with production. (Intel-) Hex files are one alternative that does not contain anything useful except the program *and* its adress(es). Unlike binary, hex files also support "holes" - unprogrammed/free space. – Turbo J Mar 03 '18 at 00:32