How to properly regenerate Keys for SM project

[Thatseasy]

When creating a new project (for STM32H573) using CubeMX, it generates defaults keys under ROT_Provisioning\SM\Keys:

06/19/2025 03:20 PM 232 ITS_key1.pem
02/17/2026 09:34 PM 16 SFI_Encryption_Key.bin
02/17/2026 09:34 PM 12 SFI_Encryption_Nonce.bin
02/18/2026 12:06 PM 136 SFI_Global_License.bin
06/19/2025 03:20 PM 246 SM_Authentication.pem
06/19/2025 03:20 PM 182 SM_Authentication_pub.pem
06/19/2025 03:20 PM 246 SM_Encryption.pem
06/19/2025 03:20 PM 182 SM_Encryption_pub.pem

Using TPC, those keys (including the SFI_global_license) can be regenerated, but when provisioning, got the following error:
2026-02-18 12:19:23,911 - DEBUG - Processing license...
2026-02-18 12:19:24,072 - DEBUG - Error: Execution of RSS CMD failed, returned value = 0xF6F6F6F6
2026-02-18 12:19:24,072 - DEBUG - Error: Failed to Process License!
2026-02-18 12:19:24,073 - DEBUG - Error: .....ROT_Provisioning\SM\Binary\SecureManagerPackage.sfi SFI file Install Operation Failure! Please, try again.
2026-02-18 12:19:24,073 - DEBUG -
2026-02-18 12:19:24,082 - ERROR - Command '"C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe" -c port=SWD ap=1 mode=HotPlug -vb 1 -sfi C:\projects\TGR_V1\GSV1_SM\ROT_Provisioning\SM\Binary\SecureManagerPackage.sfi ....ROT_Provisioning\SM\Keys\SFI_Global_License.bin -rsse ....ROT_Provisioning\SM\Binary\enc_signed_RSSe_SFI_STM32H5_2M_v2.0.1.0.bin ' returned non-zero exit status 1

My questions, after re--generating the keys, besides running the provisioning.py to re-create the sfi file, what else should be done before flashing the device (assuming it is already in OPEN state)?

Thanks!

[Jocelyn RICARD]

Hello @Thatseasy 

you should generate the new Global license as suggested by the provisioning.py script:

2026-02-24 11:05:56,516 - INFO - * Choice of the SFI license
2026-02-24 11:05:56,516 - INFO - In C:\ST\X-CUBE-SEC-M-H5_V2.1.0\Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\sm.ini, You have chosen (global) for license_type.
2026-02-24 11:05:56,516 - INFO - Is this the desired configuration for your SFI?
2026-02-24 11:05:56,517 - INFO - [ '1' for Yes | '2' for No]:
1
2026-02-24 11:06:01,593 - INFO - * SFI with global license configuration:
2026-02-24 11:06:01,594 - INFO - From TrustedPackageCreator (License Gen tab in Security panel)
2026-02-24 11:06:01,594 - INFO - Select SFIG in the "License Type" list
2026-02-24 11:06:01,595 - INFO - Open encryption key file (\ROT_Provisioning\SM\Keys\SFI_Encryption_Key.bin)
2026-02-24 11:06:01,595 - INFO - and nonce file (\ROT_Provisioning\SM\Keys\SFI_Encryption_Nonce.bin),
2026-02-24 11:06:01,595 - INFO - then regenerate them (if/as needed) with same name.
2026-02-24 11:06:01,595 - INFO - Select Output license file (\ROT_Provisioning\SM\Keys\SFI_Global_License.bin)
2026-02-24 11:06:01,596 - INFO - then Generate License (if/as needed) with same name.

This operation should be done manually using the TPC.

Best regards

Jocelyn

[Thatseasy]

Thank you @Jocelyn RICARD.

The SFI_Global_License.bin was regenerated using the new SFI_Encryption_Key.bin and SFI_Encryption_Nonce.bin.

The log files from sfi-gen and sfi-flash are attached.

 

BTW, I tried RSSe_SFI_H56x_H573_v3.1.0.bin and RSSe_SFI_H56x_H573_v3.0.0.bin as well, they do not work either.

 

 

 

 

 

[Jocelyn RICARD]

Hello @Thatseasy;,

It seems you are using an old version of secure manager. Also, you seem to use CubeMX to generate non secure application using Secure Manager bootpath. This feature is no more supported in CubeMX.

I wrote a wiki page to still be able to use CubeMX to generate the non secure application here.

Maybe would be worth upgrading your environment to fit with latest versions ?

If not possible, I would try provisioning your target with default configuration to check if it still working.

Best regards

Jocelyn

[Thatseasy]

Thank you @Jocelyn RICARD for sharing the upgrade guide, it is very helpful! I followed it to manually upgrade my environment to SM 2.1.0 (from 1.2.0, did not run the new CubeMX). I think the only problem now is that the BOOT_USE is not changed to C3 after sfi-flash, no matter how the Option_Bytes sets it.  

What might be still missing?  

The new sfi-gen and sfi-flash log files are attached. 

BTW: SRAM3_ECC is disabled because the new RSSe requires it.

 

Thanks!

 

It looks like the 0xF6F6F6F6 error is almost always related to a mismatch between regenerated keys and previously generated artifacts.

After regenerating SM keys with TPC, you need to fully reset the provisioning artifacts — not just re-run provisioning.py.

Here’s what I usually recommend:

1. Delete all previously generated files:

   • SecureManagerPackage.sfi

   • enc_signed_RSSe_*.bin

   • SFI_Global_License.bin

   • Any previously signed binaries

2. Regenerate in strict order:

   • Generate new keys via TPC

   • Regenerate SFI_Global_License.bin

   • Re-run provisioning.py to rebuild the full package

3. Ensure there are no leftover default CubeMX keys still sitting in the Keys directory.

Even if the device is still in OPEN state, it’s worth:

• Doing a full regression (if allowed)

• Power-cycling before reattempting provisioning

That RSS failure usually means the license and SFI were not built from the exact same key set.

I recently documented some structured troubleshooting approaches for technical deployment issues on our site (https://alightmotionapp.co/) different domain, but the validation logic principles are surprisingly similar when dealing with signed artifacts and deployment chains.

Hope this helps.

[Thatseasy]

Thank you @unknown, I agree that enc_signed_RSSe_SFI_STM32H5_2M_v2.0.1.0.bin might be the problem, but I do not know how to re-generate it as it was from the ST RSSe package.  How did you regenerate it after your delete enc_signed_RSSe_*.bin?

[Jocelyn RICARD]

Hello @Thatseasy 

BOOT_UBE is not set to 0xC3 anymore with this version of secure manager.

Reason is that STiROT is not more used, it was replaced by SMiROT in user flash. You can check this in UM3254.

SRAM3_ECC check is necessary during the provisioning but can be changed in final option bytes settings.

Best regards

Jocelyn

[Thatseasy]

Thank you @Jocelyn RICARD, in my project, I only have one NS application, how to configure the SMuRoT to jump to the NS application located at 0x0805E000?  Or Do I need to add a secure application to my project, who will be responsible to launch the NS application?  Will that then become OEMuRoT? Sorry I might be confused by the terms.

Here is the option_bytes I am using, do you see any problems?
OPTSR_PRG,0x30F0C6F8
OPTSR2_PRG,0xB4000034
NSBOOTR_PRG,0x0805E0C3
SECBOOTR_PRG,0x0C0000B4
SECWM1R_PRG,0x00010000
SECWM2R_PRG,0x00010000
WRP1R_PRG,0xFFFFFFFF
WRP2R_PRG,0xFFFFFFFF
EDATA1R_PRG,0x00000000
EDATA2R_PRG,0x00000000
HDP1R_PRG,0x0000007F
HDP2R_PRG,0x0000007F

[Jocelyn RICARD]

Hello @Thatseasy 

You don't have any flexibility in the non secure application location.

One you have setup C:\ST\X-CUBE-SEC-M-H5_V2.1.0\Projects\STM32H573I-DK\ROT_Provisioning\SM\Config\Profile_Large\SM_Config_General_Large.xml all mapping is fixed.

Your non secure application linker file will be updated by prebuild.

In your linker file you should have something like:

MEMORY
{
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 256K - RAM_S_NS_IF_SIZE
 RAM_2 (xrw) : ORIGIN = RAM_S_END + 1, LENGTH = 0x200A0000 - (RAM_S_END + 1)
 FLASH (rx) : ORIGIN = 0x08000000 + CODE_OFFSET + IMAGE_HEADER_SIZE, LENGTH = (CODE_SIZE - IMAGE_HEADER_SIZE)
 FLASH_RESERVED (rx) : ORIGIN = 0x08000000 + RESERVED_AREA_OFFSET, LENGTH = RESERVED_AREA_SIZE
}

 

With Secure Manager solution you should only have to care about your non secure application.

Once you have launched provisioning.py --sfi-gen --sfi-flash -a :

Plaform first boots on SMiROT.

SMiROT checks authenticity of SMuROT and jump to this 2nd stage secure boot.

SMuROT checks mainly authenticity of : Secure Manager core that is the secure application and your non secure application.

By default you are in development mode. For secure manager it means product state is TZ-CLOSED.

In this state only non secure part of the flash are accessible to the debugger.

The option bytes you share show that secure manager is not installed.

Here is an option bytes setting you have on an installed secure manager:

OPTSR_PRG,0x2D30C6F8
OPTSR2_PRG,0x2D30C6F8
NSBOOTR_PRG,0x080000C3
SECBOOTR_PRG,0x00000000
SECWM1R_CUR,0x002E0000
SECWM2R_CUR,0x00730065
WRP1R_PRG,0xFFFFFFFF
WRP2R_PRG,0xE7FFFFFF
EDATA1R_PRG,0x00000000
EDATA2R_PRG,0x00000000
HDP1R_PRG,0x0000007F
HDP2R_CUR,0x006C006D

Best regards

Jocelyn