CKS32: Unable to flash STM32F103C8T6 with stlink 1.5.1

[svenikea]

I'm on Arch linux and i install stlink through it repository and when I install all the require dependencies and run stlink-flash hello.bin 0x08000000 it gave me this error

st-flash 1.5.1
2019-09-15T00:41:53 INFO usb.c: -- exit_dfu_mode
2019-09-15T00:41:53 INFO common.c: Loading device parameters....
2019-09-15T00:41:53 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-09-15T00:41:53 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2019-09-15T00:41:53 INFO common.c: Attempting to write 1228 (0x4cc) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000400 erased
2019-09-15T00:41:53 INFO common.c: Finished erasing 2 pages of 1024 (0x400) bytes
2019-09-15T00:41:53 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-09-15T00:41:53 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 410
2019-09-15T00:41:53 WARN flash_loader.c: Failed to write flash loader to sram!
2019-09-15T00:41:53 ERROR common.c: stlink_flash_loader_init() == -1
stlink_fwrite_flash() == -1

I'm been searching online how to fix this but no luck and also the preloaded led blink is gone so I don't know if I broke the chip or not. If anybody find a solution for this I'll be appreciated thanks

[N0ury]

Me too.
Running
st-flash --reset --format binary write generic_boot20_pc13_bootloader_par_defaut_led_en_pc13.bin 0x8000000

gives:

st-flash 1.5.1
2019-09-16T15:02:03 INFO usb.c: -- exit_dfu_mode
2019-09-16T15:02:03 INFO common.c: Loading device parameters....
2019-09-16T15:02:03 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-09-16T15:02:03 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2019-09-16T15:02:03 INFO common.c: Attempting to write 7160 (0x1bf8) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08001800 erased
2019-09-16T15:02:03 INFO common.c: Finished erasing 7 pages of 1024 (0x400) bytes
2019-09-16T15:02:03 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-09-16T15:02:03 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 410
2019-09-16T15:02:03 WARN flash_loader.c: Failed to write flash loader to sram!
2019-09-16T15:02:03 ERROR common.c: stlink_flash_loader_init() == -1
stlink_fwrite_flash() == -1

It's a new device ordered from aliexpress, and received today.

I must add that using with ftdi:
stm32loader -p /dev/cu.usbserial-A5XK3RJT -e -w -v generic_boot20_pc13_bootloader_par_defaut_led_en_pc13.bin
works fine.

Help would be greatly appreciated.

[N0ury]

I have just tried with an old "bluepill" and it works fine.
There's no difference in st-info --probe
Is it a hardware issue ? It would be strange, twice a day...

[N0ury]

There's one hardware difference.
On the microcontroller of the old bluepill that works fine, there is "STM32" and STM logo
On the new one that doesn't work fine there is "CKS32F" and CKS logo.

[svenikea]

Can you give more specific about Friday and the line you added

stm32loader -p /dev/cu.usbserial-A5XK3RJT -e -w -v

[N0ury]

I'm on Mac, so I need to use stm32loader, a python app.
I've downloaded it from https://github.com/florisla/stm32loader.git
You can also do (and it's better): pip install stm32loader
I think there's already the same on Windows, but I don't know its name.
If you use this one, be careful to add binary name to flash at the end.

[svenikea]

Oh so we both UNIX

[N0ury]

I have solved my issue but in a "dirty" way.
Here's what I have done:

In include/stm32.h, I have added #define CS32VL_CORE_ID 0x2ba01477 0x2ba01477 beeing the unrecognized coreid.
In src/flash_loader.c, I have added line 265:

    } else if (sl->core_id == STM32VL_CORE_ID
            || sl->chip_id == CS32VL_CORE_ID <== added this line
            || sl->chip_id == STLINK_CHIPID_STM32_F1_MEDIUM

It works fine now.
Can someone tell if it's good or not.

[slyshykO]

Can someone tell if it's good or not.

I think it is good. If it is possible, please send a PR.

[svenikea]

which library are you using m8?

[N0ury]

@kynguyen98 I don't understand your question. I have cloned the project, changed 2 files, and then compiled the project. That's all.
@slyshykO I'm going to do this

[N0ury]

@slyshykO I've sent a pull request #834

[ColinKinloch]

I'm having the same issue, however only on macOS (10.14.6).
Doing the same operation on the same hardware on Fedora flashes without complaint.

[N0ury]

I'm on Mac too. Be sure to use the latest version, it works fine.

[ColinKinloch]

I'm using v1.5.1 installed using homebrew.
Do you mean compiled from the master branch?

[N0ury]

Yes, homebrew version is not the last one. It doesn't work for this chip.
Use github last version from the master branch.

[fadedbee]

I am using the ST Link V2 programmer on an STM32F429I-DISCO board. That programmer successfully flashes the on-board STM32F4xx.

I have connected the onboard ST Link V2 (after removing jumpers) to a blue-pill with a MCU marked STM32F103C8T6.

I am using the latest stlink from the master branch:

chris@purple:~/github/stlink$ cat .git/config 
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://github.com/texane/stlink.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
chris@purple:~/github/stlink$ git pull
Already up-to-date.

When I type load in gcc, I see the following:

chris@purple:~/stm32f103c8t-blinky$ arm-none-eabi-gdb build/stm32f103c8t-blinky.elf 
...
(gdb) target extended-remote :4242
Remote debugging using :4242
Reset_Handler () at startup_stm32f103xb.s:65
65	  movs r1, #0
(gdb) load
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x33d8 lma 0x800010c
Loading section .rodata, size 0x74 lma 0x80034e4
Loading section .init_array, size 0x4 lma 0x8003558
Loading section .fini_array, size 0x4 lma 0x800355c
Loading section .data, size 0x17c lma 0x8003560
Error finishing flash operation
(gdb) 

In the stlink window, I see:

chris@purple:~/github/stlink$ ./build/Release/src/gdbserver/st-util
st-util 1.5.1-50-g3690de9
2020-01-06T14:06:11 INFO usb.c: -- exit_dfu_mode
2020-01-06T14:06:11 INFO common.c: Loading device parameters....
2020-01-06T14:06:11 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-01-06T14:06:11 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2020-01-06T14:06:11 INFO gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
2020-01-06T14:06:11 INFO gdb-server.c: Listening at *:4242...
2020-01-06T14:37:23 INFO gdb-server.c: Found 6 hw breakpoint registers
2020-01-06T14:37:23 INFO gdb-server.c: GDB connected.
2020-01-06T14:37:44 INFO common.c: Attempting to write 1024 (0x400) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-01-06T14:37:44 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-01-06T14:37:44 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-01-06T14:37:44 INFO flash_loader.c: Successfully loaded flash loader in sram

2020-01-06T14:37:44 INFO common.c: Starting verification of write complete
2020-01-06T14:37:44 INFO common.c: Flash written and verified! jolly good!
2020-01-06T14:37:44 INFO common.c: Attempting to write 1024 (0x400) bytes to stm32 address: 134218752 (0x8000400)
Flash page at addr: 0x08000400 erased
2020-01-06T14:37:44 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-01-06T14:37:44 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-01-06T14:37:44 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-01-06T14:37:44 ERROR flash_loader.c: write error, count == 511
2020-01-06T14:37:44 ERROR common.c: stlink_flash_loader_run(0x8000400) failed! == -1

The core ID of 1ba01477 seems to be consistent with it being a genuine ST part, rather than a clone.

I have power-cycled both the ST Link v2 and the blue-pill.

What can I do to diagnose and fix this issue?

[fadedbee]

A second blue-pill behaved identically, so it is not a faulty blue-pill.

[Nightwalker-87]

Duplicate of #756.

[Nightwalker-87]

Finally resolved by #805.