Unable to flash OEMiRoT application using STLink-V2

[giubacchio]

Hi,

I'm developing a secure boot application for STM32H563ZI microcontroller. I started with a very simple application following ST template code and tutorials like this one: https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STM32CubeMX_OEMiRoT_Boot_path_on_STM32H563  

Everything runs as expected when I try to run my application using the NUCLEO-H5 board. However, this is not true when I do the same provisioning process in my H5 custom board. The only difference I can see between the two tests is that in the custom board I'm using the STLink-V2 programmer, while the Nucleo is programmed by the embedded STLINK-V3EC.

Here are some additional points:

1) in both cases the provisioning script reaches the end, saying "The board is correctly configured".

2) in the custom board, I see the flash full of zeros after provisioning; I checked it with stm32CubeProgrammer

3) I have no problems in flashing firmware through stm32CubeProgrammer or stm32CubeIde in my custom board


Am I missing something? I tried to modify stm32programmercli settings used by the provisioning script without success. 
Thank you,
Giulio

[Jocelyn RICARD]

Hello @giubacchio ,

There is no limitation related to STLinkV2 as far as I know.

One possible issue is that you didn't connect the reset pin to STLinkV2

Best regards

Jocelyn

[giubacchio]

Hello @Jocelyn RICARD ,

thank you for your answer. Reset pin is connected, and the debug authentication process works as expected. I can correctly check the provisioning state by the "Discover" button of STM32CubeProgrammer, as well as enabling the debug and reading the flash memory by authenticating with key and certificate.

I can try to prorgram the Nucleo board with the STLink-V2 programmer using the MIPI20 interface and check if the behavior is the same, but I don't have the female 1.27mm connector.

If you have any other ideas please let me know ;)

Thank you,

Giulio

[Jocelyn RICARD]

Hello @giubacchio ,

OK thank you for the details.

 

After provisioning your custom board, can you check what you see with STM32CubeIDE debugger, removing the download part ?

Is it also only zeros ?

Best regards

Jocelyn

[giubacchio]

Hello @Jocelyn RICARD ,

I tried to read the memory using STM32CubeIDE as you suggested: using the Memory view I read only question marks as in the image shown below; as expected, the execution doesn't stop in any of the breakpoints.
The same process with the Nucleo board leads me to a correct read in the Memory view and breakpoints work as expected.

Thank you,
Giulio

 

[Jocelyn RICARD]

Hello @giubacchio,

This is strange indeed.

Could you please compare option bytes using -ob displ of STM32CubeProgramer CLI ?

This may give some clue

Best regards

Jocelyn

[giubacchio]

Hi @Jocelyn RICARD, the command:

STM32_Programmer_CLI -c port=SWD mode=Hotplug -ob displ

gives the same option bytes configuration in both boards. Apparently, the only differences between the two output are the ST-Link info and that in the Nucleo board the command fails to read the flash size. Attached you can find both outputs.

Thank you,
Giulio

[Jocelyn RICARD]

Hello @giubacchio ,

in option bytes you provided the targets are in PROVISIONED state.

 PRODUCT_STATE: 0x2E (iRoT-provisioned, Debug partially opened (only non-secure)) 

In this state you cannot access to the secure part of the flash whatever the STLink you use.

So, I guess that with Nucleo, you reopened the debug.

Did you try provisioning in OPEN state using BOOT0 pin for provisioning OBKeys ?

On my side, I connected a STLinkV2 to the H563 Nucleo (following board's documentation) and got correct behaviour: provisioning with final state OPEN : OK, provisioning with final state PROVISIONED : OK but only access to non secure. After opening the debug, I could connect with debugger (In software system reset) and see the secure part of the code.

One last thing in your trace that is not normal is the SFSP value:

SFSP Version: v45.48.46

I don't catch how this is even possible. This could mean that system flash is corrupted.

Best regards

Jocelyn

[giubacchio]

Hello @Jocelyn RICARD ,

I confirm you that the two boards were in PROVISIONED state and that I reopened the debug by authenticating with key and certificate before reading the secure zone memory.
I also tried to provision both boards in OPEN state getting the same results: that is, the H5 in the NUCLEO shows a memory mapping as expected while my custom board not. 

However, I have found something with a more careful analysis of the complete flash content: the flash of the H5 in the custom board does not seem totally empty: it shows some patterns but they seem shifted respect to the NUCLEO case. For example:

• CUSTOM board memory addresses from 0xC0BE000 to 0xC0BE020 are set with the same values of those from 0xC018000 to 0xC018020 of the NUCLEO board
• CUSTOM board memory addresses from 0xC0BE400 to 0xC0C3130 contains something, but it does not match with the secure code contained from address 0xC018400 to 0xC019C90 of the Nucleo board.
• there are some others memory regions with similar patterns.

While the content of the memory of the Nucleo H5 matches the expectation, that of the custom board does not, because the code seems to be placed at the secondary slot of the secure area. Indeed, the flash layout header of the application says:

#define FLASH_AREA_0_OFFSET 0x18000 /* Secure app image primary slot offset */

#define FLASH_AREA_0_SIZE 0x6000 /* Secure app image primary slot size */

#define FLASH_AREA_1_OFFSET 0x1E000 /* Non-secure app image primary slot offset */

#define FLASH_AREA_1_SIZE 0xA0000 /* Non-secure app image primary slot size */

#define FLASH_AREA_2_OFFSET 0xBE000 /* Secure app image secondary slot */

#define FLASH_AREA_2_SIZE 0x6000 /* Secure app image secondary slot size */

#define FLASH_AREA_3_OFFSET 0xC4000 /* Non-secure app image secondary slot offset */

#define FLASH_AREA_3_SIZE 0xA0000 /* Non-secure app image secondary slot size */

. 

At this point, it seems that something wrong is happening in the memory management, but I can't figure why. Do you have any ideas? I have attached the flash memory contents of the two boards.

Thank you,
Giulio

 

[Jocelyn RICARD]

Hello @giubacchio,

You are really having a STM32H563ZI ? Is it confirmed by the marking ?

Also which STM32CubeProgrammer version are you using?

Best regards

Jocelyn

 

[giubacchio]

Hello @Jocelyn RICARD,

I think both micros can be classified as STM32H563ZI. 
The markings of the H5 in the Nucleo says:
STM32H563ZIT6U - AA065VQ - TMN AA 430

The markings of the H5 in the custom board says:

STM32H563ZIT6 - AA102VQ - TMN AA 434

 

The STMCubeProgrammer version is the v2.21.0. I'm running everything under Linux Ubuntu 22.04.

Thank you,
Giulio

[Jocelyn RICARD]

Hello @giubacchio ,

It looks like you have a chip having flash issues, this is not common.

You can possibly make more tests to confirm the chip is not fully functional.

Maybe, switch back TZ to 0xC3 and fill the flash with anything using verification.

Check on another board...

Best regards

Jocelyn

[giubacchio]

Hello @Jocelyn RICARD,

I arranged to get another custom board: in this one I have no problems even when using the OEMiROT bootloader.

I'm not sure that the issue is in the flash, since the same application without OEMiROT works smooth in the suspected faulty H5 chip. I’m a bit disappointed, but I’ll get over it.

Thank you for your time,
Giulio