SBSFU YModem Issue: Signature Verification Failure on Second Update (STM32WB55VG)

[GuilhemG]

Hello ST Community,

I'm encountering a persistent issue with the Secure Boot and Secure Firmware Update (SBSFU) implementation on the STM32WB55VGQ6. I am using a setup largely based on the official SBSFU examples, but modified for my specific application.

The core problem is that the first successful firmware update via YModem works perfectly (signature verification and decryption pass), but all subsequent updates fail authentication, even with the same, correctly signed and encrypted .sfb file.

Target and Configuration Details

• Target MCU: STM32WB55VGQ6

• Bootloader: SBSFU (Close to standard example, running on Cortex-M4 only).

• Update Method: YModem over UART @ 115200 baud.

• Firmware Image: Custom .sfb file, encrypted and signed using the standard provided tools (prepareimage, etc.) with self-generated keys.

• Initial Programming:

  1. UserKey (for AES_CBC) pushed via CubeProgrammer.

  2. SECoreBin + SBSFU loaded at 0x08000000.

• CM0+ Core: Not used at all (disabled for historical reasons, as wireless connectivity is handled by a separate STM32WB55 dongle communicating over UART).

• Flash Usage Note: Since the CM0+ is disabled, the M4 is allocated more Flash space, extending beyond the typical 512KB partition (using up to $\approx 550\text{KB}$ of the available 1MB Flash).

• Emulated EEPROM: Using the Emulated EEPROM feature, which is regrettably necessary as the MCU lacks a dedicated EEPROM.

Error Description

The first time I transfer the .sfb file, the update is successful. When attempting a second update, the YModem transfer completes, but the signature verification consistently fails, leading to the following log output from the SBSFU:

= [SBOOT] STATE: CHECK USER FW STATUS
          A FW is detected in the slot SLOT_ACTIVE_1
= [SBOOT] STATE: VERIFY USER FW SIGNATURE
= [SBOOT] RuntimeProtections: 0
=         SFU_IMG_VerifyActiveImg failure with se_status=1338049!
          Firmware signature verification failure in slot SLOT_ACTIVE_1
          Erasing slot SLOT_ACTIVE_1
= [SBOOT] STATE: HANDLE CRITICAL FAILURE
= [SBOOT] STATE: REBOOT STATE MACHINE

The error code $\mathbf{0x1338049}$ is consistently observed on the failing signature verification.

Linker Script Information

I suspect this might be related to how the slots or the Emulated EEPROM state is handled or mapped, especially given the repeated failure after the first success. Below are the relevant memory definitions from my linker scripts:

mapping_sbsfu.ld (SBSFU and Loader Regions)

Extrait de code

/* ... (omitting SE definitions for brevity) ... */

/* SBSFU Code region */
__ICFEDIT_SB_region_ROM_start__            = __ICFEDIT_SE_IF_region_ROM_end__ + 0x1;
__ICFEDIT_SB_region_ROM_end__              = 0x0800FFFF;

/* LOADER code region : 20 kBytes area aligned on 4kBytes address, MPU protection constraints */
__ICFEDIT_LOADER_region_ROM_start__        = __ICFEDIT_SB_region_ROM_end__ + 0x1;
__ICFEDIT_LOADER_region_ROM_end__          = 0x08014FFF;

mapping_fwimg.ld (Firmware Slot)

Extrait de code

__ICFEDIT_SLOT_Active_1_header__ = 0x08015000;
__ICFEDIT_SLOT_Active_1_start__  = 0x08016000;
__ICFEDIT_SLOT_Active_1_end__    = 0x080ABFFF; /* ~600KB allocated for user firmware */

STM32WB55VGQX_FLASH.ld (Emulated EEPROM Location)

Extrait de code

MEMORY
{
    /* ... (other memory definitions) ... */
    EEPROM (rwx)      : ORIGIN = 0x080AD000, LENGTH = 32K
}

Question

The failure on the second verification suggests that the state of the firmware in the slot or the metadata stored in the Emulated EEPROM is being corrupted or incorrectly maintained after the first successful boot.

1. What does the error code $\mathbf{0x1338049}$ specifically indicate in the context of SFU_IMG_VerifyActiveImg failure?

2. Could the use of Emulated EEPROM be the source of this persistent state failure? Are there known issues with SBSFU and emulated EEPROM on the STM32WB55?

3. Are there any concerns with the Flash memory mapping, especially the EEPROM starting at $\mathbf{0x080AD000}$?

Any guidance on troubleshooting the post-update state management, particularly regarding the Emulated EEPROM persistence, would be greatly appreciated.

Thank you for your help!