STM32L052 flash loader run error: write_half_pages failed == -1

[12amOil]

(See closed issue #269, as well.)

Summary:
Remote flashing via gdb often (? 30%) fails with "write_half_pages failed == -1"

Details:

I am using st-util 1.4.0 on MacOS to drive the ST-LINK half of a Discovery STM32L0308 as my debugging tool. The ST-LINK is running firmware V2J34S0 . I debug with GDB ("GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs").

The target is a bare-bones STM32L052K8 . I connect the Discovery's SWDIO/CLK to STM32L0 PA13/PA14 respectively, NRST to STM32L0 NRST, Vpp to the STM32 Vcc/Vss, and the STM32L0 BOOT0 is pulled to ground. The STM32 GPIOs are configured for I2C, SPI, and polling simple SPST switches.

The STM32L052 is USB-powered. I read a steady 5v01 at Vusb, and I feed that into an 800mA 3.3V regulator (TC1265-3.3). It shows a steady 3v28 output. With the Cortex busy-spinning awaiting a debug, current is well below 800mA - I read 24 - 30mA at the USB pins (regulator Vin).

Upon launching st-util, the target is identifed as such:

$ stlink/1.4.0/bin/st-util -p 24500 -v
st-util 1.4.0
2019-07-11T09:59:39 INFO src/usb.c: -- exit_dfu_mode
2019-07-11T09:59:40 INFO src/common.c: Loading device parameters....
2019-07-11T09:59:40 INFO src/common.c: Device connected is: L0x3 device, id 0x10386417
2019-07-11T09:59:40 INFO src/common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2019-07-11T09:59:40 INFO src/gdbserver/gdb-server.c: Chip ID is 00000417, Core ID is 0bc11477.
2019-07-11T09:59:40 INFO src/gdbserver/gdb-server.c: Listening at *:24500...

I notice st-util displays "L0x3" while my target is indeed STM32L052, but have no reason to think this is an issue. I have not pulled the sources to check that, I confess.

Debugging is generally robust. I only have issues with the loading of flash.

Using the GDB 'load' command to update system flash, there is a high probability that st-util will begin to fail to write half-pages. The failures are not always at the same half-page. Once this is encountered, the only workaround I have found is to remove power from the ST-LINK, re-apply power, and reconnect GDB to a new instance of st-util .

2019-07-11T10:43:22 INFO src/common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134222336 (0x8001200)
Flash page at addr: 0x08001200 erased
2019-07-11T10:43:22 INFO src/common.c: Finished erasing 1 pages of 128 (0x80) bytes
2019-07-11T10:43:22 INFO src/common.c: Starting Half page flash write for STM32L core id
2019-07-11T10:43:22 INFO src/flash_loader.c: Successfully loaded flash loader in sram

2019-07-11T10:43:22 INFO src/common.c: Starting verification of write complete
2019-07-11T10:43:22 INFO src/common.c: Flash written and verified! jolly good!
2019-07-11T10:43:22 INFO src/common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134222464 (0x8001280)
Flash page at addr: 0x08001280 erased
2019-07-11T10:43:23 INFO src/common.c: Finished erasing 1 pages of 128 (0x80) bytes
2019-07-11T10:43:23 INFO src/common.c: Starting Half page flash write for STM32L core id
2019-07-11T10:43:23 INFO src/flash_loader.c: Successfully loaded flash loader in sram
2019-07-11T10:43:27 ERROR src/flash_loader.c: flash loader run error
2019-07-11T10:43:27 WARN src/common.c: l1_stlink_flash_loader_run(0x80012c0) failed! == -1
2019-07-11T10:43:27 WARN src/common.c:
write_half_pages failed == -1
0/ 1 pages written
2019-07-11T10:43:27 INFO src/common.c: Starting verification of write complete
2019-07-11T10:43:27 INFO src/common.c: Flash written and verified! jolly good!

Each failure seems to stall for a few seconds before proceeding.

Once power cycled and with a new instance of st-util, the same load almost 100% always works the first time.

I have looked through other topics and seen similar problems as well, but some years ago and resolved.

I notice that the head of this repository appears to be 1.3.0, but mine claims to be 1.4.0. I've been using my copy of st-util for a while and put it aside for another project; now I don't recall where I downloaded this version.

Any wisdom one may have on this problem will be appreciated. I hope I have provided the right amount of information.

Thank you for your time.

[xor-gate]

It is possible there is a bug in the algorithm for programming the flash and leaves it in an odd state where you can only recover from using powercycle. Always make sure you use the latest HEAD version of the texane/stlink repository, or else we are unable to support you. Also it needs investigation why it fails. Most flash drivers are identical for a series of processors so I think indeed the "L0x3" should not be the issue. You could also dig into the git history to see the original author of the STM32L flash driver as I have no detailed knowledge why it should not work.

Thanks for reporting!

[12amOil]

Thanks for the reply. I had pulled down the head of the repository and built it; it seems to behave much better. It is also tagged as 1.5.2 (IIRC, I know it was 1.5.x) so ignore my mumble about 1.3.0 before; the summary must be out of date.

[Nightwalker-87]

@Ant-ON: What's your opinion on this one?
To me it looks different to the flash loader errors we've seen so far...

[Ant-ON]

@Nightwalker-87 Yes, the error is different since the flash loading code for L0 and L1 is slightly different from other series. Most likely the problem in SysTick interrupts and it's fixed by #1113

[Nightwalker-87]

Closed by #1113.