Flash loader counter error on STM32F107VCT6

[Trinitywerma]

• Programmer type:Stlink/v2
• Programmer firmware version: V2.J21.S4
• Operating system: Linux, Raspbian
• Stlink tools version: v1.5.1-28-gd040db5
• Stlink commandline tool name: st-flash
• Target chip (and optional board):STM32F107VCT6 F1Connectivity Line Device

Hey Guys,
got here some problems with a STM32F107VCT6. I want to flash it with my Raspbian and a ST-LinkV2 Clone via SWD. Wiring is fine i guess. Connection is pretty good and the first file to flash works fine, but the second one throws an error at page 7 of 55. I don´t know how to handle that kind of issue. Maybe you guys, have an idea.
I´ve tried it on a Windows system with St-Link Utility and it works fine for both files.
File1 is directed for Address 0x8000000
File2 is directed for Address 0x8007000

Commandlines:
st-flash erase
st-flash --reset --format ihex write file1.hex
st-flash --debug --reset --format ihex write file2.hex

OUTPUT/ERROR of the commandline tool(s):

root@raspberrypi:/# ./doitst.sh
st-flash 1.5.1-28-gd040db5
2019-05-29T14:12:52 INFO common.c: Loading device parameters....
2019-05-29T14:12:52 INFO common.c: Device connected is: F1 Connectivity line device, id 0x10016418
2019-05-29T14:12:52 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
Mass erasing
st-flash 1.5.1-28-gd040db5
2019-05-29T14:12:52 INFO common.c: Loading device parameters....
2019-05-29T14:12:52 INFO common.c: Device connected is: F1 Connectivity line device, id 0x10016418
2019-05-29T14:12:52 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2019-05-29T14:12:52 INFO common.c: Attempting to write 13412 (0x3464) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003000 erased
2019-05-29T14:12:52 INFO common.c: Finished erasing 7 pages of 2048 (0x800) bytes
2019-05-29T14:12:52 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-05-29T14:12:52 INFO flash_loader.c: Successfully loaded flash loader in sram

1/7 pages written
2/7 pages written
3/7 pages written
4/7 pages written
5/7 pages written
6/7 pages written
7/7 pages written
2019-05-29T14:12:53 INFO common.c: Starting verification of write complete
2019-05-29T14:12:53 INFO common.c: Flash written and verified! jolly good!
st-flash 1.5.1-28-gd040db5
2019-05-29T14:12:53 INFO common.c: Loading device parameters....
2019-05-29T14:12:53 INFO common.c: Device connected is: F1 Connectivity line device, id 0x10016418
2019-05-29T14:12:53 INFO common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2019-05-29T14:12:53 INFO common.c: Attempting to write 111432 (0x1b348) bytes to stm32 address: 134246400 (0x8007000)
Flash page at addr: 0x08022000 erased
2019-05-29T14:12:56 INFO common.c: Finished erasing 55 pages of 2048 (0x800) bytes
2019-05-29T14:12:56 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-05-29T14:12:56 INFO flash_loader.c: Successfully loaded flash loader in sram

1/55 pages written
2/55 pages written
3/55 pages written
4/55 pages written
5/55 pages written
6/55 pages written
7/55 pages written2019-05-29T14:12:56 ERROR flash_loader.c: write error, count == 483
2019-05-29T14:12:56 ERROR common.c: stlink_flash_loader_run(0x800a800) failed! == -1
stlink_fwrite_flash() == -1
root@raspberrypi:/#

Thanks for responses.

PS: In addition i hang some --debug messages from st-link.
Flash_loader_counter_Error.txt

[Trinitywerma]

Hey Guys, it seems that the problem was the OptionBytes, in spezific the RDP-Bit (ReadProtectionBit) of the Microcontroller it self. Under Linux Ubuntu i could use the Developer Tool to acces this bit directly and the Flash-process works fine.
Till now, i didn´t found an easy possibility to toggle that bit via stlink.
Greetings

[Nightwalker-87]

@Ant-ON Do we actually support writing of option bytes for the F1? I couldn't find any reference on that.

[Ant-ON]

@Nightwalker-87 st-flash does not support option byte for the F1 now. PR #1112 by @2a17 can add this (F0 and F1 have the same algorithm)