[STM32F103C8T6]: Can't flash on Ubuntu

[junaire]

• I made serious effort to avoid creating duplicate or nearly similar issue

In order to allow developers to isolate and target your respective issue, please take some time to select the check boxes below and fill out each of the following items appropriate to your specific problem.

• Programmer/board type: /V2-clone
• Operating system an version: Linux (Ubuntu22.04)
• stlink tools version and/or git commit hash: 733893a
• stlink commandline tool name: st-flash
• Target chip (and board, if applicable): STM32F103C8T6

I built the program using STM32CubeMX and cmake, then manually converted it to a .bin:

arm-none-eabi-objcopy -O binary test.elf test.bin

Then I try to flash the code to my board:

/build/bin/st-flash write /path/to/test.bin 0x08000000

But I got:

st-flash 1.8.0-64-g733893a-dirty
2024-11-24T14:13:04 WARN common.c: unknown chip id! 0x10
Failed to connect to target
Failed to parse flash type or unrecognized flash type

I investigated a bit, but I'm not sure where goes wrong...
Looks like in common.c:239 stlink_chip_id it returns an invalid chip id so we can't match it with a known one. and in usb.c _stlink_usb_read_debug32 we have:

(gdb) p cmd
$21 = (unsigned char * const) 0x555555567a00 "\362\066"

(gdb) p / *rdata
$19 = 0x80
(gdb) p /x *data
$20 = 0x4010

any ideas about why?

[junaire]

well i belive the correct chip id should be 0x410 so I hardcoded it in my case, and it seems to work?

2024-11-24T14:23:10 INFO common.c: STM32F1xx_MD: 20 KiB SRAM, 128 KiB flash in at least 1 KiB pages.
file /path/to/test.bin md5 checksum: 8ab2e3258142eba5b253b2bb2c5d5, stlink checksum: 0x00103f68
2024-11-24T14:23:10 INFO common_flash.c: Attempting to write 11024 (0x2b10) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x400)
-> Flash page at 0x8000400 erased (size: 0x400)
-> Flash page at 0x8000800 erased (size: 0x400)
-> Flash page at 0x8000c00 erased (size: 0x400)
-> Flash page at 0x8001000 erased (size: 0x400)
-> Flash page at 0x8001400 erased (size: 0x400)
-> Flash page at 0x8001800 erased (size: 0x400)
-> Flash page at 0x8001c00 erased (size: 0x400)
-> Flash page at 0x8002000 erased (size: 0x400)
-> Flash page at 0x8002400 erased (size: 0x400)
-> Flash page at 0x8002800 erased (size: 0x400)

2024-11-24T14:23:10 INFO flash_loader.c: Starting Flash write for VL/F0/F3/F1_XL
2024-11-24T14:23:10 INFO flash_loader.c: Successfully loaded flash loader in sram
2024-11-24T14:23:10 INFO flash_loader.c: Clear DFSR
  1/11  pages written
  2/11  pages written
  3/11  pages written
  4/11  pages written
  5/11  pages written
  6/11  pages written
  7/11  pages written
  8/11  pages written
  9/11  pages written
 10/11  pages written
 11/11  pages written

2024-11-24T14:23:11 INFO common_flash.c: Starting verification of write complete
2024-11-24T14:23:11 INFO common_flash.c: Flash written and verified! jolly good!
2024-11-24T14:23:11 INFO common.c: Go to Thumb mode

[Ant-ON]

@junaire Do you flash original STM32 or clone chip?

[junaire]

@junaire Do you flash original STM32 or clone chip?

tbh i don't know... i think it's the original chip but I how can I verify that? i bought it from 3rd party store online though.

[junaire]

I suspect it's because the stlink v2 is the cloned one, I'm pretty sure about that. is it possible to have failures because of this?

[Nightwalker-87]

@junaire: Yes, that's why we don't offer any support for STLINK/v2 clone programmers.
Here are some references from within the project: #1012, #1206, #1308, #1435.

Referring to @Ant-ON 's question: The spread of cloned/fake STM32F103C8T6 devices mostly originating from China has turned out to be a notable problem as well. Some of them are only partially functional or even do not work at all.
Looking back, we have faced several issues here in the past as well (e.g. #1322) and thus we don't offer support for these as well.

[junaire]

Yes, that's why we don't offer any support for STLINK/v2 clone programmers. Here are some references from within the project: #1012, #1206, #1308, #1435. Referring to @Ant-ON 's question: The spread of cloned STM32F103C8T6 devices mostly originating from China has turned out to be a notable problem as well. Some of them are only partially functional or even do not work at all. Looking back, we have faced several issues here in the past as well (e.g. #1322).

Thanks for the explanation. if it's a very common issue, maybe we can document it in the README a bit and have some hints in error messages?

[Nightwalker-87]

Thanks for the explanation. if it's a very common issue, maybe we can document it in the README a bit and have some hints in error messages?

The topic is indeed already covered in our tutorial as can be found in the result of #1322.