[STM32G0B1RE]: st-flash fails seemingly randomly

[OpusElectronics]

Hello, using st-flash 1.8.0 on Linux here.

When flashing a STM32G0B1RE on a Nucleo 64 board, flashing often (but not always) fails with the following sequence:

st-flash 1.8.0
2025-06-21T18:24:02 INFO common.c: STM32G0Bx_G0Cx: 144 KiB SRAM, 512 KiB flash in at least 2 KiB pages.
2025-06-21T18:24:02 WARN common_flash.c: Flash base use default L0 address
file NFC_Reader.bin md5 checksum: 5951891abe16bfd9fa234e522b8a4d87, stlink checksum: 0x006b9a59
2025-06-21T18:24:02 INFO common_flash.c: Attempting to write 74024 (0x12128) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8012000 erased (size: 0x800)
2025-06-21T18:24:02 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5/H5/C0
 36/36  pages written
2025-06-21T18:24:11 ERROR common_flash.c: Invalid flash address
2025-06-21T18:24:11 ERROR common_flash.c: Flash programming error: 0x00000080
stlink_fwrite_flash() == -1

But sometimes, it succeeds. Even with the exact same binary file.
When it fails, it can fail similarly for a number of attempts. It will eventually succeed.

What I noticed, if that can help find the cause, is that when it fails as above, the erase phase seems to be almost instant, while when it succeeds, it takes a bit more time (enough so that we can see the message -> Flash page at 0x8012000 erased (size: 0x800) changing.

Here is the "normal" report when it succeeds:

st-flash 1.8.0
2025-06-21T18:15:17 INFO common.c: STM32G0Bx_G0Cx: 144 KiB SRAM, 512 KiB flash in at least 2 KiB pages.
2025-06-21T18:15:17 WARN common_flash.c: Flash base use default L0 address
file NFC_Reader.bin md5 checksum: 213d8763ec8b546a19e94ddff03a6f6, stlink checksum: 0x006b9a5b
2025-06-21T18:15:17 INFO common_flash.c: Attempting to write 74024 (0x12128) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8012000 erased (size: 0x800)
2025-06-21T18:15:18 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5/H5/C0
 36/36  pages written
2025-06-21T18:15:28 INFO common_flash.c: Starting verification of write complete
2025-06-21T18:15:28 INFO common_flash.c: Flash written and verified! jolly good!

[a-michelis]

Some additional context after some research:

We see:

2025-06-21T18:15:17 WARN common_flash.c: Flash base use default L0 address

that is called @ get_stm32l0_flash_base, which, according to the code, can only be called when sl->flash_type is STM32_FLASH_TYPE_L0_L1

actually, this also gets called by stop_wdg_in_debug in this specific scenario (flash_type is STM32_FLASH_TYPE_G0)

So, 0x80 indicates PGSERR
According to Reference diagram:

Set by hardware when a write access to the flash memory is performed by the code while
PG or FSTPG have not been set previously. Set also by hardware when PROGERR,
SIZERR, PGAERR, WRPERR, MISSERR or FASTERR is set due to a previous
programming error.

Cleared by writing 1.

That, apparently means that PGAERR catched in the error checking function is the cause. we do not see any other error present.

PGAERR indicates that:

Set by hardware when the data to program cannot be contained in the same double word
(64-bit) flash memory in case of standard programming, or if there is a change of page
during fast programming.

Cleared by writing 1.

The part in bold is the one that seems more promising.

Also, this seems related to #1321

[Nightwalker-87]

This issue definitely requires input from the community, particularly from users who have experience with the affected MCU family. Your help in resolving it would be greatly appreciated.

[Nightwalker-87]

Functions stlink_mwrite_flash(...) and stlink_fwrite_flash(...) in common_flash.c might be of interest here:

  /*
   * TODO: investigate a kind of weird behaviour here:
   * If the file is identified to be all-empty and four-bytes aligned,
   * still flash the whole file even if ignoring message is printed.
   */
  err = stlink_write_flash(sl, addr, data,
                          (num_empty == length) ? length : length - num_empty,
                          num_empty == length, erase_type);
  stlink_fwrite_finalize(sl, addr);
  return (err);

and

  /*
   * TODO: investigate a kind of weird behaviour here:
   * If the file is identified to be all-empty and four-bytes aligned,
   * still flash the whole file even if ignoring message is printed.
   */

  /* In case the address is within the OTP area we use a different flash method */
  if(addr >= sl->otp_base && addr < sl->otp_base + sl->otp_size) {
    err = stlink_write_otp(sl, addr, mf.base,
                           (num_empty == mf.len) ? (uint32_t) mf.len : (uint32_t) mf.len - num_empty);
  } else {
    err = stlink_write_flash(sl, addr, mf.base,
                           (num_empty == mf.len) ? (uint32_t) mf.len : (uint32_t)mf.len - num_empty,
                           num_empty == mf.len, erase_type);
  }
  stlink_fwrite_finalize(sl, addr);
  unmap_file(&mf);
  return (err);

However the main point may indeed be a timing issue on the G0-Series, as this MCU type does not seem to provide parallel R/W access, as available in other STM32-Series, what may result in the described non-deterministic behaviour. One may try to add the delay below in common_flash.c and give it another try:

    // STM32G0
    if(sl->flash_type == STM32_FLASH_TYPE_G0) {
      uint32_t flash_page = ((flashaddr - STM32_FLASH_BASE) / sl->flash_pgsz);
      stlink_read_debug32(sl, STM32_FLASH_Gx_CR, &val);
      // sec 3.7.5 - PNB[9:0] is offset by 3. PER is 0x2.
      val &= ~(0x3FF << 3);
      val |= ((flash_page & 0x3FF) << 3) | (1 << FLASH_CR_PER);
      stlink_write_debug32(sl, STM32_FLASH_Gx_CR, val);

    // wait 100 ms to ensure flash controller is ready (no parallel R/W for STM32G0)
    #ifdef _WIN32
        Sleep(100);
    #else
        usleep(100000);
    #endif

I don't know if this resolves this issue properly though, it rather feels like a temporary workaround...
Please give it a try and also do further investigations to help resolve this topic.