STM32G031G8: Verification of flash failed - and using STM32CubeIDE to flash temporarily fixes it?

[tcbennun]

• I made serious effort to avoid creating duplicate or nearly similar issue
• Programmer/board type: NUCLEO-F302R8 (ST-LINK/V2-1)
• Operating system an version: Debian 10
• stlink tools version and/or git commit hash: v1.6.1
• stlink commandline tool name: st-flash
• Target chip (and board, if applicable): STM32G031G8Ux

This hardware configuration flashes correctly when using the STM32CubeIDE software (flashing using STM32CubeProgrammer v2.7.0-RC1).

Flashing using st-flash v1.6.1, I get:

$ st-flash write build/fw.bin 0x8000000
st-flash 1.6.1
2021-04-19T14:28:46 INFO common.c: G030/G031/G041: 8 KiB SRAM, 64 KiB flash in at least 2 KiB pages.
file build/fw.bin md5 checksum: 7ac3767e3770e96cb19d1c104f32bc9a, stlink checksum: 0x001c188e
2021-04-19T14:28:46 INFO common.c: Attempting to write 20620 (0x508c) bytes to stm32 address: 134217728 (0x8000000)
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08000000 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08000800 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08001000 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08001800 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08002000 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08002800 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08003000 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08003800 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08004000 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08004800 erased
2021-04-19T14:28:46 INFO common.c: Flash page at addr: 0x08005000 erased
2021-04-19T14:28:46 INFO common.c: Finished erasing 11 pages of 2048 (0x800) bytes
Writing
Starting  10 page write
2021-04-19T14:28:48 INFO common.c: Starting verification of write complete
2021-04-19T14:28:48 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

"Verification of flash failed" is misleading; the flash has apparently not occurred at all. Using my UART output, I can see that the old binary is still on the device.

What's especially interesting is the following. If I flash a binary through CubeIDE, and then immediately attempt to flash another binary with st-flash, it suddenly works:

$ st-flash write build/fw.bin 0x8000000
st-flash 1.6.1
2021-04-19T14:28:12 INFO common.c: G030/G031/G041: 8 KiB SRAM, 64 KiB flash in at least 2 KiB pages.
file build/fw.bin md5 checksum: 7153a889c81ff354c2e81da3102c8d5, stlink checksum: 0x001bf5cf
2021-04-19T14:28:12 INFO common.c: Attempting to write 20552 (0x5048) bytes to stm32 address: 134217728 (0x8000000)
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08000000 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08000800 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08001000 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08001800 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08002000 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08002800 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08003000 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08003800 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08004000 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08004800 erased
2021-04-19T14:28:12 INFO common.c: Flash page at addr: 0x08005000 erased
2021-04-19T14:28:12 INFO common.c: Finished erasing 11 pages of 2048 (0x800) bytes
Writing
Starting  10 page write
2021-04-19T14:28:14 INFO common.c: Starting verification of write complete
2021-04-19T14:28:14 INFO common.c: Flash written and verified! jolly good!

... and I'm able to verify via UART output that this binary has in fact loaded.

However, if I then try to flash a different binary with st-flash, it persistently breaks again, same as the output given at the top of the post -- until STM32CubeProgrammer performs a flash again.

Seems to me as though STM32CubeProgrammer is performing a pre- or post-flash step that st-flash is not. The effect of the step must persist after its flash is complete.

I can see that STM32G0 support was built into st-flash a while ago. However, no G0 chips seem to have been tested in conjunction with the NUCLEO-F302R8 programmer board, so I'm outside of official support in that sense!

Many thanks.

[tcbennun]

My apologies, this seems to have already been fixed in develop since v1.6.1.

bisect reveals that this issue appears resolved from commit cb551d50f879 (PR #1126). However, multiple bisect iterations were 'bad' simply because of the issue that this PR resolved, not the issue I've listed here!

Either way, closing.

[Nightwalker-87]

Please leave closing to automated project maintenance.

[Nightwalker-87]

Closed by #1126.