cancel
Showing results for 
Search instead for 
Did you mean: 

SBSFU: Active slot ends up empty after swapping of firmware images

mahse
Associate

Hello,

I have a setup with two partitions (active + download) and a user application that also acts as a firmware loader.

At the moment, the loader/user application downloads the new firmware to the download slot successfully and after reset the new firmware is identified and the SBSFU initiates the installation of the new firmware. The decryption succeeds and I've verified that the correct image is obtained after decryption. Hence, the installation seems to work up until the swapping phase. During swapping, no firmware data seems to be written to the active slot. After the swapping operation is completed, no firmware is present in the active slot at all. Hence, the swap seems to act more or less act as an erase operation on the active partition. Still, the SBSFU seems to consider the installation successful and complete (no error codes are returned if I check during debug). But after the subsequent reset, it starts to erase the content in the active slot, announcing: "Slot SLOT_ACTIVE_1 not empty: erasing ...".

Do anyone have any idea what could be the problem?
I have verified the flash routines, and they seem to work for all tests I've made.

The SBSFU version is 2.6.2, executing on a STM32F750.

3 REPLIES 3
Jocelyn RICARD
ST Employee

Hello @mahse ,

The STM32F750 has 64 kbytes of flash memory. So, you must have changed things to use external flash I suppose.

So, it looks like something goes wrong with flash driver.

The flash layout configuration should be aligned on a multiple of flash sectors size so that you can perform permutation between a sector from active slot, a sector from download slot and a scratch sector.

Best regards

Jocelyn

Hello Jocelyn, thank you for your response!

That's correct, an external flash is used in this case. It is setup with the active slot and download slot, 8 MB each, together with a swap slot (256 KB).
The swap is at the start of the flash 0x0 (relative address).
The active slot starts at 0x00040000 (relative address).
The download slot starts at 0x00840000 (relative address).

The test application is approximately 1 MB in size.

During the swap operation, I've noticed that no writes are requested by the SBSFU swap routine for addresses at the beginning of the active partition (the addresses that should contain the firmware, i.e. 0x00040400). Writes are only requested for addresses at the other end of the active slot.

Do you think this is due to the flash layout and/or flash layout misconfiguration?

Hello @mahse,

the swap starts from the end of the slots. This explains why you see changes at the end.

You can use debugger and go through SwapFirmwareImages() function (which is a bit too complex IMHO) and understand what happens in your case.

Best regards

Jocelyn