FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Flashing device in Closed_device / Secured_Locked state over USB (DFU)

Go to solution
gbe
Associate II

‎2025-11-04 9:47 AM - edited ‎2025-11-04 9:49 AM

Hi, 

we have a custom board using STM32MP157C that seems to be bricked and can no longer be flashed with STM32 Cube Programmer over USB (DFU) after fusing the Closed_device bit in OTP.

Before that we verified our image with signed FSBL and FIP with TRUSTED_BOARD_BOOT enabled. Logs suggested that secure boot was working fine.

After programming OTP with STM32PRGFW-UTIL and setting Closed_device bit the device won't boot and can also no longer be flashed successfully. I guess FSBL got overwritten by the one from STM32PRGFW-UTIL which was not signed. However I don't understand why flashing no longer works.

Does STM32 Cube Programmer USB/DFU flashing rely on a signed working FSBL already on the device?

From the documentation here https://www.st.com/resource/en/application_note/an5275-introduction-to-usb-dfuusart-protocols-used-in-stm32mp1-and-stm32mp2-mpu-bootloaders-stmicroelectronics.pdf in 1.7.1 Case 1 – programming from reset it sounds like that Cube Programmer loads FSBL and SSBL directly into RAM. Do I manually need to sign those? 

Clarification on how flashing works in Closed_device would be appreciated.

 

0 Kudos
1 ACCEPTED SOLUTION

Accepted Solutions
Go to solution
gbe
Associate II

‎2025-11-05 4:09 AM

We could solve the problem now.

Here a short summary what we learned:

  1. It turned out that the OTP management utility STM32PRGFW-UTIL .stm32 file needs to be signed with the ROT_KEY with the signing tool, once the device is in locked state. If you do not sign it, you lose access to OTP and also flashing is not possible anymore. Once you use a correctly singed version you gain access to OTP again via STM32Programmer

  2. Also the TF-A BL2 used for programming via USB DFU with STM32Programmer needs to be signed, what we did.

  3. It turned out, what we think is a lack of documentation, that the monotonic OTP counter (anti rollback monotonic counter) is incremented when you lock the device (from 0 to 1). So the tf-a bl2 for emmc or sdcard boot which are already on the device prior to locking and were verified to boot correctly and authenticate correctly prior to lock, do not boot anymore (they have counter 0). No output no error message etc.

  4. You need to have the final producion / after lock TF-A and FIP set to counter 1 minimum to be bootable after locking.

Now flashing and secure boot in closed device state is working correctly.

View solution in original post

1 REPLY 1
Go to solution
gbe
Associate II

‎2025-11-05 4:09 AM

We could solve the problem now.

Here a short summary what we learned:

  1. It turned out that the OTP management utility STM32PRGFW-UTIL .stm32 file needs to be signed with the ROT_KEY with the signing tool, once the device is in locked state. If you do not sign it, you lose access to OTP and also flashing is not possible anymore. Once you use a correctly singed version you gain access to OTP again via STM32Programmer

  2. Also the TF-A BL2 used for programming via USB DFU with STM32Programmer needs to be signed, what we did.

  3. It turned out, what we think is a lack of documentation, that the monotonic OTP counter (anti rollback monotonic counter) is incremented when you lock the device (from 0 to 1). So the tf-a bl2 for emmc or sdcard boot which are already on the device prior to locking and were verified to boot correctly and authenticate correctly prior to lock, do not boot anymore (they have counter 0). No output no error message etc.

  4. You need to have the final producion / after lock TF-A and FIP set to counter 1 minimum to be bootable after locking.

Now flashing and secure boot in closed device state is working correctly.

Top