SBSFU: The binary image to be installed overlap with the trailer area

[sute]

Hello,

We have a software project with STM32H7B3 MCU using SBSFU for bootloader and installing updates. We are using one download slot and one active slot and have been very tight on flash size and have often had to reduce binary size. Normally, this is not a problem since we get a compilation error from the linker script when binary size becomes too big. In the linker script we have:

ISR_VECTOR_START = __ICFEDIT_SLOT_Active_1_start__ + 0x400; /* Cortex-M7: align the init vectors on 0x400 */
APP_ROM_START = ISR_VECTOR_START + VECTOR_SIZE;
APP_ROM_END = __ICFEDIT_SLOT_Active_1_end__;
APP_ROM_LENGTH = APP_ROM_END - APP_ROM_START + 1;
 
/* Specify the memory areas */
MEMORY
{
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM (xrw) : ORIGIN = 0x24000000, LENGTH = 1024K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
ISR_VECTOR (Rw) : ORIGIN = ISR_VECTOR_START, LENGTH = VECTOR_SIZE
APP_ROM (rx) : ORIGIN = APP_ROM_START, LENGTH = APP_ROM_LENGTH
}

This makes APP_ROM_END equal to 0x081FFFFF and compilation should not be possible if binary grows too much. However, we have now encountered a situation where the software compiled successfully and we got a .sfb update image, which was downloaded to flash. Once, SBSFU executed, it gave the following warning:

> = [FWIMG] The binary image to be installed overlap with the trailer area!

Upon further research, I found that there is a trailer area which starts at address 0x81FF980. This is not mentioned in any documentation I could find. Could someone explain what is the trailer area and should I change APP_ROM_END to 0x81FF97F so that there is no overlap? This seems weird since none of the SBSFU example projects seem to take the trailer area into consideration.

[Fred]

Hi @MS_it.12utela​ ,

indeed this is probably not documented as it is an internal SBSFU behavior.

As you may know, the firmware installation procedure "swaps" the 2 slots (active slot and OTA slot).

We need to "follow" this procedure in case a problem occurs (power shutdown for instance) and we need to restart the procedure.

So, this trailer is a critical area, placed at the end of the OTA slot, which allows SBSFU to know the progress of the installation process.

I am not sure if this design evolved in the latest SBSFU revisions, but basically the OTA slot is organized like this:

[sute]

Thanks! I solved this by adding to the linker script:

.trailer :
 {
 . = . + SBSFU_TRAILER_SIZE;
 } > APP_ROM

Now linking will fail already if firmware overlaps with the trailer.

[Fred]

Indeed, even the integration guide does not mention it:

https://www.st.com/resource/en/application_note/an5056-integration-guide-for-the-xcubesbsfu-stm32cube-expansion-package-stmicroelectronics.pdf

As you resize the slots, I think it is important to:

• follow section 3.2.2
• consider this trailer area (unfortunately not documented) because it implies that not the entire slot can be used for the firwmare image

For the trailer, you can find the details in sfu_fwim_swap.c:

/* DWL_SLOT_REGION_SIZE */
/* <-----------------------------------------------------------------------------------------------------> */
/* |HEADER_TOT_LEN|HEADER_TOT_LEN|MAGIC_LENGTH|MAGIC_LENGTH|N*sizeof(FLASH_write_t)|N*sizeof(FLASH_write_t) */
/* | header 1 | header 2 |SWAP magic |CLEAN pat. | N*CPY_TO_ACTIVE_SLOT | N*CPY_TO_DWL_SLOT */
/* */
/* Please note that the size of the trailer area (N*CPY_TO_SLOTx) depends directly on SFU_LL_FLASH_write_t type, */
/* so it can differ from one platform to another (this is FLASH-dependent) */
#define TRAILER_SIZE(A) ((sizeof(SFU_LL_FLASH_write_t)*(TRAILER_INDEX(A)))\
 + (sizeof(SFU_LL_FLASH_write_t)*(TRAILER_INDEX(A))) + (uint32_t)(TRAILER_HEADER))
#define TRAILER_BEGIN(A) (( uint8_t *)(SlotStartAdd[A]\
 + SLOT_SIZE(A) - TRAILER_SIZE(A)))

[Fred]

If the FLASH size becomes an issue, please note that STM32H7B3I-DK demonstrates an external flash usage in this project: "2_Images_ExtFlash"