Question
STM32H573 SFI (without Secure Manager) fails at Area 2 with error 0xFFEB0FB3 – "Failed to Process Area Number 70"
Environment
- MCU: STM32H573 (custom board)
- STM32CubeProgrammer & STM32 Trusted Package Creator: v2.23.0 (same version)
- X-CUBE-RSSe: installed (RSSe SFI binary v3.1.0, RSS v2.2.0)
- License: ST HSM (hsm=1, slot=1)
- Boot: custom OEM bootloader (OEM-iRoT), not STiRoT / not mcuboot
- Connection: Hotplug
What I'm doing I'm evaluating SFI without Secure Manager, installing my own firmware into internal secure flash. TrustZone is enabled (TZEN=0xB4), and my final option bytes (CSV) set:
- BOOT_UBE = 0xB4 (OEM-iRoT)
- SECBOOTADD = 0xC0000 (0x0C000000)
- SECWM1 = 0x00–0x7F, SECWM2 = 0x00–0x7F (all secure)
Memory layout (secure alias 0x0C000000):
| File | Address | Size |
|---|---|---|
| 1.bin | 0x0C000000 | 22.2 KB |
| 2.bin | 0x0C008000 | ~813 KB total |
| 3.bin | 0x0C0F7FA0 | 80 B |
| 4.bin | 0x0C0F8000 | 32 B |
| 5.bin | 0x0C1F8000 | 5.6 KB |
Behavior The SFI process starts correctly:
- License processed OK
- Image header processed OK
- Area 1 (type H) processed OK
- Fails at Area 2 with:
Error: Execution of RSS CMD failed, returned value = 0xFFEB0FB3
Error: Failed to Process Area Number 70 of type (type field is blank)
After failure, PRODUCT_STATE stays at 0x17 (Provisioning), and I can only recover debug access after a full power cycle.
What I have already checked / ruled out
- Encryption Key and Nonce are identical between the HSM programming and the SFI image generation.
- Firmware binaries are rebuilt for the secure address (0x0C000000), format is .bin with addresses assigned in TPC.
- CSV option bytes are correct (verified in the intermediate log; BOOT_UBE=0xB4 and SECBOOTADD=0xC0000 match).
- No address overlap (total image is only ~813 KB).
- I regenerate a fresh .sfi (new filename) every time.
Questions
- What does the return value 0xFFEB0FB3 indicate, and why does the failure report "Area Number 70 of type (blank)" when only ~13 areas exist? This looks like a corrupted/unexpected area descriptor.
- For a custom OEM-iRoT (no STiRoT, no Secure Manager), is there any additional requirement for the first firmware area at 0x0C000000 (e.g. alignment, reserved header, OBK provisioning) that I might be missing?
- Are there known incompatibilities between TPC-generated SFI images (Protocol version 2) and the RSSe SFI binary version that could cause this area-parsing failure?
Any guidance on how to interpret this error code and where to look next would be greatly appreciated. Thank you.
