[feature] Support for GD32F130

[EmerickH]

• Programmer/board type: Stlink v2
• Programmer firmware version: Last one
• Operating system: Linux
• Stlink tools version and/or git commit hash: st-flash 1.4.0-41-ge147a8e
• Stlink commandline tool name: st-flash
• Target chip (and optional board): GD32F130C8 (clone of STM32F103C8)

Output:

> st-flash --reset write build/hover.bin 0x8000000
st-flash 1.4.0-41-ge147a8e
2018-07-15T12:27:50 INFO common.c: Loading device parameters....
2018-07-15T12:27:50 INFO common.c: Device connected is: F1 Medium-density device, id 0x13030410
2018-07-15T12:27:50 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-07-15T12:27:50 INFO common.c: Attempting to write 15404 (0x3c2c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003c00 erased
2018-07-15T12:27:50 INFO common.c: Finished erasing 16 pages of 1024 (0x400) bytes
2018-07-15T12:27:50 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-07-15T12:27:50 INFO flash_loader.c: Successfully loaded flash loader in sram
  2/16 pages written2018-07-15T12:27:50 ERROR flash_loader.c: write error, count == 512
2018-07-15T12:27:50 ERROR common.c: stlink_flash_loader_run(0x8000800) failed! == -1
stlink_fwrite_flash() == -1 

Sometimes the count is a random number instead of 512

Expected/description:
I can't manage to flash a GD32F130C8 with st-flash with this StLink:

• I've connected 3v3, Gnd, SWDIO and SWCLK to the board...
• I tried to connect also RST but it's complicated because there's no pin to solder
• I tried to flash it on Windows with STM32 ST-LINK Utility, same problem: only a few bytes are written then it's only FFFFF...
• I tried multiples bin files (hello world, already made firmwares...)
  Have you got any idea of what's wrong?

[xor-gate]

You need the reset pin, else it won't work in most situations. Clones of programmers and non-genuine are unsupported by the stlink project. So if they don't work you are on your own or buy for a few bucks real hardware.

[EmerickH]

Ok... I'm going to retry with the reset and I will update the issue.

[EmerickH]

I've soldered a cable on the board on the reset resistor and connected it to T_JRST

But now I have:

> st-flash --reset write build/hover.bin 0x8000000
st-flash 1.4.0-41-ge147a8e
2018-07-15T14:46:36 INFO usb.c: -- exit_dfu_mode
2018-07-15T14:46:36 INFO common.c: Loading device parameters....
2018-07-15T14:46:36 INFO common.c: Device connected is: F1 Medium-density device, id 0x13030410
2018-07-15T14:46:36 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-07-15T14:46:36 INFO common.c: Attempting to write 15404 (0x3c2c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003c00 erased
2018-07-15T14:46:36 INFO common.c: Finished erasing 16 pages of 1024 (0x400) bytes
2018-07-15T14:46:36 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-07-15T14:46:36 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: ffffffff, chipid: 410
2018-07-15T14:46:36 WARN flash_loader.c: Failed to write flash loader to sram!
2018-07-15T14:46:36 ERROR common.c: stlink_flash_loader_init() == -1
stlink_fwrite_flash() == -1

(when I deconnect RST, I have the same log as previous)

EDIT: I found this
https://translate.google.fr/translate?sl=auto&tl=en&js=y&prev=_t&hl=fr&ie=UTF-8&u=https%3A%2F%2Fwww.mikrocontroller.net%2Ftopic%2F431806&edit-text=&act=url
where stlink seems to find coreid

EDIT 2: STLINK_CHIPID_STM32_F1_MEDIUM (410) is delared in chipid.h but not used in any if condition here

EDIT 3: according to this, STLINK_FLASH_TYPE_F0 must be used, i'm trying to make a fix on my fork

EDIT 4: The change I made on my fork removes coreid problem, but it's not working...

st-flash 1.4.0-43-ge9f2399
2018-07-15T15:58:39 INFO usb.c: -- exit_dfu_mode
2018-07-15T15:58:39 INFO common.c: Loading device parameters....
2018-07-15T15:58:39 INFO common.c: Device connected is: F1 Medium-density device, id 0x13030410
2018-07-15T15:58:39 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-07-15T15:58:39 INFO common.c: Attempting to write 15404 (0x3c2c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003c00 erased
2018-07-15T15:58:40 INFO common.c: Finished erasing 16 pages of 1024 (0x400) bytes
2018-07-15T15:58:40 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-07-15T15:58:40 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-07-15T15:58:42 ERROR flash_loader.c: flash loader run error
2018-07-15T15:58:42 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

[xor-gate]

Thats weird, I have no clue why it doesn't work.

[EmerickH]

Maybe somes clues here:
https://github.com/libopencm3/libopencm3/blob/master/include/libopencm3/stm32/f1/flash.h
https://github.com/libopencm3/libopencm3/blob/master/include/libopencm3/stm32/f0/flash.h
https://github.com/libopencm3/libopencm3/blob/master/include/libopencm3/stm32/common/flash_common_f01.h
To recreate a flashloader for F1 like:
https://github.com/texane/stlink/blob/master/flashloaders/stm32f0.s
I will try tomorrow to continue digging...

EDIT: We can use OpenOcd's one maybe?
https://github.com/ntfreak/openocd/blob/master/contrib/loaders/flash/stm32/stm32f1x.S

[EmerickH]

I never achieved to programm it...
(Maybe dead?)
I bought a new board with a STM32 and it is working well!
Should I close this issue?
Thank you

[xor-gate]

Broken hardware can result in weird unexplainable errors. Thanks for reporting back it works now with good hardware!

[Nightwalker-87]

The GD32F130C8 is not officially supported by this toolset.
However it would indeed be worth to have a look this as a possible feature.
At first there should be further testing to find out more about current incompatibilities with this MCU series.

[Nightwalker-87]

@Ant-ON: Can you review this in relation to the recently referenced commit?
It looks as if this has been resolved already, but I don't know since when exactly...

[Ant-ON]

@Nightwalker-87 I think it most likely closes by #1044. The second problem with the flashloader launch ability is also likely to be closed by the flashloader improving (#1113, #1124).

[Nightwalker-87]

Partially fixed in #1044, #1113 and finally closed with #1124.