STM32 MCUs Security

Security:Introduction to STM32H5 security - stm32mcu “Approved version. Approved on: 10:25, 18 May 2026”The following links are broken:In the intro section, the text “For general STM32 security see this article and AN5156.”: The link “this article” is https://wiki.st.com/stm32mcu/wiki/Security:Security_overview which shows a “Page not found” error page. In section 2, in the bullet point about PCROP, the text “Obviously this feature is redundant with the availability of TrustZone® and HDP.”: The link “TrustZone” goes to Security:How to disable TrustZone in STM32L5xx devices during development phase - stm32mcu which is for a different MCU and not very relevant for STM32H5. In section 3, the text “For introduction on these features, refer to this guide.”: The link “this guide” is https://wiki.st.com/stm32mcu/index.php?title=Security:Guide_to_use_specific_security_feature&action=edit&redlink=1 - which does not exist. section 3.2, the text “For broader context follow here.”: The lin

Hi team,we have custom project based on STM32U558 controller with TrustZone, and I am only involved in small part of the project.but i would like to learn about this trust zone is enabled and how both secure and non secure zone are talking.how i will identify which peripheral and which pins are intialised as secure and non secure part.also will appreciate if provided with reading section for trustzone.(prefer small blogs, not big one just because i am a new to trust zone).

Hello,I’m working with a project with STM32h563 micro which includes the use of the OEMiROT bootloader. I tried different solution to set up the project, and, in order to use CubeMX, I think this is the “normal” way. However, there are some things that look awkward to me.If you want to use the OEMiROT bootloader included in the firmware package mentioned in the tutorial, it seems to be mandatory to strictly respect the folder tree given used inside the package. This means that your application project has to reside in STM32Cube_FW_H5_V1.6.0/Projects/NUCLEO-H563ZI/Applications/ROT/ even if you are not using a NUCLEO board. When, in CubeMX, you set the Boot Path and Debug Authentication options, you can modify the OEM_iROT reference location but not the Config Files Location, which is mandatory to be inside the ROT_Provisioning folder automatically created inside the newly created application (e.g. STM32Cube_FW_H5_V1.6.0/Projects/NUCLEO-H563ZI/Applications/ROT/ROT_Provisioning). However,

Hello everyone,I am looking for some help getting started with the STSAFE-A110 in a new project.My Setup: MCU: Custom board using STM32H503CBT6 Secure Element: X-NUCLEO-SAFEA1B expansion board Software: STM32CubeIDE with the X-CUBE-SAFEA1 middleware added via CubeMX Output: I am using the USB CDC Virtual COM port (Classic Middleware) for my output. I have not enabled and am not using UART. The Problem:I am completely stuck trying to get the initial communication working. I cannot seem to establish communication between the STM32H5 and the STSAFE-A110 through I2C, and I cannot get StSafeA_Init() to initialize the STSAFE properly.I have tried reading the user manual (UM2646 - Getting started with the X-CUBE-SAFEA1), but I find it extremely confusing. It does not clearly outline the necessary steps that I need to take to start the project properly from code generated by CubeMX.What I need help with:Could someone provide a clear, step-by-step guide on how to actually bring up the STS

Hi ST team,we are currently developing a new industrial product embedding the STM32U5A5ZJT6Q MCU.For our system reliability assessment, we would like to request the official reliability data for this specific component.Could you please provide:MTBF (Mean Time Between Failures) FIT rate (Failures In Time)If available, we would prefer values calculated according to:Telcordia SR-332 MIL-HDBK-217 Ground Benign (GB) operating environment assumptionsThank you for your support.Best regards

Processor is  STM32U585CIU6Q. I have a trust zone project (STM32IDE) that runs just fine without the boot loader. At reset the secure project runs, transfers control to the non-secure and I can make calls to functions on the secure side just fine. All is good.This is boot loader development effort. I don’t have code to actually receive images yet. I place the secure and non-secure projects in place with the IDE and run the boot loader. When the boot loader transfers control to the secure application it seems to initially work OK.  I get to the secure application OK, The secure application transfers control to the non-secure project OK. However, as soon as i try to make a call to a secure function the system hangs.To transfer out of the boot loader I save a flag in protected memory and do a SW reset. I have used this technique on other ST parts as a way to get the processor in a known state. When I come out of reset the boot loader immediately (before any initialization except C init) t

Hi, I use OEMiROT_Appli_TrustZone +OEMiROT_Boot to do some change in order to migrate to my project. Version: STM32Cube_FW_H5_V1.5.0 1.i change the secure image and non secure image size in flash_layout.h from OEMiROT_Boot. #define FLASH_S_PARTITION_SIZE (0x20000) /* 128KB for S partition */ #if defined(DEVICE_1M_FLASH_ENABLE) #define FLASH_NS_PARTITION_SIZE (0x30000) /* 192 KB for NS partition */ #else #define FLASH_NS_PARTITION_SIZE (0x60000) /* 384 KB for NS partition */ ​2.then rebuild the OEMiROT_Boot. it will autocratically change the ld file and image.xls size of OEMiROT_Appli_TrustZone. 3.rebuild OEMiROT_Appli_TrustZone secure ap and non secure app 4.execute STM32Cube_FW_H5_V1.5.0\Projects\NUCLEO-H563ZI\ROT_Provisioning\OEMiROT\provisioning.bat OK 5.reconnet the board with UART . it shows the error as follow:. INF] TAMPER Activated [INF] BANK 1 secure flash 0, 27] : OB [0, 14] [ERR] Unexpected value for secure flash protection

Have successfully worked throughSTM32Cube_FW_U5_V1.8.0/Projects/B-U585I-IOT02A/Applications/SBSFU/readme.htmlI need to port this (..boot, ..loader, ..appli) to a custom board running STM32U585VIT6.Within the readme it states "This example has been tested with STMicroelectronics B-U585I-IOT02A board and can be easily tailored to any other supported device and development board."Is there an example / idiots guide to work through doing the above?Thanks 

Hello,I'm currently integrating the SBSFU 2.8 for one of our board, that use a STM32H753, with a dual-slot configuration.I'm adapting the example for the STM32H753ZI. For now, this mostly involves modifying the USART (use the 6 instead of the 3).I am currently trying to set up the system to resume operation after a power outage. I defined ENABLE_IMAGE_STATE_HANDLING in the projects SeCoreBin and SBSFU.This is my scenario:Download of a UserAppValidation of the downloaded UserAppDecryption of the UserAppStart of the swap between the DownloadSlot and the ActiveSlot/!\ Power outage!Power returnResume of the installation processCurrently, the resume always fails when checking the trailer (in CheckTrailerMagic).I checked what he wrote as trailer (in WriteTrailerHeader), and what is written is indeed what is read after the reset.What's strange is how he slices up what he's checking.If we look at the names of the arrays in the CheckTrailerMagic function, we have:FieldValue readm

Hello,I’m working with the STM32CubeWB package and trying to understand ST’s plans regarding VEX documentation following annoucements here https://wiki.st.com/stm32mcu/wiki/Security%3ASTM32%20Software%20security%20policies%20Q%26A# Could you clarify the plan for STM32CubeWB specifically?Is VEX publication still planned for STM32CubeWB? If yes, is there an estimated timeline or target STM32CubeWB release version? Where will the VEX files be published: inside the STM32CubeWB package, on st.com, on GitHub, or next to the existing sbom_cdx.json file? Will VEX documents be provided per STM32CubeWB version, or only for the latest available package? Will VEX entries map directly to SBOM components using bom-ref or Black Duck component IDs from the associated SBOM, or another identifier? Can we expect more detailed vulnerability information than what is currently available through PSIRT bulletins, for example affected/not affected status, justification, fixed version, remediation, or workaroun

Hello, I am trying to create a very simple TZ-Enabled application on the STM32H573 in a CMake project. My application can build and flash to the IC and execute the main.c of the secure world but it hard faults, I believe when switching to the non-secure world. I am unsure of why it does this and would like help figuring that out. I’ve attached the project to this post and I will provide information below: Fault Analyzer OutputFault Analyzer OutputR0:      0x2009FC00 ← Non-Secure RAM (Non-Secure SP?)R1:      0x08110B68 ← Non-Secure FLASH (See Vector Table Non-Secure Memory (Non-Secure Main Entry?))R2:      0x08110B68 ← See AboveR3:      0x08110B68 ← See AboveR12:    0x08110B68 ← See AboveSP:      0x3004FF74 ← Secure RAMLR:      0xFFFFFFA9PC:      0x0C000FF6XPSR: 0x09000003 Vector Table Non-Secure MemoryThis is some data from memory address 0x0810 0000Address 0 4 8 C 0x0810 0000 200A 0000 0811 0B69 0811 0BC5 0811 0BC5 0x810 0010 0810 03BD 0811 0BC5 0810 03C3 081

Hello,I’m using the SBSFU by MCUboot implementation from the STM32CubeU5 Project (here).It works well on the target board (U585) and I succeeded at uploading a new firmware through Teraterm, as per the documentation :  But our teams cannot all have access to a PC with Windows, and as such I attempted to make an upload with Minicom on Linux (Ubuntu) instead, which did not work (I added the “Bytes” logging before the “Abort from user” message) :  I saw much discussions about a similar problem on the legacy SBSFU 2.4 / 2.7 (this one or this one for example), but none for the one using MCUboot. I’ve still tried most of the solutions proposed there, but to no avail. I’ve tried fiddling around the code to see why the Ymodem protocol was failing through Minicom, but haven’t found much actionable information up to now.Has anyone encountered this problem and may know how to patch it or work around it ?I’ll continue to investigate on my end and document my eventual findings here. Thanks in advan

I am trying to disable the write protection on an STM32G431K (on a Nucleo-G431KB) by settings the option bytes using CubeProgrammer:However, “Apply” fails with the log showing:11:14:40:365 : Option byte command : -ob WRP1A_STRT=0x3f WRP1A_END=0x0 11:14:40:367 : qCmd : -ob WRP1A_STRT=0x3f WRP1A_END=0x0 11:14:40:367 : PROGRAMMING OPTION BYTES AREA ...11:14:40:368 : Database: Config 0 is active.11:14:40:368 : Bank : 0x0011:14:40:368 : Address : 0x40022020 11:14:40:368 : Size : 84 Bytes11:14:40:373 : halt ap 0 11:14:40:381 : Loader write option bytes...11:14:40:381 : Init flashloader...11:14:40:381 : halt ap 0 11:14:40:389 : run ap 0 11:14:40:390 : halt ap 0 11:14:40:396 : run ap 0 11:14:40:420 : Reconnecting...11:14:41:549 : ST-LINK SN : 00190036313351123630373911:14:41:549 : ST-LINK FW : V3J17M1011:14:41:549 : Board : NUCLEO-G431KB11:14:41:550 : Voltage : 3.27V11:14:41:739 : Error: Unable to get core ID11:14:41:739 : Error: Cannot connect to acce

On a secured STM32H7Sx device (in CLOSED or LOCKED product state), what is the recommended way of passing volatile data to lower HDPL levels?According to the reference manual, the SBS_RSSCMDR register can be used to pass volatile data from HDPL 1, 2 or 3 to HDPL 0 (RSS), so that part of the answer is covered:Bits 15:0 RSSCMD[15:0]: RSS commandThe application can use this bitfield to pass on a command to the RSS, executed at thenext reset.But what if you want to pass volatile data from HDPL 2 or 3 to HDPL 1?(E.g., HDPL 2 wants to call into HDPL 1 so HDPL 2 first needs to write some volatile command somewhere, then execute a reset, then HDPL 0 (RSS) boots, then HDPL 1 boots and picks up the volatile command from somewhere.)SBS_RSSCMDR cannot be used because RSS will interpret this value as well, and RSS might clear this value at the moment it boots HDPL 1.

Hi ST!I’ve been having some difficulty trying to integrate my UART project inside the architecture outlined in your OEMiRoT_Appli_TrustZone example for the NUCLEO-U385RG-Q. Note this example is incompatible with CubeMX and therefore I’m somewhat on my own when it comes to setting up additional peripherals (like USART3).I’m currently able to send in a string to uart3 using HAL_UART_Transmit, however am not able to trigger an interrupt when attempting to input to uart3 - code below: char *msg = "USART3 TEST 3\r\n"; HAL_UART_Transmit(HUART, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY); HAL_UART_Receive_IT(HUART, &uart_rx_byte, 1);I’ve tried using VSCodes compare functionality to mirror a CubeMX generated TrustZone example with uart enabled, so far adjusting sections of stm32u3xx_it.h/c, stm32u3xx_hal_conf.h/c and partition_stm32u385xx.h, with some nudging from this forum question https://community.st.com/stm32-mcus-embedded-software-32/stm32h563-trustzone-usart3-interrupts-not-working

Hello ST Community,Following your suggestion @Onizuka09, I developed a software program as per the example STM32H753_SecureMem_ExampleV1.1.After updating the software, I noticed that the part for printing strings via UART (printf) was missing, but it had already been downloaded to the MCU and the software was started. After correcting the code for the printf prints, I no longer want to connect via ST-LINK to download the software to the MCU.So, I try connecting with the STM32CubeProgrammer to attempt to erase all the flash memory. This popup appears:Even if I change modes such as "Under Reset" and "Core Reset," this popup appears:I'm afraid that when the software started, even without seeing the strings in printf via UART, it may have set some security parameters, or option bytes, or disabled Boot for CM7 and CM4.The software had an option that allowed you to reset those parameters and return to the ST-LINK connection mode without any problems.So, is there a way to connect to the STM32

hello ST CommunityIs it possible to erase all flash memory including the protection by shorting some hardware pins?thanks for supports

I have a STM32U585 (edit: ...VIT6, so not the one where this doesn't work due to errata) product with Trustzone enabled, Bootlock disabled and RDP level 0.I want to bring this into ST bootloader mode from software (for easy Firmware change via USB).To my understanding that would mean implementing the last entry of Pattern 12 from AN2606  Which means the following code, executed from secure side.RCC->APB3ENR |= RCC_APB3ENR_SYSCFGEN; //clock is disabled after startup, so enable __DSB();//make sure data is written SYSCFG->RSSCMDR = 0x1C0; //pattern from AN2606, RM says any value will do? __DSB();//make sure data is written __NVIC_SystemReset(); //SW reset But all I get is a restart to SECBOOTADD0. And RSSCMDR is zeroed out afterwards, even though the RM states that it is only affected by power on reset.What am I doing wrong?

Hello ST Community,Before releasing the next revision of our prototype board, we would like to verify that the hardware implementation of the ST33KTPM2I is correct and that there are no hardware design issues.Currently, the ST33KTPM2I is implemented as an optional component on our board. Before modifying the board design, we would like to perform some basic functional checks to confirm that the device is operating properly.Our interface is SPI.Is there any recommended way to verify communication with the ST33KTPM2I? For example, is it possible to read a device ID register or any other status information to confirm that the device is responding correctly?We reviewed the datasheet, but it does not appear to provide details about accessible registers or a register map. Therefore, we are not sure what commands or procedures can be used to perform a basic hardware validation.Thank you very much for your support.Below is our hardware schematic:  

HiI am implemented flash write protect on STM32U5 using option byte register FLASH_WRP2AR.Following these steps to write protect page 0x4C and 0x4D page in Bank 2- Unlock flash - Unlock Flash option register(FLASH_OPTR)- Unlock flash page by setting UNLOCK bit(31) in FLASH_WRP2AR- Write WRP2A_PSTRT[6:0] of  FLASH_WRP2AR with value 0x4C- Write WRP2A_PEND[[6:0] of  FLASH_WRP2AR with value 0x4D- Lock flash page by clearing UNLOCK bit(31) in FLASH_WRP2AR - Initiate option byte programming by setting OPTSTRT bit FLASH_NSCR register - Wait for flash operation to complete - Lock FLASH_OPTR register - Lock FlashThis sequence works some times , however most of the time  after option byte programming FLASH_WRP2AR value resets to following value and write protect is disabled. - WRP2A_PSTRT[6:0]: 0x7F - WRP2A_PEND[[6:0]: 0x00OPTWERR bit sets in FLASH_NSSR indicating that invalid configuration, however configuration looks right.Regards,Hareesha 

I am a user of the NUCLEO-N657X0-Q board. I am using the NUCLEO-N657X0-Q board with Root of Trust enabled, and I want to use the RTC.Out of the 3 stages  (FSBL → Secure App → Non-Secure App)  I want to use the RTC in the Non-Secure App. My development environment is as follows:1> Development tool: Keil uVision V5.422> Example source: STM32Cube\Repository\STM32Cube_FW_N6_V1.2.0\Projects\NUCLEO-N657X0-Q\Applications\ROT\OEMuROT_Appli3> Development board: NUCLEO-N657X0-Q The biggest problem is that when HAL_RTC_Init() is called in the Non-Secure App, it hangs. The source for STM32Cube_FW_N6_V1.2.0\Projects\NUCLEO-N657X0-Q\Applications\ROT\OEMuROT_Appli was created by referencing STM32Cube_FW_N6_V1.2.0\Projects\STM32N6570-DK\Applications\ROT\OEMuROT_Appli. The code I added is as follows.1. Added to the main function of the Secure App.HAL_RIF_RISC_SetSlaveSecureAttributes(RIF_RCC_PERIPH_INDEX_RTC, RIF_ATTRIBUTE_NSEC);2. Added a function to the Non-Secure App.RTC_HandleTypeDef RtcHa

I am currently working with SBSFU on the STM32H743ZIT6 series and have implemented several modifications to its core functionality. I would like to clarify the potential impact of these changes.1. Modification to SBSFU FunctionalityI have altered the default SBSFU behavior by replacing the traditional firmware swapping mechanism with a bank-switching approach to reduce application downtime.Both Bank 1 and Bank 2 will contain the bootloader and the application. Bank selection is managed using the swap option byte.2. Relocation of Swap AreaI plan to relocate the swap area from Sector 8 to Sector 15, considering that Bank 2 spans from Sector 0 to Sector 7.The swap area is used during the decryption process. It requires 128 KB of memory.3. Clarification RequiredI would like to understand whether these modifications will have any impact on the system:Will the transition from a swap-based mechanism to a bank-switching approach affect the core functionality, integrity, or reliability of SBSFU

We are seeing a very odd data corruption issue which is highly repeatable, and appears to be related to a configuration setting which we haven't yet identified.In our system (running on an STM32H7S7), we're using the STiROT + OEMuROT secure bootloader to load our application. After a minute or two, the application causes a hard fault.The issue comes down to a POP instruction. I can see in the debugger that a value is being copied from the stack to a register, but one of the bits is flipped. Subsequent instructions do some indirection which ultimately causes the hard fault.It's always the same instruction in the same line of code. It always occurs within the first minute or two of execution.Using the debugger, we can see that the value in the stack (stored in DTCM) is correct. The error occurs when it's copied to the register. And although the error always occurs at the same address, it doesn't appear to be a fault with that location, as when I moved the stack to elsewhere in DTCM,

Hi everyone,I tried Secure Firmware Install (SFI) with the Nucleo-H563ZI. The process failed, however my device is still accessible. By connecting to the device via Hot plug and Access port 1 I am able to see that the device is in "Provisioning" state.The option bytes are as follows:{ "deviceId" : 1156, "bitNameToValue" : { "PRODUCT_STATE" : 23, "BOR_LEV" : 0, "BORH_EN" : 0, "IO_VDD_HSLV" : 0, "IO_VDDIO2_HSLV" : 0, "IWDG_STOP" : 1, "IWDG_STDBY" : 1, "BOOT_UBE" : 195, "SWAP_BANK" : 0, "IWDG_SW" : 1, "NRST_STOP" : 1, "NRST_STDBY" : 1, "TZEN" : 180, "SRAM2_ECC" : 1, "SRAM3_ECC" : 1, "BKPRAM_ECC" : 1, "SRAM2_RST" : 1, "SRAM1_3_RST" : 1, "NSBOOTADD" : 524288, "NSBOOT_LOCK" : 195, "SECBOOT_LOCK" : 0, "SECBOOTADD" : 0, "SECWM1_STRT" : 0, "SECWM1_END" : 127, "WRPSGn1" : -1, "SECWM2_STRT" : 0, "SECWM2_END" : 127, "WRPSGn2" : -1, "LOCKBL" : 0, "EDATA1_EN" : 0, "EDATA1_STRT" : 0, "EDATA2_EN" : 0, "EDATA2_STRT" : 0, "HDP1_STRT" : 1, "HDP1_END" : 0, "HDP2_

The issue feels really simple, and it's easy to do on N6. At the core, I am running out of MPU regions as there are only 8 available. So it would be nice to have a small chunk of SRAM, where privileged code can share data with unprivileged code. Say a status or something like this.GTZC only controls both read and write. So I cannot say that a single 512 byte block is read/write for privileged code, but read only for unprivileged.