cancel
Showing results for 
Search instead for 
Did you mean: 

SBSFU with SFI conflict and have made my board inaccessible.

moosterlaken
Associate II

Hello,

I am developing a new product with the STM32h753, and we are trying to use both SBSFU and SFI. The secure boot implementation was already integrated and working before tackling SFI. When tackling SFI, I first tested it with a simple program without secure boot. This worked perfectly, exactly as advertised. Then I tried using SFI on our debug binary. This binary was the combined SBSFU + User application binary where the bootloader exists at the normal program counter and the user application exists in the first slot. This version of our bootloader had all the protections disabled. (RDP 0 WRP 0 etc.). This is the working firmware of our application, and I tested it with normal programming before testing SFI. So finally I build the SFI image to test the SFI and the STM32CubeProgrammer had some errors, but it seems to complete correctly. Then the device became inaccessible. I tried accessing the device with USB and UART while enabling boot 0 as well as STLINK and the device just doesnt seem to exist. What happened here? The options bytes were not set to any heavy restrictions, so this should not have happened right? I have copied the STM32CubeProgrammer log from the failed SFI process below:

12:44:31 : Requesting Chip Certificate from device ...
12:44:32 : Get Certificate done successfully
12:44:32 : requesting license for the current STM32 device
12:44:32 : Init Communication ...
12:44:32 : P11 lib initialization Success!
12:44:32 : Opening session with slot ID 1...
12:44:32 : Succeed to Open session with reader slot ID 1
12:44:33 : Succeed to generate license for the current STM32 device
12:44:33 : Closing session with reader slot ID 1...
12:44:33 : Session closed with reader slot ID 1
12:44:33 : Closing communication with HSM...
12:44:33 : Communication closed with HSM
12:44:33 : Succeed to get License for Firmware from HSM slot ID 1
12:44:33 : Starting Firmware Install operation...
12:44:33 : Activating security...
12:44:33 : Warning: Option Byte: SECURITY, value: 0x1, was not modified.
12:44:33 : Warning: Option Bytes are unchanged, Data won't be downloaded
12:44:33 : Time elapsed during option Bytes configuration: 00:00:00.057
12:44:33 : Activating security Success
12:44:33 : Setting write mode to SFI
12:44:33 : Warning: Option Byte: BCM4, value: 0x0, was not modified.
12:44:33 : Warning: Option Byte: BCM7, value: 0x1, was not modified.
12:44:33 : Warning: Option Byte: SECURITY, value: 0x1, was not modified.
12:44:33 : Warning: Option Byte: ST_RAM_SIZE, value: 0x3, was not modified.
12:44:33 : Warning: Option Bytes are unchanged, Data won't be downloaded
12:44:33 : Time elapsed during option Bytes configuration: 00:00:00.055
12:44:33 : Succeed to set write mode for SFI
12:44:33 : Starting SFI part 1
12:44:33 : Writing license to address 0x24020800
12:44:33 : Writing Img header to address 0x24021000
12:44:33 : Writing areas and areas wrapper...
12:44:41 : Sending Go command...
12:44:42 : Reconnecting...
12:44:43 : Error: Target device not foundEstablishing connection with the device failed
12:44:43 : ...retrying...
12:44:43 : Error: Target device not foundEstablishing connection with the device failed
12:44:43 : ...retrying...
12:44:44 : Error: Target device not foundEstablishing connection with the device failed
12:44:44 : ...retrying...
12:44:45 : USB speed : Full Speed (12MBit/s)
12:44:45 : Manuf. ID : STMicroelectronics
12:44:45 : Product ID : DFU in FS Mode
12:44:45 : SN : 200364500000
12:44:45 : DFU protocol: 1.1
12:44:45 : Board : --
12:44:45 : Device ID : 0x0450
12:44:45 : Reconnected !
12:44:45 : SECURITY State Success
12:44:45 : Starting SFI part 2
12:44:45 : Writing license to address 0x24020800
12:44:45 : Writing Img header to address 0x24021000
12:44:45 : Writing areas and areas wrapper...
12:44:50 : all areas processed
12:44:50 : Sending Go command...
12:44:50 : Warning: Could not verify security state after last chunk programming
12:44:50 : SFI Process Finished!
12:44:50 : SFI file Install Operation Success
12:44:51 : Warning: Connection to device 0x450 is lost
12:44:51 : Disconnected from device.

1 ACCEPTED SOLUTION

Accepted Solutions
moosterlaken
Associate II

Update:
The original device was inaccessible due to option bytes setting the boot addresses. I believe this is the core way some of SFI works since the boot address gets changed to a location in RAM which is where the secure engine probably runs. So then the boot0 mode becomes the default x0800 program address and the regular boot mode is supposed to boot into RAM. If something goes wrong, like it did in my case. The only way to recover the device is to set the Boot0 pin and then use the SWDIO in hot-plug mode to change the option bytes back.

I ended up getting SFI working with secure boot by following the README of the STM32_XCube_SFI NUCLEO-H753ZI project. The main difference being using the option bytes file supplied by that project vs generating one on the STM32 Trusted Package Creator. The STM32 Trusted Package Creator option bytes generation seems to be wrong for the H753 CPUs. I burned through a lot of licenses when programming with the HSM. Kind of annoyed that the lack of documentation and error handling caused me to lose those licenses. I had so many flash attempts where the console said "SFI success!" but checking my Flash, it was completely erased still and the SFI license counter went down. 

View solution in original post

2 REPLIES 2
moosterlaken
Associate II

Update:
I was able to access my device again by help of the solution found on this Forum page:
https://community.st.com/t5/stm32-mcus-security/error-connecting-board-to-stm32cubeprogrammer/m-p/674976
I changed the Mode to "Hot plug" and set boot0 pin high while trying to connect with STLINK.

I should be able to continue experimenting safely now, however, any debugging advice or insight would be much appreciated.

moosterlaken
Associate II

Update:
The original device was inaccessible due to option bytes setting the boot addresses. I believe this is the core way some of SFI works since the boot address gets changed to a location in RAM which is where the secure engine probably runs. So then the boot0 mode becomes the default x0800 program address and the regular boot mode is supposed to boot into RAM. If something goes wrong, like it did in my case. The only way to recover the device is to set the Boot0 pin and then use the SWDIO in hot-plug mode to change the option bytes back.

I ended up getting SFI working with secure boot by following the README of the STM32_XCube_SFI NUCLEO-H753ZI project. The main difference being using the option bytes file supplied by that project vs generating one on the STM32 Trusted Package Creator. The STM32 Trusted Package Creator option bytes generation seems to be wrong for the H753 CPUs. I burned through a lot of licenses when programming with the HSM. Kind of annoyed that the lack of documentation and error handling caused me to lose those licenses. I had so many flash attempts where the console said "SFI success!" but checking my Flash, it was completely erased still and the SFI license counter went down.