stlink: STM32F101VG: st-flash reports " ERROR common.c: unsupported flash method, abort"
- I made serious effort to avoid creating duplicate or nearly similar issue
- Programmer/board type: STLink/V2
- Operating system an version: Linux
- Stlink tools version and/or git commit hash: v1.6.1
- Stlink commandline tool name: st-flash
- Target chip (and board, if applicable): STM32F101VG (custom board)
Commandline:
st-flash --reset --flash=512k --format=ihex write app.hex
Commandline-Output:
st-flash 1.6.1
2021-03-27T19:09:43 INFO common.c: F1xx XL-density: 96 KiB SRAM, 1024 KiB flash in at least 2 KiB pages.
Forcing flash size: --flash=0x00080000
2021-03-27T19:09:43 INFO common.c: Attempting to write 415132 (0x6559c) bytes to stm32 address: 134275072 (0x800e000)
2021-03-27T19:09:43 ERROR common.c: unsupported flash method, abort...
Expected/description: Correct operation.
Also, I’ve noticed that st-util reports incorrect RAM size:
$ st-util
st-util
2021-03-27T19:12:46 INFO common.c: F1xx XL-density: 96 KiB SRAM, 1024 KiB flash in at least 2 KiB pages.
STM32F101VG has only 80Kib.
P.S. OpenOCD also fails with “error waiting for target flash write algorithm”. Original ST Windows utilities work without problems.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 24 (3 by maintainers)
@nbkolchin I checked the behavior of the application with the IWDG enabled by hardware. It is very similar to the observed situation (interrupting the flashing in random places and the contents of the registers). I added IWDG reset during flashing. Everything should work correctly now. If you can, then check out the https://github.com/Ant-ON/stlink/commits/flash_loader_fix branch.
@nbkolchin Oh, I’m already inattentive by the evening. No need. Can you read data from MCU by run something
@nbkolchin I’m glad the problem has been resolved. Thanks for your quick testing! I’ll do PR later and the fixes will be in the main branch. I’m waiting now for information about the state of the problem with L4…