STM32F030R8T6: flash loader run error

[grzegorz-kraszewski]

• 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

[chenguokai]

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.

[grzegorz-kraszewski]

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.

[Nightwalker-87]

@chenguokai: What do we have here?

[chenguokai]

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.

[Nightwalker-87]

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.

[chenguokai]

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

[grzegorz-kraszewski]

@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

[Nightwalker-87]

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

[chenguokai]

Not sure, as it triggers another one:

Does a relaunch or a unplug and plug help?