STM32G491: programming flash error, non-erased value.

[salyzyn]

Ubuntu 22.04 (linux)

any v1.7.0 version of st-flash exhibits the problem as shipped in ubuntu, and then we built v1.7.0-263-g8de2b4d latest from git pull and reproduced.

NUCLEO-G491RE with on-board STLink/V3. Chip is an STM32G491RE6.

$ st-info --probe
Found 1 stlink programmers
version: V3J10
serial: 0009002C4D46501020383832
flash: 524288 (pagesize: 2048)
sram: 114688
chipid: 0x479
dev-type: STM32G49x_G4Ax

Happens even if we round the size of the flash image up to the next 2Kbyte boundary. Some other flashing bugs with same WB/G0/G4/L5/U5 system indicated fill to 16 byte boundary solved their unrelated issue, we tried 16, 512 and 2048 byte 0xFF roundup to the image size.

NB: an sboot _stm32 bootblock resides at 0x8000000, and runs the executable at 0x8004000. We have similar flash issue if we KISS and drop the UDF bootblock and run on iron at 0x8000000, albeit with slightly more chances of success to run with the borken(sic) flash report. We do correct SCB->VTOR, so no FUD there.

$ st-flash st-flash --connect-under-reset --debug write build/NUCLEO-G491RE.checked 0x8004000
st-flash 1.7.0-263-g8de2b4d
2023-04-29T10:48:28 INFO common.c: STM32G49x_G4Ax: 112 KiB SRAM, 512 KiB flash in at least 2 KiB pages.
file build/NUCLEO-G491RE.checked md5 checksum: b6f199bd74a22ad196b2974f40d2d9, stlink checksum: 0x01c4ab4c
2023-04-29T10:48:28 INFO common_flash.c: Attempting to write 284672 (0x45800) bytes to stm32 address: 134234112 (0x8004000)
. . .
-> Flash page at 0x8049000 erased (size: 0x800)
2023-04-29T10:48:31 INFO flashloader.c: Starting Flash write for WB/G0/G4/L5/U5
. . .
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_debug32 0xffffffff to 0x080497ec
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_debug32 0xffffffff to 0x080497f0
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_debug32 0xffffffff to 0x080497f4
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_debug32 0xffffffff to 0x080497f8
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010
139/139 pages written
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_debug32 0xffffffff to 0x080497fc
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010

2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010
2023-04-29T10:42:37 ERROR common_flash.c: Flash memory contains a non-erased value
2023-04-29T10:42:37 ERROR common_flash.c: Flash programming error: 0x000000a0
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_debug32 0x080049ad at 0x08004004
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_reg
2023-04-29T10:42:37 DEBUG common.c: *** stlink_run ***
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_read_reg
2023-04-29T10:42:37 DEBUG read_write.c: (16) ***
2023-04-29T10:42:37 DEBUG common.c: data_len = 8 0x8
80 00 00 00 00 00 00 01
2023-04-29T10:42:37 DEBUG usb.c: r_idx (16) = 0x01000000
stlink_fwrite_flash() == -1
2023-04-29T10:42:37 DEBUG common.c: *** stlink_exit_debug_mode ***
2023-04-29T10:42:37 DEBUG read_write.c: *** stlink_write_debug32 0xa05f0000 to 0xe000edf0

Expected the device to flash and run. Sometimes it does run if code is changed and positions moves, but flakey. When we flash with the built-in tools with STM32cubeIDE, the same binary flashes and runs appropriately independently or under the debugger.

[salyzyn]

NB: if we erase the entire product and reflash boot block, application and parameter regions, flashing reports no issue with non-erased values. But the erasure of the UDF bootblock and parameters is kinda destructive.

[Nightwalker-87]

@salyzyn Unfortunately I can't reproduce this with a STM32G431 Nucleo-32 board under similar conditions.

[salyzyn]

I believe this issue may be related to the STM32G491 having 512KB of flash, STM32G431 only has 128KB. The report I provided was for a flash image that breached the 256KB 'bank' boundary. Which now that I see that, i have my suspicions. I have internal flash code in my application that uses the top 16KB of flash to simulate nonvolatile memory through a journaling filesystem. The problem is that the necessary manifest defines are left undefined in the HAL headers when the overarching config indicates the product is not in dual-bank mode, yet they are essential for access when in that fixed dual bank mode despite the config. We have to check the actual device's configuration. Hence why I have the #ifndef references below. The chips are shipped out in dual-bank mode and since stlink and IDE do not have a capability to switch it out of that mode, I have to be sensitive to this state. Since I found my workaround as cited below to calculate the appropriate Bank and Sectors used when erasing and flashing, I never stepped aside and used alternate tools to switch the STM32G491 into single bank mode, hence your problem in the tool. There is a performance advantage because writes/erasures to the second bank do not block MPU cycles for read accesses to the first bank, or so they say in the documentation, although for the most part not an issue since the STM32G491 also has a program cache that it hits instead of hitting flash. I hope the following helps identify what I believe to be the issue. NB: I do not complain in my code if I try to write content to flash that is already there, but since there is a CRC, one can not correct it (change just the 1s to 0s if it takes it) of course like we can do in other products without CRC protection of flash. My code will accept changing 1s to 0s, in other product's flash, other than STM32G491, but of course never supports changing 0s to 1s without an intervening block erase.

#ifndef OB_USER_DBANK
#define OB_USER_DBANK             0x00000100U              /*!< Single bank with 128-bits data or two banks with 64-bits data */
#endif

static uint32_t GetPage(uintptr_t Addr) {
        if (READ_BIT(FLASH->OPTR, OB_USER_DBANK)) {
                if (Addr < (FLASH_BASE + (FLASH_SIZE >> 1))) {
                        return (Addr - FLASH_BASE) / FLASH_PAGE_SIZE;
                }
                return (Addr - (FLASH_BASE + (FLASH_SIZE >> 1)))
                                / FLASH_PAGE_SIZE;
        }
        return (Addr - FLASH_BASE) / FLASH_PAGE_SIZE;
}

static uint32_t GetBank(uintptr_t Addr) {
        if (READ_BIT(FLASH->OPTR, OB_USER_DBANK)) {  // unexpected
                if (Addr < (FLASH_BASE + (FLASH_SIZE >> 1))) {
                        return FLASH_BANK_1;
                }
#ifdef FLASH_BANK_2
#pragma message("warning: FLASH_OPT_DBANK defined!")
                return FLASH_BANK_2;
#else
                return FLASH_BANK_1 << 1;
#endif
        }
        return FLASH_BANK_1;
}


bool Nonvolatile::erase(void(*callback)(void)) {
        if (unlikely_debug(!flashStart_)
         || unlikely_debug(!flashEnd_)
         || unlikely_debug(flashStart_ >= flashEnd_)
         || unlikely_debug((flashEnd_ | flashStart_) & 3)
         || unlikely_debug(!!private_)) {
                dputs("Fatal: Nonvolatile::erase incorrect configuration\r\n");
                executive_pushSlow(callback);
                return false;
        }
        if (!isErased()) {
                __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP
                                        | FLASH_FLAG_OPERR
                                        | FLASH_FLAG_PROGERR
                                        | FLASH_FLAG_WRPERR
                                        | FLASH_FLAG_PGAERR
                                        | FLASH_FLAG_SIZERR
                                        | FLASH_FLAG_PGSERR
                                        | FLASH_FLAG_MISERR
                                        | FLASH_FLAG_FASTERR
                                        | FLASH_FLAG_OPTVERR);
                __HAL_FLASH_DATA_CACHE_DISABLE();
                __HAL_FLASH_DATA_CACHE_RESET();
                __HAL_FLASH_DATA_CACHE_ENABLE();
#ifdef DEBUG
#if (DEBUG + 0) > 0
                dputs("HAL_FLASH_Unlock() = ");
#endif
#endif
                if (unlikely(HAL_FLASH_Unlock() != HAL_OK)) {
#ifdef DEBUG
#if (DEBUG + 0) > 0
                        dputs("?\r\n");
#endif
#endif
                        executive_pushSlow(callback);
                        return false;
                }
#ifdef DEBUG
#if (DEBUG + 0) > 0
                dputs("HAL_OK\r\n");
#endif
#endif

                private_ = calloc(sizeof(FLASH_EraseInitTypeDef), 1);
                auto pErase = reinterpret_cast<FLASH_EraseInitTypeDef*>(
                                                                private_);
                pErase->TypeErase = FLASH_TYPEERASE_PAGES;
                pErase->Banks = GetBank(flashStart_);
                pErase->Page = GetPage(flashStart_);
                pErase->NbPages = GetPage(flashEnd_) - pErase->Page;
                callbackFromEraseOrWrite_ = callback;
#ifdef DEBUG
#if (DEBUG + 0) > 0
                std::stringstream s;
                s << "HAL_FLASHEx_Erase_IT({0x" << std::hex << pErase->TypeErase
                  << ", 0x" << pErase->Banks << ", 0x" << pErase->Page
                  << ", " << std::dec << pErase->NbPages << "}) = ";
#else
                dputs("HAL_FLASHEx_Erase_IT(pErase) = ");
#endif
#endif
                __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_OPTVERR);
#if defined(FLASH_SR_OPTVERR)
                if (FLASH->SR != 0) {
                        FLASH->SR = FLASH_SR_OPTVERR;
                }
#endif
                auto FlashStatus = HAL_FLASHEx_Erase_IT(pErase);
                if (unlikely(FlashStatus != HAL_OK)) {
#ifdef DEBUG
#if (DEBUG + 0) > 0
                        s << "0x" << std::hex << FlashStatus
                          << "\r\nHAL_FLASH_Lock()\r\n";
                        dputs(std::move(s));
#else
                        dputs("?\r\nHAL_FLASH_Lock()\r\n");
#endif
#endif
                        HAL_FLASH_Lock();
                        callbackFromEraseOrWrite_ = nullptr;
                        free(pErase);
                        private_ = nullptr;
                        executive_pushSlow(callback);
                        return false;
                }
#ifdef DEBUG
#if (DEBUG + 0) > 0
                s << "HAL_OK\r\n";
                dputs(std::move(s));
#else
                dputs("HAL_OK\r\n");
                dputs(std::move(s));
#else
                dputs("HAL_OK\r\n");
#endif
#endif
                return true;
        }
        executive_pushSlow(callback);
        return true;
}

[jast1982]

Hi!

I have the same issue with STM32G491RET and code which is larger than 256kbyte. I use the latest git version compiled for yocto linux and an ST-Link V3. I'll try to switch to single bank via STM32CubeProg today and see if that helps.

Regards,
Jan

[Nightwalker-87]

@salyzyn We currently have no dual-bank support implemented for this device - that's for sure.

[salyzyn]

stM32g4 has three flash options, Category 2, 3 and 4, the stm32g491 is Category 4. in Category 3 block size is 2K for dual bank, and 4K for single bank, whereas Category 4 is 2K for both single and dual bank configurations. What a wild ride. Is there anything I can do to help?

[Nightwalker-87]

@salyzyn Indeed... I need to gain an overview first of what is currently supported in the codebase and what is missing. Please give me a few days for that.

Do you have a L0 device as well or know anybody?
We still need some feedback on issue (no. 681) also, which is another major topic I'd like to see closed soon...

[salyzyn]

I only have f429 and g491. No L0 device. I am hitting the road tomorrow, so dev work from campgrounds. Do you think sending you a NUCLEO-G491RE will help? PM me deets and hopefully can send you something from mouser?

[Nightwalker-87]

Thanks for the kind offer. I may find the specific Nucleo board at work when looking at it's specs, will check soon.
However I'd first need to look into the code in more detail. I'll let you know about the results.

[Nightwalker-87]

@salyzyn Try this:

1. in /config/chips/G49x_G4Ax.chip change flags swo to flags swo dualbank , otherwise there can be no dualbank handling at all from my understanding.
2. in /stlink-lib/common.c Line 288 we should have:

if (sl->chip_id == STM32_CHIPID_G4_CAT3 ||
      sl->chip_id == STM32_CHIPID_G4_CAT4) {

I'm not sure if that fixes it, but both steps at least seem to be part of the solution.

I further noticed that option byte programming support seems absent for this device.
Here we need case STM32_CHIPID_G4_CAT4: added in /stlink-lib/option_bytes.c L1014

[Nightwalker-87]

... the board at work is a Nucleo-G474RE 😒 - whatever, as it has dualbank as well, i'll give it a try to see what is happening.

[Nightwalker-87]

@salyzyn: I could reproduce the observed behaviour and found a reason for it. 🎉
The same happens on a Nucleo-G474RE when the dualbank flag is not set in the related .chip file.

st-flash --debug --connect-under-reset write /test.bin 0x8000000

[...]
2023-05-11T21:41:28 DEBUG read_write.c: *** stlink_read_debug32 0x000000a8 at 0x40022010
2023-05-11T21:41:28 ERROR common_flash.c: Flash memory contains a non-erased value
2023-05-11T21:41:28 ERROR common_flash.c: Flash programming error: 0x000000a0
2023-05-11T21:41:28 DEBUG read_write.c: *** stlink_read_debug32 0x08000afd at 0x08068004
2023-05-11T21:41:28 DEBUG read_write.c: *** stlink_write_reg
2023-05-11T21:41:28 DEBUG common.c: *** stlink_run ***
2023-05-11T21:41:28 DEBUG read_write.c: *** stlink_read_reg
2023-05-11T21:41:28 DEBUG read_write.c:  (16) ***
2023-05-11T21:41:28 DEBUG common.c: data_len = 8 0x8
 80 00 00 00 00 00 00 01
2023-05-11T21:41:28 DEBUG usb.c: r_idx (16) = 0x01000000
stlink_fwrite_flash() == -1
2023-05-11T21:41:28 DEBUG common.c: *** stlink_exit_debug_mode ***
2023-05-11T21:41:28 DEBUG read_write.c: *** stlink_write_debug32 0xa05f0000 to 0xe000edf0
2023-05-11T21:41:28 DEBUG common.c: *** stlink_close ***

[salyzyn]

Just got internet/laptop. sounds like you have the solution without my help ;->

Thanks!

Does your solution work for the stm32g474 (a category 3 device, where the block size changes 2k/4k depending on bank selection mode) in either mode (READ_BIT(FLASH->OPTR, OB_USER_DBANK) returning true or false)? It might be the more complex chip to manage. The stm32g491/stm32g4a1 are a category 4 devices, which AFAIK only means the block size remains constant 2k regardless if in single bank or dual bank mode, all else is similar I suspect, but by no means am I an expoit(sic)

[Nightwalker-87]

You are welcome. Can you verify the result on your side? I plan to look at the STM32G474 case this weekend.

[Nightwalker-87]

It does work on the Nucleo-G474RE as well. The lengthy debug output shows nothing remarkable, so I'm skipping it here.

st-flash --connect-under-reset write /test.bin 0x8000000

st-flash 1.7.0-283-g88201a8-dirty
2023-05-14T22:10:23 INFO common.c: STM32G47x_G48x: 128 KiB SRAM, 512 KiB flash in at least 2 KiB pages.
file /test.bin md5 checksum: 5761fe3885e985c3021dd8aceb38db9, stlink checksum: 0x00f78dcc
2023-05-14T22:10:23 INFO common_flash.c: Attempting to write 65536 (0x10000) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x800)
-> Flash page at 0x8000800 erased (size: 0x800)
-> Flash page at 0x8001000 erased (size: 0x800)
-> Flash page at 0x8001800 erased (size: 0x800)
-> Flash page at 0x8002000 erased (size: 0x800)
-> Flash page at 0x8002800 erased (size: 0x800)
-> Flash page at 0x8003000 erased (size: 0x800)
-> Flash page at 0x8003800 erased (size: 0x800)
-> Flash page at 0x8004000 erased (size: 0x800)
-> Flash page at 0x8004800 erased (size: 0x800)
-> Flash page at 0x8005000 erased (size: 0x800)
-> Flash page at 0x8005800 erased (size: 0x800)
-> Flash page at 0x8006000 erased (size: 0x800)
-> Flash page at 0x8006800 erased (size: 0x800)
-> Flash page at 0x8007000 erased (size: 0x800)
-> Flash page at 0x8007800 erased (size: 0x800)
-> Flash page at 0x8008000 erased (size: 0x800)
-> Flash page at 0x8008800 erased (size: 0x800)
-> Flash page at 0x8009000 erased (size: 0x800)
-> Flash page at 0x8009800 erased (size: 0x800)
-> Flash page at 0x800a000 erased (size: 0x800)
-> Flash page at 0x800a800 erased (size: 0x800)
-> Flash page at 0x800b000 erased (size: 0x800)
-> Flash page at 0x800b800 erased (size: 0x800)
-> Flash page at 0x800c000 erased (size: 0x800)
-> Flash page at 0x800c800 erased (size: 0x800)
-> Flash page at 0x800d000 erased (size: 0x800)
-> Flash page at 0x800d800 erased (size: 0x800)
-> Flash page at 0x800e000 erased (size: 0x800)
-> Flash page at 0x800e800 erased (size: 0x800)
-> Flash page at 0x800f000 erased (size: 0x800)
-> Flash page at 0x800f800 erased (size: 0x800)

2023-05-14T22:10:24 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5

  1/ 32 pages written
  2/ 32 pages written
  3/ 32 pages written
  4/ 32 pages written
  5/ 32 pages written
  6/ 32 pages written
  7/ 32 pages written
  8/ 32 pages written
  9/ 32 pages written
 10/ 32 pages written
 11/ 32 pages written
 12/ 32 pages written
 13/ 32 pages written
 14/ 32 pages written
 15/ 32 pages written
 16/ 32 pages written
 17/ 32 pages written
 18/ 32 pages written
 19/ 32 pages written
 20/ 32 pages written
 21/ 32 pages written
 22/ 32 pages written
 23/ 32 pages written
 24/ 32 pages written
 25/ 32 pages written
 26/ 32 pages written
 27/ 32 pages written
 28/ 32 pages written
 29/ 32 pages written
 30/ 32 pages written
 31/ 32 pages written
 32/ 32 pages written
2023-05-14T22:10:30 INFO common_flash.c: Starting verification of write complete
2023-05-14T22:10:30 INFO common_flash.c: Flash written and verified! jolly good!

[Nightwalker-87]

@salyzyn I'm now waiting for your verification, before committing the proposed fixes, which would then close this issue per automation. Please report back as soon as you were able to do your testing.

[Nightwalker-87]

The dualbank flag issue mentioned earlier in this thread has been fixed in commit 92ad99f (this are the changes from above) and I've reviewed this ticket up to 17 May 2023. Taking into account the recent pause, we should start over from there again.
@salyzyn I'm currently working on the testing branch for further investigations.

[Nightwalker-87]

@salyzyn I can reproduce this now on a Nucleo-G431KB (STM32G43x_G44x):

st-flash --reset --flash=0x200000 write /.../BG_BOOT_APP_combine.bin 0x8000000
st-flash 1.7.0-289-gefc5c37-dirty
2023-06-09T16:28:39 INFO common.c: STM32G43x_G44x: 32 KiB SRAM, 128 KiB flash in at least 2 KiB pages.
Forcing flash size: --flash=0x00200000
file /.../BG_BOOT_APP_combine.bin md5 checksum: b97ea645b48ec8db44b748344490c06b, stlink checksum: 0x056ea4aa
2023-06-09T16:28:39 INFO common_flash.c: Attempting to write 761946 (0xba05a) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x80ba000 erased (size: 0x800)
2023-06-09T16:28:48 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5
372/372 pages written
2023-06-09T16:30:04 INFO common_flash.c: Starting verification of write complete
2023-06-09T16:30:05 ERROR common_flash.c: Verification of flash failed at offset: 131072
stlink_fwrite_flash() == -1

The error derives from here (L1393ff):

    if (memcmp(sl->q_buf, data + off, cmp_size)) {
      ELOG("Verification of flash failed at offset: %u\n", (uint32_t)off);
      return (-1);
    }

... but I couldn't make out the reason yet. It may have to do with alignment indeed tough.

[victor-dryad]

@salyzyn I can reproduce this now on a Nucleo-G431KB (STM32G43x_G44x):
... but I couldn't make out the reason yet. It may have to do with alignment indeed tough.

Make full erase, then by STM32CubeProgrammer check what was really flashed.
failed at offset: 131072 = 0x20000. Looks start of a page.

[Nightwalker-87]

I think we may be facing the same or at least a very similar issue here as with #1249 and #1305, so it may be a systematic problem.

[Nightwalker-87]

@victor-dryad I think I've made at least a little progress on my side: Leaving out --flash=0x200000 gives:

st-flash 1.7.0-290-gc5c8a46-dirty
2023-06-10T15:09:14 INFO common.c: STM32G43x_G44x: 32 KiB SRAM, 128 KiB flash in at least 2 KiB pages.
file /.../BG_BOOT_APP_combine.bin md5 checksum: b97ea645b48ec8db44b748344490c06b, stlink checksum: 0x056ea4aa
2023-06-10T15:09:14 INFO common_flash.c: Attempting to write 761946 (0xba05a) bytes to stm32 address: 134217728 (0x8000000)
2023-06-10T15:09:14 ERROR common_flash.c: The size exceeds the size of the flash (0x00020000 bytes available)
stlink_fwrite_flash() == -1

--> I need a smaller binary. How stupid. 🙈

Here is the second attempt with a 64 KiB binary:

st-flash 1.7.0-290-gc5c8a46-dirty
2023-06-10T15:22:48 INFO common.c: STM32G43x_G44x: 32 KiB SRAM, 128 KiB flash in at least 2 KiB pages.
file /.../test.bin md5 checksum: 5761fe3885e985c3021dd8aceb38db9, stlink checksum: 0x00f78dcc
2023-06-10T15:22:48 INFO common_flash.c: Attempting to write 65536 (0x10000) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x800f800 erased (size: 0x800)
2023-06-10T15:22:49 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5
 32/ 32 pages written
2023-06-10T15:22:55 INFO common_flash.c: Starting verification of write complete
2023-06-10T15:22:55 INFO common_flash.c: Flash written and verified! jolly good!

We should retry this on a STM32G491 with the latest testing branch now for further investigation.
@salyzyn Are you still there?

[victor-dryad]

@victor-dryad I think I've made at least a little progress on my side: Leaving out --flash=0x200000 gives:
2023-06-10T15:09:14 INFO common.c: STM32G43x_G44x: 32 KiB SRAM, 128 KiB flash in at least 2 KiB pages.
--> I need a smaller binary. How stupid. 🙈

To set up a right test for current issue, a device from this serie with 256 or 512KiB (2 or 4 * 128) is needed.

[Nightwalker-87]

Additional testing on a Nucleo-G474RE confirms the result by @salyzyn :

st-flash --reset write /.../test.bin 0x8000000 2>&1 | tee /.../out.txt
st-flash 1.7.0-293-gb72f5b5
2023-06-17T14:38:25 INFO common.c: STM32G47x_G48x: 128 KiB SRAM, 512 KiB flash in at least 2 KiB pages.
file /.../test.bin md5 checksum: 8819351492bdee93c5fdc8a2513bd5b, stlink checksum: 0x0423f07a
2023-06-17T14:38:25 INFO common_flash.c: Attempting to write 524256 (0x7ffe0) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x807f800 erased (size: 0x800)
2023-06-17T14:38:31 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5/H5
255/255 pages written
2023-06-17T14:39:20 ERROR common_flash.c: Flash memory contains a non-erased value
2023-06-17T14:39:20 ERROR common_flash.c: Flash programming error: 0x000000a0
stlink_fwrite_flash() == -1

with this .bin file ending:

00 00 00 1B F1 08 08 79 CA 08 08 00 00 00 00 60 67 0B 08 D6 37 0A 08 AE 32 09 08 AE 32 09 08 AE 32 09 08 AE 32 09 08 AE 32 09 08 AE 32
09 08 AE 32 09 08 AE 32 09 08 AE 32 09 08 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 01 00 41 53 43 49 49 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00

[Nightwalker-87]

The error seems to derive from common_flash.c L307ff within function int32_t check_flash_error(stlink_t *sl), where PROGERR is raised:

  case STM32_FLASH_TYPE_G0:
  case STM32_FLASH_TYPE_G4:
    res = read_flash_sr(sl, BANK_1) & FLASH_Gx_SR_ERROR_MASK;
    WRPERR = (1 << FLASH_Gx_SR_WRPERR);
    PROGERR = (1 << FLASH_Gx_SR_PROGERR);
    PGAERR = (1 << FLASH_Gx_SR_PGAERR);
    break;

... and it looks like, as if only single bank devices are addressed here. BANK_1 is defined in the related header file, as well as BANK_2 which is obviously not covered here. The definition of a separate FLASH_TYPE may be required for these dualbank-devices in order to get this verification / error checking to a working state.

[Nightwalker-87]

@salyzyn @jast1982 Try this:

  case STM32_FLASH_TYPE_G0:
  case STM32_FLASH_TYPE_G4:
    res = read_flash_sr(sl, BANK_1) & FLASH_Gx_SR_ERROR_MASK;
    if (sl->chip_flags & CHIP_F_HAS_DUAL_BANK) {
      res |= read_flash_sr(sl, BANK_2) & FLASH_Gx_SR_ERROR_MASK;
    }
    WRPERR = (1 << FLASH_Gx_SR_WRPERR);
    PROGERR = (1 << FLASH_Gx_SR_PROGERR);
    PGAERR = (1 << FLASH_Gx_SR_PGAERR);
    break;

With the same approach as above, this now leads to:

st-flash --reset write /.../test.bin 0x8000000 2>&1 | tee /home/nightwalker-87/Schreibtisch/out.txt
st-flash 1.7.0-293-gb72f5b5-dirty
2023-06-20T00:03:09 INFO common.c: STM32G47x_G48x: 128 KiB SRAM, 512 KiB flash in at least 2 KiB pages.
file /.../test.bin md5 checksum: 8819351492bdee93c5fdc8a2513bd5b, stlink checksum: 0x0423f07a
2023-06-20T00:03:09 INFO common_flash.c: Attempting to write 524256 (0x7ffe0) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x807f800 erased (size: 0x800)
2023-06-20T00:03:15 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5/H5
255/255 pages written
2023-06-20T00:04:04 INFO common_flash.c: Starting verification of write complete
2023-06-20T00:04:09 INFO common_flash.c: Flash written and verified! jolly good!

[salyzyn]

st-flash 1.7.0-294-gd4b53b0

Problem still exists, please PM me and I will arrange to send you a stm32g491 development board

[Nightwalker-87]

@salyzyn This is still a very kind offer, but I must admit that I'm not able to spend any time to dig into things deeper at the moment, so it wouldn't change anything really. Paid work takes precedence.