STM32F103CB: I could not write bin file on my controller.

[Joypacharya]

I am facing issue while writing the .bin file into my controller Stm32f103cB.
Here the command for execution,
sudo st-flash --flash=128k write /home/pi/Desktop/Spell/Bootloader.bin 0x08000000

the outcome -->

st-flash 1.6.1-109-g781557d
2020-11-09T17:40:59 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 128 KiB flash in at least 1 KiB pages.
file /home/pi/Desktop/Spell/Bootloader.bin md5 checksum: 4636419d5875ac7103da4e6dc66c566, stlink checksum: 0x0006b357
2020-11-09T17:40:59 INFO common.c: Attempting to write 4572 (0x11dc) bytes to stm32 address: 134217728 (0x8000000)
2020-11-09T17:41:00 INFO common.c: Flash page at addr: 0x08000000 erased
2020-11-09T17:41:00 INFO common.c: Flash page at addr: 0x08000400 erased
2020-11-09T17:41:00 INFO common.c: Flash page at addr: 0x08000800 erased
2020-11-09T17:41:00 INFO common.c: Flash page at addr: 0x08000c00 erased
2020-11-09T17:41:00 INFO common.c: Flash page at addr: 0x08001000 erased
2020-11-09T17:41:00 INFO common.c: Finished erasing 5 pages of 1024 (0x400) bytes
2020-11-09T17:41:00 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-11-09T17:41:00 INFO flash_loader.c: Successfully loaded flash loader in sram
5/5 pages written
2020-11-09T17:41:00 INFO common.c: Starting verification of write complete
2020-11-09T17:41:00 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

I hope anyone helps me resolve my problem,

[Ant-ON]

@Joypacharya Can you try read first 10 bytes after write? Something like:

sudo st-flash --flash=128k read test.bin 0x08000000 10
xxd -b test.bin

[Joypacharya]

First, I erase the flash memory then I load the bin file.
One more thing I want to tell you which installed stlink in raspberry pi board .

[Nightwalker-87]

Invalid opening of this ticket against our project guidelines.
The policy is to delete tickets that do not use the prepared and described template.

@Ant-ON Please take note of this before answering in the future.
However I'll leave this one here now, as the thread has already started... (I may not do so in the future.)

@Joypacharya Please provide the missing information for this issue.

[Nightwalker-87]

I can't reproduce this issue with the same commit and a STM32F103C8T6.

Knowing that the flash size is limited to 64kB (hardware size) in the given chip I opted for --flash=64k, as with --flash=128k flashing would fail anyway. However this is unlikely the cause for this issue, as verification of the written flash failed in the original console output.

$ st-flash --flash=64k write /[...]/Blinker.bin 0x8000000
st-flash 1.6.1-109-g781557d
2021-03-11T22:20:54 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file /[...]/Blinker.bin md5 checksum: 16277ff2c027d497361dbae4255081a1, stlink checksum: 0x0004644a
2021-03-11T22:20:54 INFO common.c: Attempting to write 3520 (0xdc0) bytes to stm32 address: 134217728 (0x8000000)
2021-03-11T22:20:54 INFO common.c: Flash page at addr: 0x08000000 erased
2021-03-11T22:20:54 INFO common.c: Flash page at addr: 0x08000400 erased
2021-03-11T22:20:54 INFO common.c: Flash page at addr: 0x08000800 erased
2021-03-11T22:20:54 INFO common.c: Flash page at addr: 0x08000c00 erased
2021-03-11T22:20:54 INFO common.c: Finished erasing 4 pages of 1024 (0x400) bytes
2021-03-11T22:20:54 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2021-03-11T22:20:54 INFO flash_loader.c: Successfully loaded flash loader in sram
  4/4 pages written
2021-03-11T22:20:54 INFO common.c: Starting verification of write complete
2021-03-11T22:20:54 INFO common.c: Flash written and verified! jolly good!

[Ant-ON]

@Nightwalker-87 Such errors can occur due to read / write protection. I thought to implement this checks, but I don't have enough time for this yet :(

[Nightwalker-87]

@Ant-ON That's OK. I don't see this feature specifically related to this ticket though, as we don't know the exact cause on the local build system. There are also several other tickets that deal with flash verification in general. One of those seem to be the right place for your idea.

The important conclusion for this ticket is, that the problem could not be generally reproduced under a most equal configuration and with the same commit. Thus there is no bug in the tools here. In this context we can safely close this issue as resolved.