CubeProgrammer can't program STM32H563 high-cycle flash if TrustZone is enabled

[JesperEC]

If TrustZone is enabled on a device, I cannot use STM32_Programmer_CLI.exe -d to program high-cycle count flash.

If TrustZone is disabled, it works.

Based on STM32_Programmer_CLI -w16 not working in high-cycl... - STMicroelectronics Community I have reason to believe that it does work with TrustZone on if you have working secure boot code that puts the device in a higher HDPL before programming is attempted. But I have not tested this myself. And if there needs to be some data in high-cycle count for the boot loader to start, you are stuck. In theory you could catch the double ECC-error and program the sectors with default values from the application, but that is a hassle.

I'd love to get some feedback from ST on if I am doing something wrong here or this is a bug in either the programmer or the MCU.

STLINK-V3SET FW V3.J16.M8.B5.S1
STM32H563 Rev X
Bootloader Version 0xE4
STM32CubeProgrammer 2.19.0

Steps to reproduce (last command is failing)

EDATA.bin is nothing special - just 16 zero bytes.

"C:/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe" --connect port=SWD mode=UR -ob displ

"C:/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe" --connect port=SWD mode=UR -ob "EDATA1_EN=1" "EDATA1_STRT=7"

OPTION BYTE PROGRAMMING VERIFICATION:

Option Bytes successfully programmed

Time elapsed during option Bytes configuration: 00:00:01.242

"C:/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe" --connect port=SWD mode=UR -d EDATA.bin 0x09000000

Opening and parsing file: EDATA.bin

Memory Programming ...
File : EDATA.bin
Size : 16.00 B
Address : 0x09000000

Erasing memory corresponding to sector 0:
Download in Progress:
▒▒▒▒▒▒ 12%▒▒▒▒▒▒ 25%▒▒▒▒▒▒ 37%▒▒▒▒▒▒▒ 50%▒▒▒▒▒▒ 62%▒▒▒▒▒▒ 75%▒▒▒▒▒▒ 87%▒▒▒▒▒▒▒ 100%

File download complete

"C:/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe" --connect port=SWD mode=UR -e all

Mass erase ...

Mass erase successfully achieved

"C:/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe" --connect port=SWD mode=UR -ob TZEN=0xB4 -hardRst

OPTION BYTE PROGRAMMING VERIFICATION:

Option Bytes successfully programmed

Time elapsed during option Bytes configuration: 00:00:02.413

Hard reset is performed

"C:/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI.exe" --connect port=SWD mode=UR -d EDATA.bin 0x09000000

Memory Programming ...
File : EDATA.bin
Size : 16.00 B
Address : 0x09000000

Erasing memory corresponding to sector 0:
Download in Progress:
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒Error: Fail to write buffer in flash
Error: failed to erase memory

Error: failed to download Sector[0]
Error: failed to download the File
0%

Output of -ob displ before enabling EDATA and (later) TrustZone

OPTION BYTES BANK: 0

Product state:

PRODUCT_STATE: 0xED (Open)

BOR Level:

BOR_LEV : 0x0 (BOR Level 1, the threshold level is low (around 2.1 V))
BORH_EN : 0x0 (0x0)

User Configuration:

IO_VDD_HSLV : 0x0 (0x0)
IO_VDDIO2_HSLV: 0x0 (0x0)
IWDG_STOP : 0x1 (0x1)
IWDG_STDBY : 0x1 (0x1)
BOOT_UBE : 0xB4 (OEM-iRoT (user flash) selected)
SWAP_BANK : 0x0 (0x0)
IWDG_SW : 0x1 (0x1)
NRST_STOP : 0x1 (0x1)
NRST_STDBY : 0x1 (0x1)
OPTION BYTES BANK: 1

User Configuration 2:

TZEN : 0xC3 (Trust zone disabled)
SRAM2_ECC : 0x1 (SRAM2 ECC check disabled)
SRAM3_ECC : 0x1 (SRAM3 ECC check disabled)
BKPRAM_ECC : 0x1 (BKPRAM ECC check disabled)
SRAM2_RST : 0x1 (SRAM2 not erased when a system reset occurs)
SRAM1_3_RST : 0x1 (SRAM1 and SRAM3 not erased when a system reset occurs)
OPTION BYTES BANK: 2

Boot Configuration:

NSBOOTADD : 0x80000 (0x8000000)
NSBOOT_LOCK : 0xC3 (The SWAP_BANK and NSBOOTADD can still be modified following their individual rules.)
SECBOOT_LOCK : 0x0 (Unknown Value)
SECBOOTADD : 0x0 (0x0)
OPTION BYTES BANK: 3

Bank1 - Flash watermark area definition:

SECWM1_STRT : 0x7F (0x80FE000)
SECWM1_END : 0x0 (0x8000000)

Write sector group protection 1:

WRPSGn1 : 0xFFFFFFFF (0x8000000)
OPTION BYTES BANK: 4

Bank2 - Flash watermark area definition:

SECWM2_STRT : 0x7F (0x81FE000)
SECWM2_END : 0x0 (0x8100000)

Write sector group protection 2:

WRPSGn2 : 0xFFFFFFFF (0x8000000)
OPTION BYTES BANK: 5

OTP write protection:

LOCKBL : 0x0 (0x0)
OPTION BYTES BANK: 6

Flash data bank 1 sectors:

EDATA1_EN : 0x0 (No Flash high-cycle data area)
EDATA1_STRT : 0x0 (0x0)
OPTION BYTES BANK: 7

Flash data bank 2 sectors:

EDATA2_EN : 0x0 (No Flash high-cycle data area)
EDATA2_STRT : 0x0 (0x0)
OPTION BYTES BANK: 8

Flash HDP bank 1:

HDP1_STRT : 0x1 (0x2000)
HDP1_END : 0x0 (0x0)
OPTION BYTES BANK: 9

Flash HDP bank 2:

HDP2_STRT : 0x1 (0x2000)
HDP2_END : 0x0 (0x0)

    Best regards, Jesper

(edited 2025-06-02: Removed label "Bug-report")

[Maryem]

Hello @JesperEC ,

You've only provided the option byte configuration before setting the EDATA and enabling TrustZone.

Could you please confirm from your side that after enabling TrustZone, the secure watermark area is either disabled or configured such that it does not overlap with the flash high-cycle data area ?

Maryem.

[JesperEC]

Hi Maryem,

Thanks, that was the question I should have asked myself.

What is causing this is that when TZEN is set to 0xB4 from 0xC3, the SECWM option bytes are reset to make the entire flash in both banks secure watermarked and sectors secure watermarked cannot be used as high-cycle data sectors. So after setting TZEN, you need to set the SECWM OBs correctly to shrink the secure watermarked area before you try to write high-cycle data.

This is the specified behaviour according to RM0481 rev 3 p.276 and section 7.6.1 and 7.6.9 so I can't claim that this is a bug report.

Let me rephrased this as a couple of improvement suggestions:

1. Although there is no OPTCHANGEERR raised when setting EDATA[1, 2]_STRT and SECWM[1, 2] to conflict, I believe that STM32CubeProgrammer downloads all the option bytes after setting to confirm that they were set as expected.

Maybe the programmer could then check if the relevant OBs are conflicting and issue a warning on the console/GUI that the high-cycle data flash won't work as expected?

2. Some high-cycle data handling could be added to the example in STM32Cube_FW_H5:Projects/NUCLEO-*/Applications/ROT/OEMiROT_Appli_TrustZone and the provisioning script ob_flash_programming.[bat|sh] could be extended to show flashing of some EDATA (which the example application could read to show that it works) and have a comment why it is important to do it after action="Configure Secure Water Mark". This would help developers to not fall in the trap if they have not read all the fine print of the reference manual.

   Best regards, Jesper