STM32 MPU ROM code overview

Applicable for STM32MP13x lines, STM32MP15x lines


1 ROM code overview[edit]

The ROM code is the first code executed by the Arm® Cortex®-A7 core(s) after reset.
The main features of the ROM code are listed in the table below for each STM32MP1 Series processor:

ROM code features STM32MP13x lines Warning.png STM32MP15x lines More info.png
STM32 header for FSBL loading v2 v1
Boot mode selection Serial boot Yes Yes
Flash memory boot Yes Yes
Developer (AKA "engineering") mode Yes Yes
SSP (secure secrets provisioning) Yes Yes
RMA (return merchandise authorization) Yes Yes
Image loading binary size (without STM32 header) 128 KB 247 KB
Secure boot FSBL authentication (ECDSA) Yes Yes
FSBL authentication key revocation Yes (x8) No
FSBL anti-rollback mechanism Yes Yes
FSBL decryption (AES) Yes No
Cryptographic accelerators (ECDSA, AES) Yes No
Secondary core boot No (N.A.) Yes
Wake up from low power modes Yes Yes
Secure services export No Yes


The diagram below puts those features in sequence, to illustrate the ROM code execution flow, and each step is then further described in the following paragraphes.

Alternate text

2 STM32 header[edit]

To be properly recognized by the ROM code, the binary file loaded from the boot device has to comply with a proprietary format, starting with a STM32 header.
The STM32MP15x lines More info.png complies with STM32 header v1 whereas the STM32MP13x lines Warning.png uses the v2 : the difference between those versions is mainly due to the introduction of the new Secure boot features, listed in the previous paragraph and described in the following ones.

3 Boot mode selection[edit]

3.1 Boot device selection[edit]

As shown in the figure and table below, the boot mode is determined by the boot pins positions, OTP words and one TAMP register.

Alternate text
ROM code - boot source selection
BOOT pins STM32MP13 TAMP_REG[30]
STM32MP15 TAMP_REG[20]
(Force Serial)
Primary boot source Secondary boot source Boot source #1 Boot source #2
if #1 fails
Boot source
if #2 fails
b000
(Force Serial)
x (don't care) x (don't care) x (don't care) Serial - -
b001 != 0xFF 0 (virgin) 0 (virgin) QSPI NOR Serial -
b010 != 0xFF 0 (virgin) 0 (virgin) eMMC Serial -
b011 != 0xFF 0 (virgin) 0 (virgin) FMC NAND Serial -
b100
(DEV Boot)
x (don't care) x (don't care) x (don't care) NoBoot - -
b101 != 0xFF 0 (virgin) 0 (virgin) SD-Card Serial -
b110 != 0xFF 0 (virgin) 0 (virgin) Serial - -
b111 != 0xFF 0 (virgin) 0 (virgin) QSPI NAND Serial -
!= b100 != 0xFF Primary1 0 (virgin) Primary1 Serial -
!= b100 != 0xFF 0 (virgin) Secondary1 Secondary1 Serial -
!= b100 != 0xFF Primary1 Secondary1 Primary1 Secondary1 Serial
!= b100 0xFF x (don't care) x (don't care) Serial - -

1Primary and Secondary are fields stored in OTP. When the selected boot mode is Serial boot or Flash memory boot, the ROM code configures the interface as specified in the following sub-paragraphes, then it loads the FSBL image into internal memory and runs Secure boot.

3.2 Serial boot[edit]

The ROM code supports UART and USB serial interfaces.

When serial boot is selected, the ROM code scans in parallel all bootable UART instances and the USB OTG. When an activity is detected on an interface, the boot process goes on with this interface and the others are ignored.

Note that it is possible to disable USB or some instances of UARTs by blowing relevant fuses of boot source disable field in OTP. In all cases, i.e. whatever the USB is disable or not, HSE is mandatory.

3.2.1 USB Boot[edit]

The ROM code supports boot on USB OTG interface with HS PHY.

ROM code use OTG_HS_DP/DM signals available as additional functions on USB_DP2/DM2 pins.

USB OTG HS is clocked by a 48 MHz and a 60 MHz clock, generated by using HSE clock (from RCC).

The ROM code supports following HSE values:

8, 10, 12, 14, 16, 20, 24, 25, 26, 28, 32, 36, 40, 48 MHz

The ROM code selects which HSE it must use by following these steps:

  • if disable HSE frequency autodetection OTP bit is set to 1, the ROM code considers HSE=24Mhz.
  • If HSE value OTP field is 0b00 (default behaviour), then the ROM code autodetects HSE by using HSI clock (from RCC).
    • Recognized values are either 8, 10, 12, 14, 16, 20, 24, 32, 36, 28, 40, or 48 MHz.
    • If none of these value can be recognized, the ROM code considers that HSE = 24 MHz.
  • If HSE value OTP field is 0b01, then it considers that HSE=24 MHz
  • If HSE value OTP field is 0b10, then it considers that HSE=25 MHz
  • If HSE value OTP field is 0b11, then it considers that HSE=26 MHz
Warning white.png Warning
On STM32MP15x lines More info.png, in case of USB boot the application has to unmux the UART RX GPIO pins, especially if it wants to use a given UART RX signal on a different pin

3.2.2 UART Boot[edit]

The ROM code supports the following UART interfaces:

  • USART/UART instances:
    • USART2, USART3, UART4, UART5, USART6, UART7, UART8
(one start bit, 8 data bits, even parity bit and one stop bit).

Configuration:

By default the ROM code scans all UARTs listed above. This list may be reduced by blowing OTP fuses in UART instances disabling field.

In case of serial boot, the ROM code applies the following AFmuxes.
The ROM code first muxes only the RX pins of bootable UART instances and scans in parallel all these RX lines. When an activity is detected on an UART interface, the ROM code muxes the related TX, all others RX are unmuxed, and the boot process goes on with this interface.

Warning white.png Warning
On STM32MP15x lines More info.png, in case of USB boot the application has to unmux the UART RX GPIO pins, especially if it wants to use a given UART RX signal on a different pin
Signal GPIO pin and alternate function (AF) for
USART2 USART3 UART4 UART5 USART6 UART7 UART8
RX STM32MP15x lines More info.png only :
PA3 (AF07)
PB12 (AF08) STM32MP13x lines Warning.png :
PD8 (AF08)
STM32MP15x lines More info.png :
PB2 (AF08)
PB5 (AF12) PC7 (AF07) PF6 (AF07) PE0 (AF08)
TX STM32MP15x lines More info.png only :
PA2 (AF07)
PB10 (AF07) STM32MP13x lines Warning.png :
PD6 (AF06)
STM32MP15x lines More info.png :
PG11 (AF06)
PB13 (AF14) PC6 (AF07) PF7 (AF07) PE1 (AF08)

3.3 Flash memory boot[edit]

The ROM code supports the following Flash interfaces:

Please refer to STM32 MPU Flash mapping article to see the details about the mapping of each of these memories.

3.3.1 Boot from parallel / serial NAND[edit]

NAND contains n copies of FSBL in first valid blocks. If FSBL is using N blocks in the memory (N is usually 2 for a max 247KB FSBL with a memory having a 128KB block size), the ROM code scans blocks from the first and looks for FSBL in the first N consecutive valid block found.

The ROM code supports parallel (via FMC) NAND and serial (via QSPI) NAND.

Supported parallel NAND:

The ROM code supports parallel NAND with the following parameters.

Block size
(KBytes )
Page size
(KBytes)
Data width ECC1(bits and code)
128 2 8, 16 4 (bch), 8 (bch), 1 (hamming)
256 4 8, 16 4 (bch), 8 (bch), 1 (hamming)
512 4 8, 16 4 (bch), 8 (bch), 1 (hamming)
512 8 8, 16 4 (bch), 8 (bch), 1 (hamming)
1: The ROM code supports both parallel NAND with or without on-die ECC. The ECC given here is for NAND without on-die ECC.


Supported serial NAND:

The ROM code supports serial NAND with the following parameters.

Block size
(KBytes)
Page size
(KBytes)
128 2
256 4
512 4
512 8

The ROM code only supports serial NAND with embedded ECC.
Some serial NAND are multi-planes. The ROM code supports such multi-planes feature when OTP bit spinand needs plane select is set to 1.

Configuration:

In order to read a NAND flash, the ROM code needs to know the page size, the block size and the number of blocks. For parallel NAND it also needs to know the width and the number of ECC bits.

The ROM code detects NAND parameters storage location by checking nand param stored in otp OTP bit value.

If nand param stored in otp OTP bit value is equal to 0 (which is the default) then the NAND shall provide an ONFI compatible parameter table in which the ROM code looks for NAND parameters. “ONFI compatible ” means that a NAND provides get parameter feature that returns a table where at least parameters needed by ROM code are located at standard ONFI offsets. If nand param stored in otp OTP bit value is equal to 1, then ROM code looks for NAND parameter in OTP.

The number of ECC bits is a particular case, as it can be set by OTP even if nand param stored in otp is equal to 0. This is to allow the user to override the recommanded number of ECC bits given by the parameter table of an ONFI NAND.

Note that serial NAND are not ONFI compliant nor ONFI compatible :

  • on STM32MP13x lines Warning.png, that OTP bit value is not used for serial NAND and ROM code always looks for serial NAND parameters in OTP.
  • on STM32MP15x lines More info.png, that OTP bit value must be set to 1 for serial NAND to force ROM code to look for serial NAND parameters in OTP.


The following table shows which ONFI parameters may be used by the ROM code:

Parameter Table
Offset
Description Needed for
parallel NAND
Needed for
serial NAND
6 Supported features
(used to determine data width)
Yes No
80-83 Number of data bytes per page Yes No
84-85 Number of spare bytes per page Yes No
92-95 Number of pages per block Yes No
96-99 Number of blocks per unit Yes No
112 Number of ECC bits correctability Yes No

The following table list NAND parameters that may be stored in fuses:

Parameter STM32MP13x lines Warning.png STM32MP15x lines More info.png
bank1 bank2
Page size nand page size nand page size nand page size
Block size nand block size nand block size nand block size
Number of blocks nand block nb nand block nb nand block nb
Parallel NAND width fmc nand width fmc nand width fmc nand width
Parallel NAND ECC bits fmc ecc bit nb fmc ecc bit nb fmc ecc bit nb
Serial NAND needs plane select spinand needs plane select spinand needs plane select spinand needs plane select

On STM32MP13x lines Warning.png there are two banks of parameters. By default the ROM code looks for serial NAND configuration in bank1 and parallel NAND configuration in bank2. This setting can be reversed by blowing fuse NAND configuration distribution.

On STM32MP15x lines More info.png there is only one bank (bank1). Therefore only one non ONFI NAND can be used at a time.

In case of serial NAND boot, the ROM code applies the same AFmuxes as the ones for serial NOR.

In case of parallel NAND boot, the ROM code applies the following AFmuxes:

Signal GPIO pin and alternate function (AF) for
8 bits parallel NAND 16 bits parallel NAND
FMC_NOE PD4 (AF12)
FMC_NWAIT STM32MP13x lines Warning.png : PA9 (AF10)
STM32MP15x lines More info.png : PD6 (AF12)
FMC_NWE PD5 (AF12)
FMC_NCE PG9 (AF12)
FMC_ALE PD12 (AF12)
FMC_CLE PD11 (AF12)
FMC_D0 PD14 (AF12)
FMC_D1 PD15 (AF12)
FMC_D2 PD0 (AF12)
FMC_D3 PD1 (AF12)
FMC_D4 PE7 (AF12)
FMC_D5 PE8 (AF12)
FMC_D6 PE9 (AF12)
FMC_D7 PE10 (AF12)
FMC_D8 NA PE11 (AF12)
FMC_D9 NA PE12 (AF12)
FMC_D10 NA PE13 (AF12)
FMC_D11 NA PE14 (AF12)
FMC_D12 NA PE15 (AF12)
FMC_D13 NA STM32MP13x lines Warning.png : PB8 (AF12)
STM32MP15x lines More info.png : PD8 (AF12)
FMC_D14 NA PD9 (AF12)
FMC_D15 NA PD10 (AF12)

3.3.2 Boot from serial NOR[edit]

The NOR Flash contains two copies of FSBL. The ROM code tries to load and launch the first copy. In case of failure, it then tries to load the second copy.

The ROM code looks for FSBL1 at offset LBA0 and FSBL2 at offset LBA512.

It is possible to use NOR flash either in single or in dual mode. In dual mode two NOR flashes are connected to the two ports of the NOR interface, and the two memories are used in interlaced mode.

Configuration:

The ROM code uses SPI legacy mode MOSI/MISO only (i.e. uses only 2 pins IO0 and IO1 to transfer data).

The ROM code automatically detects single and dual modes.

In dual mode, BK1_nCS shall drive the two chip selects on board and BK2_nCS can remain unused or be used for other functions.

By default the ROM code applies the following AFmuxes:

Signal GPIO pin and alternate function (AF) for
serial NOR (single NOR) serial NOR (dual NOR)
QUADSPI_CLK PF10 (AF9)
QUADSPI_BK1_NCS STM32MP13x lines Warning.png : PB2 (AF9)
STM32MP15x lines More info.png : PB6 (AF10)
QUADSPI_BK1_IO0 PF8 (AF10)
QUADSPI_BK1_IO1 PF9 (AF10)
QUADSPI_BK2_IO0 NA PH2 (AF9)
QUADSPI_BK2_IO1 NA STM32MP13x lines Warning.png : PG10 (AF10)
STM32MP15x lines More info.png : PH3 (AF9)

These default AFmux can be overwritten by values defined in AFmux configuration OTP words.

QUADSPI CLK is set to HSI / 2 = 32Mhz

3.3.3 Boot from SD card[edit]

SD cards contain two versions of FSBL. The ROM code tries to load and launch the first copy. In case of failure, it then try to load the second copy.

The ROM code first looks for a GPT. If it finds it, it locates two FSBLs by looking for the two first GPT entries which name begins with "fsbl". If it cannot find a GPT, the ROM code looks for FSBL1 at offset LBA128 and FSBL2 at offset LBA640.

Configuration:

The ROM code uses only one data bit.

By default the ROM code uses SDMMC1 instance.

If SD card memory interface OTP field value is not equal to 0, the ROM code uses the value of this field (1 or 2) to determine which SDMMC interface to use.

By default the ROM code applies the following AFmuxes:

Signal GPIO pin and alternate function (AF) for
SD card
SDMMC1_CK PC12 (AF12)
SDMMC1_CMD PD2 (AF12)
SDMMC1_D0 PC8 (AF12)
SDMMC1_CDIR PB9 (AF11)
SDMMC1_D0DIR AFMUX OTP needed

SDMMC CK is set to HSI / 4 = 16 Mhz

If SD card memory interface OTP field value is not equal to 0, the ROM code does not apply these settings and instead uses the non default AFmux values defined by AFmux configuration OTP words.

Note that AFmux for SDMMC1_D0DIR has no default value and, if needed, must be applied via AFmux configuration OTP words.

3.3.4 Boot from eMMC[edit]

An eMMC™ contains two copies of FSBL in its two boot regions, but only one boot region is active at a time. The ROM code tries to load and launch the copy of FSBL contained in the active boot region.

Configuration:

The ROM code uses only one data bit.

By default the ROM code uses SDMMC2 instance.

If e•MMC™ memory interface OTP field value is not equal to 0, the ROM code uses the value of this field (1 or 2) to determine which SDMMC interface to use.

By default the ROM code applies following AFmuxes:

Signal GPIO pin and alternate function (AF) for
eMMC
SDMMC2_CK PE3 (AF09)
SDMMC2_CMD PG6 (AF10)
SDMMC2_D0 PB14 (AF09)

SDMMC CK is set to HSI / 4 = 16 Mhz

If e•MMC™ memory interface OTP field value is not equal to 0, the ROM code does not apply these settings and instead uses the non default AFmux values defined by AFmux configuration OTP words.

3.4 Developer (AKA "engineering") mode[edit]

Developer boot allows the user to connect a debugger on a opened device, so that it can load and run any software on either the CA7 or the CM4.

The ROM code detects developer boot when boot pins value is 0b100. The ROM code then simply enters an infinite loop after having:

  • re-opened CA7 secure debug,
  • started CM4 to run an infinite loop

Engineering boot is not available on closed devices (cf Closing the device)

3.5 Life cycle[edit]

The ROM code behavior is strongly linked to the device state in the product life cycle.

Alternate text
Device states
  • OPEN state: By default the device is in open state. Authentication is not mandatory. An authentication error does not prevent FSBL from beeing started.
  • CLOSED state: Once product secrets have been provisioned into the device, it can be closed by blowing closing bits fuses (see is closed on STM32MP13x lines Warning.png and is closed on STM32MP15x lines More info.png). On closed devices, authentication is mandatory. An authentication error prevents FSBL from beeing started.
  • RMA state: A closed device can be put once in RMA state and back again in CLOSED state. When the device is in RMA state, all ROM code features, except the one used to go back in closed state are disabled.

Notice that the secrets provisioning can be done by direct writing into the OTP registers or relying on the SSP (secure secrets provisioning) process, explained just below.

3.5.1 SSP (secure secrets provisioning)[edit]

The ROM code provides specific boot services allowing a user to store his own secrets in BSEC fuses in a secure way that guarantees the secrets confidentiality and integrity.

For details about the full Secure Secrets Provisioning (SSP) process please refer to AN5510: Overview of the secure secret provisioning (SSP) on STM32MP1 Series.

The ROM code uses the two following fuses to distinguish SSP boots:

  • SSP request (STM32MP13x lines Warning.png) or SSP request (STM32MP15x lines More info.png): when set to 1 it tells the ROM that SSP process is requested.
  • SSP success (STM32MP13x lines Warning.png) or SSP success (STM32MP15x lines More info.png) : when set to 1 it tells the ROM that SSP process is finished. Once this bit is set to 1, it is no more possible to request for SSP boots.

3.5.2 RMA (return merchandise authorization)[edit]

RMA boot allow a user to perform a Return Material Authorization (RMA).

  • RMA Unlock
The user can request to put a closed device in RMA state by configuring via Jtag the RMA unlock password in BSEC JTAG_IN register, which the ROM code compares after reset to the password stored in rma unlock passwd fuses.
  • RMA boot
When the device is in unlocked for RMA : DFT tests (tests of the silicon done during production) are possible again, but without possibility to access any sensitive data stored in fuses by the user. For full list of locked fuses, refer to the STM32MP15 Reference manuals, "OTP mapping (OTP)" section, swprlock3 column.
  • RMA Relock (STM32MP15x lines More info.png only)
The user can request to put a RMA device back in closed state by configuring via Jtag the RMA relock password in BSEC JTAG_IN register, which the ROM code compares after reset to the password stored in rma relock passwd fuses.
Info white.png Information
The RMA Unlock and RMA Relock sequences execution set two constraints on the platform:
  • The 5-pin standard JTAG interface must be used (2-pin SWD is not possible)
  • VDDCORE supply must not be power cycled during the reset that allows to come back in the ROM code, to keep BSEC JTAG_IN register content

4 Image loading[edit]

  • In Serial boot and Flash memory boot, the first stage boot loader (FSBL) binary is loaded from the selected boot device into the internal SRAM, following the memory mapping illustrated below:
Alternate text

5 Secure boot[edit]

The ROM code implements the authentication process as described in STM32 MPU ROM code secure boot, authentication processing chapter.

Alternate text
ROM code - secure boot

If the #Secure boot authentication is successful, then the ROM code stores the address of the boot context in r0 register and jumps to the FSBL entry point defined in image header.

5.1 FSBL authentication (ECDSA)[edit]

FSBL authentication relies on ECDSA verification algorithm, as described in Image signing and Image authentication chapters.

5.2 FSBL authentication key revocation[edit]

On STM32MP13x lines Warning.png, the ROM code allows the usage up to 8 signing keys and provide mechanism to revoke leaked keys. Details are described in Image signing and Image authentication chapters.

5.3 FSBL anti-rollback mechanism[edit]

The ROM code provides FSBL version anti-rollback mechanism to prevent launching of older versions of FSBL. See details in Image authentication chapters.

5.4 FSBL decryption (AES)[edit]

On STM32MP13x lines Warning.png, the ROM code provide FSBL decryption feature. Details are described in Image encryption and Image decryption chapters.

5.5 Cryptographic accelerators (ECDSA, AES)[edit]

On STM32MP13x lines Warning.png, the ROM code uses HASH, PKA, CRYP and SAES cryptographic accelerators.

  • HASH to perform SHA256 hashes.
  • PKA to perform ECDSA signature verification
  • CRYP or SAES to perform AES decryption of FSBL

On STM32MP15x lines More info.png, the ROM code uses HASH cryptographic accelerators, to perform SHA256 hashes.

6 Secondary core boot[edit]

6.1 On STM32MP13x lines Warning.png[edit]

Chip has only one Cortex-A7 core.

6.2 On STM32MP15x lines More info.png[edit]

Chip has two Cortex-A7 core. At reset, both cores of Cortex-A7 start and run the same instructions. The ROM code splits the execution flow so that only core0 runs the boot process. The secondary core of the Cortex-A7 is parked in an infinite loop, waiting for a signal from the application to go further. The signal mechanism is based on a secure SGI and the two backup registers MAGIC_NUMBER and BRANCH_ADDRESS.

To unpark the core1, the application running on core0 shall:

7 Wake up from low power modes[edit]

The ROM code manages exit from "wake up from low power modes" resulting in a reset.

7.1 On STM32MP13x lines Warning.png[edit]

Standby exit

The ROM code makes no distinction between Standby exit reset and Power On reset.

LPLV-Stop2 exit

The ROM code reads an address from BSEC SCRATCH register. This address may be any address except a ROM address. If the address is not in ROM range it jumps to it.

7.2 On STM32MP15x lines More info.png[edit]

In case of Standby exit reset, the ROM code proceeds as shown on following figure:

Alternate text
ROM code - wake up from low power modes

In such resets the Cortex®-M4 is always hold on reset, and only the ROM code on Cortex®-A7 is running. The behavior of the ROM code depends on value of bits MCU_BEN, MPU_BEN of RCC_MP_BOOTCR register.

Cortex®-M4 wake up

If bit MCU_BEN of RCC_MP_BOOTCR register is set to 1, the ROM proceeds to Cortex®-M4 software wake up.

The ROM code wakes up Cortex®-M4 by releasing it from its "hold on reset" state.

  • Cortex®-M4 software integrity check
Before releasing Cortex®-M4 the ROM code can use backup registers to recover the Cortex®-M4 software integrity check value and compare it to the one computed on RETRAM.
Note: if the device is closed, this check is mandatory.


Cortex®-A7 wake up

The Cortex®-A7 software wake up consists in processing Secure boot. The ROM will proceed to Cortex®-A7 software wake up in three cases:

  • If M4 software wake up is not required (i.e. MCU_BEN=0)
  • If M4 software wake up is required (i.e. MCU_BEN=1) but fails,
  • If M4 software wake up is required (i.e. MCU_BEN=1), is processed successfully and MPU_BEN is also set to 1


Cortex®-A7 returns to CStandby low power mode

If Cortex®-M4 software wake up is required (i.e. MCU_BEN=1), is processed successfully and MPU_BEN is set to 0, the ROM enters the Cortex®-A7 in CStandby low power modes.

8 Secure services export[edit]

8.1 On STM32MP13x lines Warning.png[edit]

The ROM code does not export any service for the application.

8.2 On STM32MP15x lines More info.png[edit]

The ROM code exports authentication services to the following stages of the STM32MP15 secure boot, starting with FSBL.

9 Memory mapping[edit]

The ROM code memory mapping is illustrated in the Image loading paragraph.

9.1 On STM32MP13x lines Warning.png[edit]

The boot context (see boot_api_context_t structure in plat/st/stm32mp1/include/boot_api.h with STM32MP13 compilation flag) is in the first 512 bytes of SRAM2. It contains information on boot process (such as the selected boot device) and pointers to the ROM code services (used for secure boot authentication).

9.2 On STM32MP15x lines More info.png[edit]

The boot context (see boot_api_context_t structure in plat/st/stm32mp1/include/boot_api.h with STM32MP15 compilation flag) is in the first 512 bytes of SYSRAM. It contains information on boot process (such as the selected boot device) and pointers to the ROM code services (used for secure boot authentication).

10 System and peripheral registers modification after boot sequence[edit]

10.1 On STM32MP13x lines Warning.png[edit]

See STM32MP13 registers modifications after boot sequence

10.2 On STM32MP15x lines More info.png[edit]

See STM32MP15 registers modifications after boot sequence

11 Debug and error cases[edit]

11.1 Debug and Error messages[edit]

  • PA13 management
The ROM code uses PA13 pin to communicate some status. On STMicroelectronics boards, PA13 is connected to the red LED, as explained in LEDs and buttons on STM32 MPU boards article.
  • in case of boot failure, the PA13 pin is set to low open-drain (i.e. red LED will light bright).
  • During UART/USB boot, the PA13 pin will toggle open-drain at a rate of about 5 Hz until a connection is started (i.e. red LED will blink fast).
  • With BOOT[2:0] = 0b100 (engineering boot, used for specific debug), PA13 will toggle opendrain at a rate of about 5 kHz (i.e. red LED will light weak).
  • In all other cases, the PA13 is kept in it’s reset value, i.e. high-z until software setting.


  • Traces
  • During its execution, the ROM writes binary traces in memory.
Traces can be downloaded and analysed with the ROM trace analyser tool.
  • In case of internal blocking error, the ROM code writes a uart log error at 9600bauds to PA13 pin.

11.2 Common debug and error cases[edit]

  • Memory Boot failure
Secure boot flow always enters the serial boot loop during which the Error LED is blinking. Therefore, observing such blinking when Memory boot is required indicates that Memory boot failed.
  • Security issue
If the bootrom encounters a security issue, it stops immediately the secure boot and sets the Error LED to light bright.