Confirm image on STM32WL is not working

[niondir]

I'm using arm mbed with MCUBoot on an STM32WL.

I'ts a custom target:

"MCU_STM32WLE5xC" : {
        "inherits" : [
            "MCU_STM32WL"
        ],
        "extra_labels_add": [
            "STM32WLE5xC"
        ],
        "macros_add": [
            "STM32WLE5xx"
        ],
        "mbed_rom_start": "0x8000000",
        "mbed_rom_size": "0x40000",
        "mbed_ram_start": "0x20000000",
        "mbed_ram_size": "0x10000",
        "bootloader_supported": true,
        "sectors": [
            [
                134217728,
                2048
            ]
        ]
    }

When the app starts it always fails to write the image_ok flag. The STM32WL seems to need an full page erase (2048 Bytes) before writing to flash.

My current Workaround is to confirm the firmware by deleting the update area (thus no rollback can happen). I could also keep the last 2048 Byte free of firmware - but I need the space.

Are there other controllers with similar issues? How to deal with it?

[d3zd3z]

I believe this part has a minimum write size of 8 bytes, can you verify that the flash_align value is 8, and that the partitions are reasonable. This should be supportable in MCUboot, at least if I'm reading the datasheet correctly.

If it indeed does require entire pages to be written and erased, it would not be supported currently (although there is work in progress to support these so-called large-write devices).

[niondir]

I tried with 8 byte buffers and it did not work. I did not check the data sheet if there is some low level register to change the behavior yet.

[d3zd3z]

BTW, if you aren't worried about revert, you can mark the image as already confirmed by passing --confirm to imgtool.py. You can also build MCUboot with "overwrite only" which basically enforces this mode.

Do you know if the STM32WL flash is similar to the flash on other STM32 devices? We have used MCUboot on some of these devices.

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[niondir]

@d3zd3z The issue is not mbed specific. Meanwhile we migrated away from mbed-os and using freeRTOS.

It's also still relevant. When not implementing the write to flash correctly, swap_type and copy_done information, and probably also the swap state are not written correctly.

I was able to confirm my image, but now a second update is not executed due to "bad state" in the primary slot. A real fix will need to adjust the flash driver to always read, erase, weite back a full 2k flash page.

[niondir]

Do you have a reference where work is large-write devices done?