STM32L476 DISCOVERY: st-flash failing to write

[tabemann]

Thank you for giving feedback to the stlink project.

In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:

• Programmer/board type: Stlink /v2-1
• Programmer firmware version: version integrated with STM32L476 DISCOVERY
• Operating system and version: Linux 5.5.0-1-amd64
• Stlink tools version and/or git commit hash: v1.6.1 (from release .tar.gz)
• Stlink commandline tool name: st-flash
• Target chip (and board if applicable): STM32L476 DISCOVERY

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

tabemann@sirius:~/projects/zeptoforth$ st-flash write zeptoforth.bin 0x08000000
st-flash 1.6.1
2020-06-12T22:42:05 INFO common.c: L4xx: 96 KiB SRAM, 1024 KiB flash in at least 2 KiB pages.
file zeptoforth.bin md5 checksum: d1e51663b9f8971cf1167145c9e76850, stlink checksum: 0x001cfa29
2020-06-12T22:42:05 INFO common.c: Attempting to write 23324 (0x5b1c) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Page:0x0 Size:0x800 2020-06-12T22:42:05 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Page:0x1 Size:0x800 2020-06-12T22:42:05 INFO common.c: Flash page at addr: 0x08000800 erased
EraseFlash - Page:0x2 Size:0x800 2020-06-12T22:42:05 INFO common.c: Flash page at addr: 0x08001000 erased
EraseFlash - Page:0x3 Size:0x800 2020-06-12T22:42:05 INFO common.c: Flash page at addr: 0x08001800 erased
EraseFlash - Page:0x4 Size:0x800 2020-06-12T22:42:05 INFO common.c: Flash page at addr: 0x08002000 erased
EraseFlash - Page:0x5 Size:0x800 2020-06-12T22:42:05 INFO common.c: Flash page at addr: 0x08002800 erased
EraseFlash - Page:0x6 Size:0x800 2020-06-12T22:42:06 INFO common.c: Flash page at addr: 0x08003000 erased
EraseFlash - Page:0x7 Size:0x800 2020-06-12T22:42:06 INFO common.c: Flash page at addr: 0x08003800 erased
EraseFlash - Page:0x8 Size:0x800 2020-06-12T22:42:06 INFO common.c: Flash page at addr: 0x08004000 erased
EraseFlash - Page:0x9 Size:0x800 2020-06-12T22:42:06 INFO common.c: Flash page at addr: 0x08004800 erased
EraseFlash - Page:0xa Size:0x800 2020-06-12T22:42:06 INFO common.c: Flash page at addr: 0x08005000 erased
EraseFlash - Page:0xb Size:0x800 2020-06-12T22:42:06 INFO common.c: Flash page at addr: 0x08005800 erased
2020-06-12T22:42:06 INFO common.c: Finished erasing 12 pages of 2048 (0x800) bytes
2020-06-12T22:42:06 INFO common.c: Starting Flash write for F2/F4/L4
2020-06-12T22:42:06 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 23324
2020-06-12T22:42:06 ERROR flash_loader.c: flash loader run error
2020-06-12T22:42:06 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Expected/description:

That st-flash would successfully write zeptoforth.bin onto the flash memory of the STM32L476 MCU, at 0x08000000.

NOTICE: This bug report may be closed without further notice, if not enough information is provided!

Thank you for your support.

The stlink project maintainers

[Crest]

I ran into the same regression on a Nucleo L476RG board both stlink 1.5.0 and 1.6.0 work for me, but the latest version from git produces this output (after I stopped it from spamming USB log messages to stdout):

st-flash 1.6.0-370-g05f79e1-dirty
2020-06-13T07:03:42 INFO common.c: L4xx: 96 KiB SRAM, 1024 KiB flash in at least 2 KiB pages.
file /home/crest/mecrisp-stellaris-2.5.4/mecrisp-stellaris-source/stm32l476-ra-nucleo/mecrisp-stellaris-stm32l476.bin md5 checksum: 2a291252c8ab59ec649217f666b78d4, stlink checksum: 0x001f2ba2
2020-06-13T07:03:42 INFO common.c: Attempting to write 20304 (0x4f50) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Page:0x0 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Page:0x1 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08000800 erased
EraseFlash - Page:0x2 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08001000 erased
EraseFlash - Page:0x3 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08001800 erased
EraseFlash - Page:0x4 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08002000 erased
EraseFlash - Page:0x5 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08002800 erased
EraseFlash - Page:0x6 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08003000 erased
EraseFlash - Page:0x7 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08003800 erased
EraseFlash - Page:0x8 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08004000 erased
EraseFlash - Page:0x9 Size:0x800 2020-06-13T07:03:42 INFO common.c: Flash page at addr: 0x08004800 erased
2020-06-13T07:03:42 INFO common.c: Finished erasing 10 pages of 2048 (0x800) bytes
2020-06-13T07:03:42 INFO common.c: Starting Flash write for F2/F4/L4
2020-06-13T07:03:42 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 20304
2020-06-13T07:03:43 ERROR flash_loader.c: flash loader run error
2020-06-13T07:03:43 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

[geoffreymbrown]

I think this may be a timing issue. I had the same problem with the stm32l432. I made the following change in flash_loader.c that seem to resolve the issue. I hesitate to say that's the root cause.

@@ -368,7 +368,7 @@ int stlink_flash_loader_run(stlink_t *sl, flash_loader_t* fl
, stm32_addr_t targe
 // by increasing the sleep-per-round to the same order-of-magnitude as
 // the tick-rounding that the OS uses, the wait until the error message is
 // reduced to the same order of magnitude as what was intended. -- REW.
-#define WAIT_ROUNDS 100
+#define WAIT_ROUNDS 200
     /* wait until done (reaches breakpoint) */
     for (i = 0; i < WAIT_ROUNDS; i++) {
         usleep(1000);

[Nightwalker-87]

@geoffreymbrown: Could you submit this as a PR, as soon as @tabemann and/or @Crest verified?

[Crest]

I tested the patch in the develop branch with Nucleo STM32L476RG board and its onboard ST-LINK/V2-1. The patch fixed the regression. Thanks for looking into this.

[Nightwalker-87]

@geoffreymbrown: I'll leave this to you then...