Stlink: STM32F030R8T6: flash loader run error

Created on 17 May 2020 · 9Comments · Source: stlink-org/stlink

Programmer/board type: ST-Link v2.1
Programmer firmware version: STSW-LINK007 2.37.26
Operating system and version: Linux, XUbuntu 18.04 LTS
Stlink tools version and/or git commit hash: 1.6.0-311-ga98b094
Stlink commandline tool name: st-flash
Target chip (and board if applicable): STM32F030R8T6, Nucleo-64

Commandline-Output:

> st-flash write dioda.bin 0x08000000
st-flash 1.6.0-311-ga98b094
2020-05-17T17:59:37 INFO common.c: F0xx: 8 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file dioda.bin md5 checksum: d3ad84699b33f431b86a77e53b16b11a, stlink checksum: 0x0000080b
2020-05-17T17:59:37 INFO common.c: Attempting to write 56 (0x38) bytes to stm32 address: 134217728 (0x8000000)
2020-05-17T17:59:37 INFO common.c: Flash page at addr: 0x08000000 erased
2020-05-17T17:59:37 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-05-17T17:59:37 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-17T17:59:37 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-05-17T17:59:37 ERROR flash_loader.c: flash loader run error
2020-05-17T17:59:37 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Expected/description:

Expect it to be flashed of course. More info:

st-info recognizes the programmer
adding --reset to st-flash does not help
powercycling the board does not help
mass-erasing the chip before flashing does not help
similar Nucleo board with STM32F103RBT6 (the same ST-Link firmware version) flashes just fine with the same software and USB cable

bufixed componenst-flash erroflash-loader olinux programmestlinkv2-1 staturesolved targestm32f0

Source

grzegorz-kraszewski

Most helpful comment

May you try my branch(with a quick and dirty fix , just as a proof of my thought)?

I've built from your branch and can confirm, it fixes the problem.

grzegorz-kraszewski on 17 May 2020

👍2

All 9 comments

Maybe I know what’s the problem here. May you try my branch(with a quick and dirty fix , just as a proof of my thought)?

https://github.com/chenguokai/stlink/tree/stlink-v3_pre

If I am right, the issue is related to the non-PIC code of new flashloaders combined with a dirty fix in flashloader.c.

chenguokai on 17 May 2020

May you try my branch(with a quick and dirty fix , just as a proof of my thought)?

I've built from your branch and can confirm, it fixes the problem.

grzegorz-kraszewski on 17 May 2020

👍2

@chenguokai: What do we have here?

Nightwalker-87 on 17 May 2020

As I mentioned, the GPL licensed flashloaders, is PIC (position independent code) while the new ones, are not. That’s also why I needed to write a linker script, specifying the base address.

By disassembling the compiled flashloaders, I recognized the addressing mode to be PC(program counter) relative. I thought they are kinds of PIC, so I kept the dirty hack as a marco in flashloader.c. From this issue, I can confirm that flashloader code is definitely not PIC, so the two nops should be added to the flashloader code rather than appended before a binary.

chenguokai on 17 May 2020

👍1

Ok then, you may hand in a PR for the June release, but make sure to branch of develop instead of stlink-v3_pre which I deleted after the last PR. I don't know if this can cause any side effects.

Nightwalker-87 on 17 May 2020

@grzegorz-kraszewski Please verify if my PR fixes this problem :-)

chenguokai on 18 May 2020

@grzegorz-kraszewski Please verify if my PR fixes this problem :-)

Not sure, as it triggers another one:

> st-flash write ~/dioda_f030.bin 0x08000000
st-flash 1.6.0-314-g273e798
2020-05-18T10:59:30 WARN common.c: unknown chip id! 0x374b
Failed to connect to target

grzegorz-kraszewski on 18 May 2020

@grzegorz-kraszewski: This looks like a different topic. Please open a new ticket for that.

Nightwalker-87 on 18 May 2020