2020-11-03 01:48 PM
Hello, in one my project I need to have SBSFU. On first version on my board I had STM32F405 uC and was successfully ported example STM32F413H_Discovery_2_Images_SBSFU. For test the porting I changed startup file in the discovery example for 405 series and make a bit chagings in functions which writing data to FLASH, also made changes for UART pins and the button. Same things I try to do fo STM32429VIT uC (2 Banks Flash) - but it not working, I have next errors in the UART terminal:
= [SBOOT] STATE: HANDLE CRITICAL FAILURE
= [EXCPT] SIGNATURE CHECK FAILED!
Cheking under debug I found the error became from firmware tag verification part in file
sfu_fwimg_core.c (see more in the attachment):
/* Firmware tag verification */
if (MemoryCompare(fw_tag_output, fw_tag, SE_TAG_LEN) != SFU_SUCCESS)
{
*pSeStatus = SE_SIGNATURE_ERR;
se_ret_status = SE_ERROR;
sfu_ret_status = SFU_ERROR;
memset(fw_tag_validated, 0x00, SE_TAG_LEN);
For the mapping_fwimg.h I used same address like for 405 uC ported project (all located in first bank of the flash) (see more in the attachment);
For the the mapping_sbsfu.h I used same address like in example for 413 and ported 405, just changed SB_REGION_RAM_END address according to my uC (see more in the attachment).
In document Porting X-CUBE-SBSFU onto another board in section 3.2.2 I found next information:
For dual-bank Flash memory devices, firewall specific constraints are:
• Firewall code segment must be in bank1, firewall non-volatile data (including header of Slot #0) segment must be in bank2.
• Firewall code and non-volatile data segments must have the same size and offset compared to the beginning of the bank.
the info not fully clear for me - I tried allocate Slot 0 in Bank 2, - same issue, but maybe I did it not correct;
If someone worked with it before (porting the SBSFU example to an another uC with dual - bank flash) - and understand my issue - please help me to understand what could be wrong.
Thanks!
2020-11-11 04:31 AM
Did you progress any further?
2021-03-04 06:27 AM
Hello Yurii,
Did you solve the problem? If so, could we know what caused this? I happen to have ported the the same bootloader to the same MCU (STM32F429) and I have not seen this problem until today. It happened once after flashing it and I try to understand why. I had not seen this before. It disappeared after a full chip erase.
Thank You,
Mathieu
2021-03-04 06:50 AM
I'm not sure it's your problem but one requirement in SBSFU is that there must not be initialized bytes in Flash memory after the official end of the current firmware.
If there are additional initialized data in application Slot, the SBSFU considers it's an attack and refuses to go further.
if you are developing and often flashing new images with your IDE, if the current image is smaller than the previous one, then there may be remaining non erased bytes from previous image. The IDE only erase the needed sectors. You have to erase "manually" the remaining flash sectors. Erasing all the Flash memory solves this. Or, if you know roughly the max size of your application you can erase only the initialized sectors (using STM32CubeProgrammer CLI for example).
This behavior can be disabled in SBSFU sources but you have to find where . If you disable it you have to remember to re-enable this check in the final product.
2021-03-04 06:54 AM
Interesting! Thank You.
I happened to have the same error as in the original post:
/* Firmware tag verification */
if (MemoryCompare(fw_tag_output, fw_tag, SE_TAG_LEN) != SFU_SUCCESS)
{
*pSeStatus = SE_SIGNATURE_ERR;
se_ret_status = SE_ERROR;
sfu_ret_status = SFU_ERROR;
memset(fw_tag_validated, 0x00, SE_TAG_LEN);
}
2021-04-20 11:22 AM
Hi! Do you still have the ported code to F405? I didn't get to make work. Always show this error when I try to upload sfb file:
Abnormal error 1 at line 2323 in D:/Projects/LoRaWAN_Fuota1/2_Images_SBSFU/SBSFU/App/sfu_fwimg_swap.c
= [SBOOT] STATE: HANDLE CRITICAL FAILURE
= [EXCPT] FLASH ERROR!
= [SBOOT] STATE: REBOOT STATE MACHINE