CubeProgrammer erase wrong sector on STM32H563VGT6 (1MB Flash) device

[Snaku]

Hi,

When I downloaded a .hex file to my STM32H563VGT6 (1MB Flash) using STM32CubeProgrammer v2.20.0, I encountered an issue where it would erase the wrong sector. For example, as shown in the image below, it was supposed to erase sectors (76..91) and sector 115, but I found that the contents of sector 27 is erased.

I also try to "Erase selected sectors" (76..116) manually, but sector 27 still be erased.

However, I did not have this problem when downloading the same .hex file using an STM32H563ZIT6 (2MB Flash).

[Snaku]

Hi Aziz,

I think the OEMiROT_Boot code interferes STM32CubeProgrammer is reading flash size.

1. I am using ST OEMiROT_Boot as the secure boot code.
Security:OEMiRoT OEMuRoT for STM32H5 - stm32mcu

2. I change the write protection setting 'WRPSGn1' to 0xFFFF_FFFF of the option bytes, it let me to erase the OEMiROT_Boot code area.

3. Then the CLI can perform the erase command without "Fail to read flash size" error.
> STM32_Programmer_CLI.exe -c port=SWD mode=hotplug freq=4000 -e [76 91]

So, you are correct, using hot-pulg mode can erase sectors [76 91] without error.

But what should I do while OEMiROT_Boot is running? Is the hide protection mechanism interfering the programmer read the flash size?

Thank you,
Snaku

[Aziz BRIGUI]

Thanks @Snaku for sharing the details, I wouldn't have guessed that.

I think yes, OEMiROT_Boot is somehow hiding the flash size address. This might link to STM32H563: CubeProgrammer UART connect fails in PR... - Page 2 - STMicroelectronics Community. Could you check my last comment and verify if you're using the latest version of CubeH5 ? If I remember correctly, the UART connection issue in the mentioned thread is linked to OEMiRot_Boot hiding the same address in previous versions.

Aziz

[Snaku]

Hi Aziz,
1. my STM32CubeH5 is version 1.5.1.
2. If the OEMiROT_Boot cause this issue, could we fix this issue by OEMiROT_Boot code? 
    or ST have plan to fix this issue by STM32CubeProgrammer?
Regards,
Snaku

[Aziz BRIGUI · Accepted solution]

Hi @Snaku,

The fix in STM32CubeProgrammer is planned, when that's done, you'll be able to resolve this by connecting in under reset mode (That way OEMiROT_boot won't be executed and won't interfere with STM32CubeProgrammer detecting the correct flash size => The correct sector indexes).

If I reproduce with OEMiROT_boot on my side and find a change to make that will resolve the issue, I'll let you know. With that being said, on the tool side, the correct behavior is what's happening in hotplug mode (We're connecting to the target that's running an application and that's by definition the hotplug mode, I don't think the tool will open additional memory regions if the running application hides them).

In any case, don't hesitate to comment if you find anything to improve on CubeH5 front as well, I'll be happy to transfer the request.

Kind regards,

Aziz

[Aziz BRIGUI]

Hi again @Snaku,

I think on CubeH5 we're OK as well since there's a define that needs to be uncommented for 1M flash size in flash_layout.h:

#define DEVICE_1M_FLASH_ENABLE

This is also mentioned in the  OEMiROT_Boot readme:

I've tried the same scenario with the line and without it and it seems to solve the issue. Could you confirm at your end ?

Aziz

[Snaku]

Hi Aziz,

When I find this wrong sector issue, my OEMiROT_Boot code already uncommented the line of the flash_layout.h file, I will check my OEMiROT_Boot code, maybe my modification in OEMiROT_Boot cause the STM32CubeProgrammer cannot read the flash size.

Regards,
Snaku

[Snaku]

Hi Aziz,
I start a new OEMiROT_Boot project from STM32Cube_FW_H5_V1.6.0, and I only uncommented the DEVICE_1M_FLASH_ENABLE definition.

1. I find that if the CPU stay in OEMiROT_Boot, then STM32_Programmer_CLI.exe cannot read the flash size even using hot-plug mode.
- this is the UART log shows OEMiROT_Boot stop here due to hide protection setting is not match.

- at this moment, STM32_Programmer_CLI hot-plug mode cannot read the flash size

2. If the CPU leave OEMiROT_Boot and jump to the bootloader in system memory, then STM32_Programmer_CLI.exe can read flash size, and sector [76 91] can be erase with hot-plug mode.
- after I change the hide protection setting in the option bytes let it match with OEMiROT_Boot code, the CPU will jump to the bootloader in the system memory.

- at this moment, STM32_Programmer_CLI hot-plug mode can read the flash size

So, my test results indicate that STM32_Programmer_CLI may still be unable to read the size of flash memory while OEMiROT_Boot is running.

Regards,
Snaku