Skip to main content
B
bns
Associate II
May 15, 2026
Solved

STM32WL SBSFU fails to write header during SFU_IMG_Validation

  • May 15, 2026
  • 1 reply
  • 79 views

Hi folks,

I am working on integrating SBSFU with my application. I've got one internal slot and one external slot. The update file is received fine, the header is written to the swap area to be installed after the reset. The reset occurs, SBSFU finds the header, decrypts the update file and swaps the file.

However.. it gets stuck at SFU_IMG_Validation, writing the `pTestHeader` to `SLOT_ACTIVE_1_HEADER` address and triggers `SFU_IMG_FLASH_WRITE_FAILED` in `sfu_fwimg_common.c`.

I assume that this part of flash is write protected? But I cannot find any mention of this in the SBSFU guides or files. It would be great if someone can help me figure out how to finalize this.

09:35:13.652 > = [SBOOT] RuntimeProtections: 0
09:35:46.801 > 74640 bytes of ciphertext decrypted.
09:35:54.301 > Image preparation done.
09:35:54.301 > Swapping the firmware images..................................
09:35:54.397 > Address = 0801D000, FwSize = 74640, len = 192 <-- added debug info
09:35:54.397 > Abnormal error 2 at line 962 in C:/Users/steve/STM32Cube/Repository/STM32Cube_FW_WL_V1.5.0/Projects/STM32WLE5JC/Applications/LoRaWAN_FUOTA_ExtFlash/1_Image_BFU/BFU/App/sfu_fwimg_common.c - BLOCK

 

Best answer by bns

Well... had been working on this for a full day yesterday before deciding to open a topic. But in the end I now did resolve it only an hour after opening up the topic after all.. Meh.

Looking at the logs I noticed that the firmware swapping was way too fast for my flash chip (see the log timestamps). Turns out that the external flash erase wasn't setting bytes to 0xFF but to 0x00 which in turn meant that the trailer bytes looked like "SWAPPED" instead of "NOT_SWAPPED" which resulted in the firmware images not getting swapped.

I'm not sure why it resulted in such a hard fault during the header write, but with the erase now setting bytes to 0xFF it succeeds :) 

Solved...

1 reply

B
bnsAuthorAnswer
Associate II
May 15, 2026

Well... had been working on this for a full day yesterday before deciding to open a topic. But in the end I now did resolve it only an hour after opening up the topic after all.. Meh.

Looking at the logs I noticed that the firmware swapping was way too fast for my flash chip (see the log timestamps). Turns out that the external flash erase wasn't setting bytes to 0xFF but to 0x00 which in turn meant that the trailer bytes looked like "SWAPPED" instead of "NOT_SWAPPED" which resulted in the firmware images not getting swapped.

I'm not sure why it resulted in such a hard fault during the header write, but with the erase now setting bytes to 0xFF it succeeds :) 

Solved...

Terms & ConditionsAccessibility statement