stlink: Attempting to flash to STM32L052K8 corrupts flash memory
- Programmer/board type: Stlink/v2
- Programmer firmware version: Unknown; generic St-link module.
- Operating system: Linux (Ubuntu 16.04)
- Stlink tools version and/or git commit hash: v1.5.0
- Stlink commandline tool name: st-util
- Target chip (and optional board): STM32L051K8
Attempting to flash a .elf to the chip results in a series of errors indicating an STM32L1 loader is being used (quoted further down), and subsequent connections fail with the following strange error message:
2018-03-08T23:04:41 WARN common.c: Invalid flash type, please check device declaration
2018-03-08T23:04:41 INFO gdb-server.c: Chip ID is 00000000, Core ID is 0bc11477.
That state persists until the chip is ‘fixed’ by connecting to it during a hardware reset via ST’s ST-Link Utility on a Windows machine. Here is the output that st-util gives during the problematic flashing operation:
st-util 1.5.0
2018-03-08T23:04:03 INFO usb.c: -- exit_dfu_mode
2018-03-08T23:04:03 INFO common.c: Loading device parameters....
2018-03-08T23:04:03 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-03-08T23:04:03 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-03-08T23:04:03 INFO gdb-server.c: Chip ID is 00000417, Core ID is 0bc11477.
2018-03-08T23:04:03 INFO gdb-server.c: Listening at *:4242...
2018-03-08T23:04:13 INFO gdb-server.c: Found 4 hw breakpoint registers
2018-03-08T23:04:13 INFO gdb-server.c: GDB connected.
2018-03-08T23:04:14 INFO common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2018-03-08T23:04:14 INFO common.c: Finished erasing 1 pages of 128 (0x80) bytes
2018-03-08T23:04:14 INFO common.c: Starting Half page flash write for STM32L core id
2018-03-08T23:04:14 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-03-08T23:04:17 ERROR flash_loader.c: flash loader run error
2018-03-08T23:04:17 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-03-08T23:04:17 WARN common.c:
write_half_pages failed == -1
0/ 1 pages written
2018-03-08T23:04:17 INFO common.c: Starting verification of write complete
2018-03-08T23:04:17 INFO common.c: Flash written and verified! jolly good!
2018-03-08T23:04:17 INFO common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134217856 (0x8000080)
Flash page at addr: 0x08000080 erased
2018-03-08T23:04:17 INFO common.c: Finished erasing 1 pages of 128 (0x80) bytes
2018-03-08T23:04:17 INFO common.c: Starting Half page flash write for STM32L core id
2018-03-08T23:04:17 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-03-08T23:04:20 ERROR flash_loader.c: flash loader run error
2018-03-08T23:04:20 WARN common.c: l1_stlink_flash_loader_run(0x8000080) failed! == -1
2018-03-08T23:04:20 WARN common.c:
write_half_pages failed == -1
0/ 1 pages written
2018-03-08T23:04:21 INFO common.c: Starting verification of write complete
2018-03-08T23:04:21 INFO common.c: Flash written and verified! jolly good!
[ ... repeats a few times ... ]
Expected/description: The program should flash susccessfully. But despite reporting success, when I try to step through it in GDB, the chip jumps directly from the reset location to 0x20000010. So I gotta figure that something went wrong somewhere.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 1
- Comments: 56 (33 by maintainers)
@chrisgjohnson The codebase has undergone major and very useful refactoring work with lots of improvements and fixes since then. Thus there can be no easy rollback to the previous state. Also by then there were some obscure implementations without any (proper) documentation on their functionality. This is why some users have taken action and have rewritten some parts of the code for flashing. As to my knowledge however a coexistence of old and new sections remain up to the latest state.
Thus one would need to debug the latest code likely without any comparison to the previous state.
@Nightwalker-87 thanks for all the help. I now retried at another computer and there the probe gets detected properly and I can now reproduce the actual problem we are discussing in this issue:
After the last entry the program freezes and has to be terminated.
Interestingly after this the ST-Link V2 clone probe was somehow in a broken state. Even after power cycle it was not being detected properly. Just after reuploading new FW with STM32CubeProgrammer it started working again.
@Nightwalker-87 one other thing I should note (in case this helps) is that I can repro this with different source code. I started that gist with the actual source I’m writing and then slowly changed all instructions to
MOVto make the repro source cleaner.I’m not sure if that’s what’s happening (or the bug just gives this appearance), but what it feels like is that it isn’t so much which instructions that are used but how many of them. It’s as if there’s a limit on the space for instructions and I can either fill it with 27
MOVs or 15LDR, MOV, STR, ORR, etc., and adding one more puts it over the edge. Or at least experimentally that’s how I’m triggering this issue.I’m seeing possibly the same issue on my
STM32L010F4MCU. I’m debugging it through aNUCLEO-L010RB(with the STLINK programmer broken off) on a mac13.3.1, withstlinkv1.7.0installed via Homebrew.Here’s a minimal repro in a gist along with the terminal output. When the final
MOVis commented out everything works and I get theFlash written and verified! jolly good!in the end of thest-flash --format ihex write minimal.hexcommand. If the 28thMOVis uncommented, I can reliably get theFlash loader run error.This happens with the
BOOT0pin in both 0 and 1 configuration (since someone asked above). And, importantly, if I take the failingminimal.hexand use theSTM32CubeProgrammerto flash it there are no issues. Happy to try things out on this hardware.I see. However thanks for the feedback. Feel free to take a look at other issues if you fancy to do so. 👍
@Nightwalker-87 Sorry, I have no boards with L series chip. The problem here is strange, a quick look at the code and reading the documentation did not give any results.
Sure, happy to check whether this still happens with STM32L0 category-2 chips.
Most of my boards are in storage atm though, so I probably won’t be able to do it until I finish moving in May. Sorry about that.