STMicroelectronics STM32MP151A, STM32MP151C, STM32MP151D, STM32MP151F, STM32MP153A Datasheet

STM32MP151x STM32MP153x STM32MP157x

Errata sheet

STM32MP151x/3x/7x device errata

Applicability

This document applies to the part numbers of STM32MP151x/3x/7x devices and the device variants as stated in this page.

It gives a summary and a description of the device errata, with respect to the device datasheet and reference manual RM0441
for STM32MP151x, RM0442 for STM32MP153x, and RM0436 for STM32MP157x.

Deviation of the real device behavior from the intended device behavior is considered to be a device limitation. Deviation of the
description in the reference manual or the datasheet from the intended device behavior is considered to be a documentation
erratum. The term “errata” applies both to limitations and documentation errata.

Table 1. Device summary

Reference Part numbers

STM32MP151x STM32MP151A, STM32MP151C, STM32MP151D, STM32MP151F

STM32MP153x STM32MP153A, STM32MP153C, STM32MP153D, STM32MP153F

STM32MP157x STM32MP157A, STM32MP157C, STM32MP157D, STM32MP157F

Table 2. Device variants

Reference

STM32MP151x/3x/7x

STM32MP151x/3x/7x Z 0x2001

1. Refer to the device datasheet for how to identify this code on different types of package.

2. REV_ID[15:0] bitfield of DBGMCU_IDC register.

Device marking

B 0x2000

Silicon revision codes

(1)

REV_ID

(2)

ES0438 - Rev 6 - February 2021

For further information contact your local STMicroelectronics sales office.

www.st.com

1 Summary of device errata

The following table gives a quick reference to the STM32MP151x/3x/7x device limitations and their status:

A = limitation present, workaround available

N = limitation present, no workaround available

P = limitation present, partial workaround available

“-” = limitation absent

Applicability of a workaround may depend on specific conditions of target application. Adoption of a workaround
may cause restrictions to target application. Workaround for a limitation is deemed partial if it only reduces the
rate of occurrence and/or consequences of the limitation, or if it is fully effective for only a subset of instances on
the device or in only a subset of operating modes, of the function concerned.

Table 3. Summary of device limitations

Function Section Limitation

Memory locations might be accessed speculatively due to instruction
fetches when HCR.VM is set

VDIV or VSQRT instructions might not complete correctly when very short
ISRs are used

Store immediate overlapping exception return operation might vector to
incorrect interrupt

TPIU fails to output sync after the pattern generator is disabled in Normal
mode

Limitation of aclk/hclk5/hclk6 to 200 MHz when used as SDMMC1/2 kernel
clock

RCC security settings for Cortex-M4 access are not kept upon wake up
from Standby

Wakeup pin flags cleared at Standby mode exit with MCU_BEN high and
MPU_BEN low

Boundary scan SAMPLE/PRELOAD behavior not compliant with
IEE1149.1

Arm Cortex-A7

core

Arm Cortex-M4

core

System

2.1.1

2.1.2 Cache maintenance by set/way operations can execute out of order A A

2.1.3 PMU events 0x07, 0x0C, and 0x0E do not increment correctly N N

2.1.4 PMU event counter 0x14 does not increment correctly A A

2.1.5 Exception mask bits are cleared when an exception is taken in Hyp mode N N

2.2.1 Interrupted loads to SP can cause erroneous behavior A A

2.2.2

2.2.3

2.3.1

2.3.2 Serial-wire multi-drop debug not supported N N

2.3.3 HSE external oscillator required in some LTDC use cases P P

2.3.4 RCC cannot exit Stop and LP-Stop modes A A

2.3.5 Incorrect reset of glitch-free kernel clock switch P P

2.3.6

2.3.7 Overconsumption in Standby with on‑board 1.8 V regulator bypassed A -

2.3.8 eMMC boot timeout too short A -

2.3.9 Cortex-M4 cannot use I/O compensation on Standby mode exit A A

2.3.10 Missed wake-up events in CSTANDBY N -

2.3.12

2.3.13

2.3.14 Boundary scan data unduly sampled on TCK falling edge A A

2.3.15

STM32MP151x STM32MP153x STM32MP157x

Summary of device errata

Status

Rev.BRev.

Z

A A

A A

A A

A A

P P

N N

N N

A A

ES0438 - Rev 6

page 2/45

STM32MP151x STM32MP153x STM32MP157x

Summary of device errata

Status

Function Section Limitation

2.3.16 Boot with a specific combination of NAND Flash memories fails

2.3.17 Boot with 1-bit error correction on SLC NAND Flash memory fails A -

System

DDRPHYC

GPIO 2.5.1

DMA 2.6.1 USART/UART/LPUART DMA transfer abort D D

DMAMUX

QUADSPI 2.8.1 Memory-mapped read of last memory byte fails P P

ADC

VREFBUF

DAC

DTS 2.12.1 Mode using PCLK & LSE (REFCLK_SEL = 1) should not be used P P

DSI 2.13.1

TIM

LPTIM

2.3.18 Boot fails if eMMC does not answer the first command N -

2.3.19 DLYB limits SDMMC throughput N N

2.3.20 LSE CSS cannot be used in VBAT state N N

2.3.21 Wrong value in Coresight M4 ROM table A A

2.4.1 DDRPHYC overconsumption upon reset or Standby mode exit A -

2.4.2

2.4.3

2.7.1 SOFx not asserted when writing into DMAMUX_CFR register N N

2.7.2 OFx not asserted for trigger event coinciding with last DMAMUX request N N

2.7.3 OFx not asserted when writing into DMAMUX_RGCFR register N N

2.7.4

2.9.1

2.9.2

2.9.3

2.9.4 ADC_AWDy_OUT reset by non-guarded channels A A

2.9.5 ADC ANA0/ANA1 resolution limited when Gigabit Ethernet is used P P

2.9.6 ADC missing codes in differential 16-bit static acquisition P P

2.11.1 VREFBUF Hold mode cannot be used N N

2.11.2 Overshoot on VREFBUF output A A

2.10.1

2.10.2

2.15.1

2.15.2 Consecutive compare event missed in specific conditions N N

2.15.3 Output compare clear not working with external counter reset P P

2.16.1 Device may remain stuck in LPTIM interrupt when entering Stop mode A A

DDR_CLK jitter out of JEDEC requirement for 32-bit LPDDR2/LPDDR3 at
low device Tj

Data corruption at low device Tj combined with low 32-bit LPDDR2/
LPDDR3 I/O supply voltage

GPIO assigned to DAC cannot be used in output mode when the DAC
output is connected to on-chip peripheral

Wrong input DMA request routed upon specific DMAMUX_CxCR register
write coinciding with synchronization event

New context conversion initiated without waiting for trigger when writing
new context in ADC_JSQR with JQDIS = 0 and JQM = 0

Two consecutive context conversions fail when writing new context in
ADC_JSQR just after previous context completion with JQDIS = 0 and
JQM = 0

Unexpected regular conversion when two consecutive injected
conversions are performed in Dual interleaved mode

Invalid DAC channel analog output if the DAC channel MODE bitfield is
programmed before DAC initialization

DMA underrun flag not set when an internal trigger is detected on the
clock cycle of the DMA request acknowledge

DSI PHY compliant with MIPI DPHY v0.81 specification, not with DSI PHY
v1.0

One-pulse mode trigger not detected in master-slave reset + trigger
configuration

Rev.BRev.

N -

A A

A A

N N

A A

A A

A A

A A

A A

N N

N -

P P

Z

ES0438 - Rev 6

page 3/45

STM32MP151x STM32MP153x STM32MP157x

Function Section Limitation

LPTIM

RTC and TAMP

I2C

USART

SPI

FDCAN

OTG_HS 2.22.1

ETH

2.16.2 Device may remain stuck in LPTIM interrupt when clearing event flag

2.16.3 LPTIM events and PWM output are delayed by 1 kernel clock cycle

2.17.1 Incorrect version register N N

2.17.2 Calendar initialization may fail in case of consecutive INIT mode entry A A

2.17.3 Alarm flag may be repeatedly set when the core is stopped in debug N N

2.17.4

2.17.5 REFCKON write protection associated to INIT KEY instead of CAL KEY A A

2.17.6 Tamper flag not set on LSE failure detection N N

2.18.1

2.18.2 Spurious bus error detection in master mode A A

2.18.3 Spurious master transfer upon own slave address match P P

2.18.4 OVR flag not set in underrun condition N N

2.18.5 Transmission stalled after first byte transfer A A

2.19.1 Anticipated end-of-transmission signaling in SPI slave mode A A

2.19.2 Data corruption due to noisy receive line N N

2.20.1 Master data transfer stall at system clock much faster than SCK A A

2.20.2 Corrupted CRC return at non-zero UDRDET setting P P

2.20.3 TXP interrupt occurring while SPI disabled A A

2.20.4 Possible corruption of last-received data depending on CRCSIZE setting A A

2.21.1 Desynchronization under specific condition with edge filtering enabled A A

2.21.2

2.21.3 DAR mode transmission failure due to lost arbitration A A

2.23.1 Incorrect L4 inverse filtering results for corrupted packets N N

2.23.2

2.23.3 Spurious receive watchdog timeout interrupt A A

2.23.4 Incorrect flexible PPS output interval under specific conditions A A

2.23.5 Packets dropped in RMII 10Mbps mode due to fake dribble and CRC error A A

2.23.6 ARP offload function not effective A A

2.23.7 Slight imbalance of AV traffic CBS bandwidth allocation N N

2.23.8 Spurious checksum error upon MTL pending Tx queue flush N N

2.23.9

2.23.10 DMA spurious state upon AXI DMA slave bus error P P

A tamper event fails to trigger timestamp or timestamp overflow events
during a few cycles after clearing TSF

Wrong data sampling when data setup time (tSU;DAT) is shorter than one
I2C kernel clock period

Tx FIFO messages inverted under specific buffer usage and priority
setting

Host packet transmission may hang when connecting through a hub to a
low-speed device

Rx DMA may fail to recover upon DMA restart following a bus error, with
Rx timestamping enabled

Bus error coinciding with start-of-packet corrupts MAC-generated packet
transmission

Summary of device errata

Status

Rev.BRev.

Z

P P

N N

P P

A A

N N

A A

N N

ES0438 - Rev 6

The following table gives a quick reference to the documentation errata.

page 4/45

STM32MP151x STM32MP153x STM32MP157x

Table 4. Summary of device documentation errata

Function Section Documentation erratum

System 2.3.11 SSCG option is not available on PLL3 and PLL4

HASH

2.14.1 Superseded suspend sequence for data loaded by DMA

2.14.2 Superseded suspend sequence for data loaded by the CPU

Summary of device errata

ES0438 - Rev 6

page 5/45

STM32MP151x STM32MP153x STM32MP157x

Description of device errata

2 Description of device errata

The following sections describe limitations of the applicable devices with Arm® core and provide workarounds if
available. They are grouped by device functions.

Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

2.1 Arm Cortex-A7 core

Reference manual and errata notice for the Arm® Cortex®-A7 core revision r0p5-REVIDR=0x01 is available from
http://infocenter.arm.com.

2.1.1 Memory locations might be accessed speculatively due to instruction fetches when HCR.VM is

set

This limitation is registered under Arm ID number 844169 and classified into “Category B”. Its impact to the device
is minor.

Description

The ARMv7 architecture requires that when all associated stages of translation are disabled for the current
privilege level, memory locations are only accessed due to instruction fetches within the same or next 4 KB region
as an instruction which has been or will be fetched due to sequential execution. In the conditions detailed below,
the Cortex‑A7 processor might access other locations speculatively due to instruction fetches.

The unwanted speculative instruction fetches may occur when the following conditions are all met:

1. The processor must be executing at PL2 or Secure PL1.

2. Address translation is disabled for the current exception level (by clearing the appropriate SCTLR.M or

HSCTLR.M bit).

3. The HCR.VM bit is set.

As the HCR.VM is reset low, this issue will not manifest during boot code.

Workaround

This issue is most likely to arise in powerdown code, if PL2 or secure PL1 software disables address translation
before the core is powered down.

To work around this erratum, software should ensure that HCR.VM is cleared before disabling address translation
at PL2 or Secure PL1.

2.1.2 Cache maintenance by set/way operations can execute out of order

This limitation is registered under Arm ID number 814220 and classified into “Category B”. Its impact to the device
is limited.

Description

The ARM v7 architecture states that all cache and branch predictor maintenance operations that do not specify an
address execute in program order, relative to each other. However, because of this erratum, an L2 set/way cache
maintenance operation can overtake an L1 set/way cache maintenance operation.

Code that intends to clean dirty data from L1 to L2 and then from L2 to L3 using set/way operations might not
behave as expected. The L2 to L3 operation might happen first and result in dirty data remaining in L2 after the L1
to L2 operation has completed.

If dirty data remains in L2 then an external agent, such as a DMA agent, might observe stale data.

If the processor is reset or powered-down while dirty data remains in L2 then the dirty data will be lost.

ES0438 - Rev 6

page 6/45

STM32MP151x STM32MP153x STM32MP157x

Arm Cortex-A7 core

The failure occurs when the following conditions are all met:

1. A CPU performs an L1 DCCSW or DCCISW operation.

2. The targeted L1 set/way contains dirty data.

3. Before the next DSB, the same CPU executes an L2 DCCSW or DCCISW operation while the L1 set/way

operation is in progress.

4. The targeted L2 set/way is within the group of L2 set/ways that the dirty data from L1 can be allocated to.

If the above conditions are met then the L2 set/way operation can take effect before the dirty data from L1 has
been written to L2.

Note: Conditions (3) and (4) are not likely to be met concurrently when performing set/way operations on the entire

L1 and L2 caches. This is because cache maintenance code is likely to iterate through sets and ways in a
consistent ascending or consistent descending manner across cache levels, and to perform all operations on
one cache level before moving on to the next cache level. This means that, for example, cache maintenance
operations on L1 set 0 and L2 set 0 will be separated by cache maintenance operations for all other sets in the
L1 cache. This creates a large window for the cache maintenance operations on L1 set 0 to complete.

Workaround

Correct ordering between set/way cache maintenance operations can be forced by executing a DSB before
changing cache levels.

2.1.3 PMU events 0x07, 0x0C, and 0x0E do not increment correctly

This limitation is registered under Arm ID number 809719 and classified into “Category C”. Its impact to the device
is minor.

Description

The Cortex-A7 processor implements version 2 of the Performance Monitor Unit architecture (PMUv2). The PMU
can gather statistics on the operation of the processor and memory system during runtime. This event information
can be used when debugging or profiling code.

The PMU can be programmed to count architecturally executed stores (event 0x07), software changes of the PC
(event 0x0C), and procedure returns (event 0x0E). However, because of this erratum, these events do not fully
adhere to the descriptions in the PMUv2 architecture.

As a result of this limitation, the information returned by PMU counters that are programmed to count events
0x07, 0x0C, or 0x0E might be misleading when debugging or profiling code executed on the processor.

The error occurs when the following conditions are met:

Either:

1. A PMU counter is enabled and programmed to count event 0x07. That is: instruction architecturally

executed, condition code check pass, store.

2. A PLDW instruction is executed.

If the above conditions are met, the PMUv2 architecture specifies that the counter for event 0x07 does not
increment. However, the counter does increment.

Or:

1. A PMU counter is enabled and programmed to count event 0x0C. That is: instruction architecturally

executed, condition code check pass, software change of the PC.

2. An SVC, HVC, or SMC instruction is executed.

If the above conditions are met, the PMUv2 architecture specifies that the counter for event 0x0C increments.
However, the counter does not increment.

ES0438 - Rev 6

page 7/45

STM32MP151x STM32MP153x STM32MP157x

Arm Cortex-A7 core

Or:

1. A PMU counter is enabled and programmed to count event 0x0E. That is: instruction architecturally

executed, condition code check pass, procedure return.

2. One of the following instructions is executed:

a. MOV PC, LR

b. ThumbEE LDMIA R9!, {?, PC}

c. ThumbEE LDR PC, [R9], #offset

d. BX Rm, where Rm != R14

e. LDM SP, {?, PC}

If the above conditions are met, the PMUv2 architecture specifies that the counter for event 0x0E increments for
(a), (b), (c) and does not increment for (d) and (e). However, the counter does not increment for (a), (b), (c) and
increments for (d) and (e).

Example:

The processor should execute interrupt handler C, and on completion of handler C should execute the handler
for B. If the conditions above are met, then this erratum results in the processor erroneously clearing the pending
state of interrupt C, and then executing the handler for B twice. The first time the handler for B is executed it
will be at interrupt C's priority level. If interrupt C is pended by a level-based interrupt which is cleared by C's
handler then interrupt C will be pended again once the handler for B has completed and the handler for C will be
executed.

As the STM32 interrupt C is level based, then this interrupt will eventually become re-pending and subsequently
be handled.

Workaround

None.

2.1.4 PMU event counter 0x14 does not increment correctly

This limitation is registered under Arm ID number 805420 and classified into “Category C”. Its impact to the device
is minor.

Description

The Cortex-A7 MPCore processor implements version 2 of the Performance Monitor Unit architecture (PMUv2).
The PMU can gather statistics on the operation of the processor and memory system during runtime. This event
information can be used when debugging or profiling code. When a PMU counter is programmed to count L1
instruction cache accesses (event 0x14), the counter should increment on all L1 instruction cache accesses.

This limitation has the following implications:

1. If SCR.{AW, FW} is set to 0 then the clearing of corresponding bit CPSR.{A, F} to 0 has no effect. The value

of CPSR.{A, F} is ignored.

2. A PMU counter is enabled and programmed to count L1 instruction cache accesses (event 0x14).

3. Cacheable instruction fetches miss in the L1 instruction cache.

If the above conditions are met, the event counter will not increment.

Workaround

To obtain a better approximation for the number of L1 instruction cache accesses, enable a second PMU counter
and program it to count instruction fetches that cause linefills (event 0x01). Add the value returned by this counter
to the value returned by the L1 instruction access counter (event 0x14). The result of the addition is a better
indication of the number of L1 instruction cache accesses.

2.1.5 Exception mask bits are cleared when an exception is taken in Hyp mode

This limitation is registered under Arm ID number 804069 and classified into “Category C”. Its impact to the device
is minor.

ES0438 - Rev 6

page 8/45

STM32MP151x STM32MP153x STM32MP157x

Arm Cortex-M4 core

Description

The Cortex-A7 processor implements the ARM Virtualization Extensions and the ARM Security Extensions.
Exceptions can be routed to Monitor mode by setting SCR.{EA, FIQ, IRQ} to 1. Exceptions can be masked by
setting corresponding bit CPSR.{A, I, F} to 1.

The ARMv7-A architecture states that an exception taken in Hyp mode does not change the value of the mask
bits for exceptions routed to Monitor mode. However, because of this erratum, the corresponding mask bits will be
cleared to 0.

The error occurs when the following conditions are met:

1. One or more exception types are routed to Monitor mode by setting one or more of SCR.{EA, FIQ, IRQ} to 1.

2. The corresponding exception types are masked by setting the corresponding CPSR.{A, F, I} bits to 1.

3. Any exception is taken in Hyp mode.

If the above conditions are met then the exception mask bit CPSR.{A, F, I} is cleared to 0 for each exception type
that meets conditions (1) and (2). The affected mask bits are cleared together regardless of the exception type in
condition (3).

The implications of this erratum are:

• If SCR.{AW, FW} is set to 0 then the clearing of corresponding bit CPSR.{A, F} to 0 has no effect. The value

of CPSR.{A, F} is ignored.

• Otherwise, when CPSR.{A, F, I} is set to 1, Secure code cannot rely on CPSR.{A, F, I} remaining set to 1. An

exception that should be masked might be routed to Monitor mode.

The impact of this limitation is considered to be minor as it is expected that the users will:

1. set SCR.{AW, FW} to 0 when SCR.{EA, FIQ} is set to 1.

2. set SCR.IRQ to 0.

Workaround

None.

2.2

Arm Cortex-M4 core

Errata notice for the Arm® Cortex®-M4 core revision r0p1 is available from http://infocenter.arm.com.

2.2.1 Interrupted loads to SP can cause erroneous behavior

This limitation is registered under Arm ID number 752770 and classified into “Category B”. Its impact to the device
is minor.

Description

If an interrupt occurs during the data-phase of a single word load to the stack-pointer (SP/R13), erroneous
behavior can occur. In all cases, returning from the interrupt will result in the load instruction being executed an
additional time. For all instructions performing an update to the base register, the base register will be erroneously
updated on each execution, resulting in the stack-pointer being loaded from an incorrect memory location.

The affected instructions that can result in the load transaction being repeated are:

• LDR SP, [Rn],#imm

• LDR SP, [Rn,#imm]!

• LDR SP, [Rn,#imm]

• LDR SP, [Rn]

• LDR SP, [Rn,Rm]

The affected instructions that can result in the stack-pointer being loaded from an incorrect memory address are:

• LDR SP,[Rn],#imm

• LDR SP,[Rn,#imm]!

As compilers do not generate these particular instructions, the limitation is only likely to occur with hand-written
assembly code.

ES0438 - Rev 6

page 9/45

STM32MP151x STM32MP153x STM32MP157x

Arm Cortex-M4 core

Workaround

Both issues may be worked around by replacing the direct load to the stack-pointer, with an intermediate load to a
general-purpose register followed by a move to the stack-pointer.

2.2.2 VDIV or VSQRT instructions might not complete correctly when very short ISRs are used

This limitation is registered under Arm ID number 776924 and classified into “Category B”. Its impact to the device
is limited.

Description

The VDIV and VSQRT instructions take 14 cycles to execute. When an interrupt is taken a VDIV or VSQRT
instruction is not terminated, and completes its execution while the interrupt stacking occurs. If lazy context save
of floating point state is enabled then the automatic stacking of the floating point context does not occur until a
floating point instruction is executed inside the interrupt service routine.

Lazy context save is enabled by default. When it is enabled, the minimum time for the first instruction in the
interrupt service routine to start executing is 12 cycles. In certain timing conditions, and if there is only one or two
instructions inside the interrupt service routine, then the VDIV or VSQRT instruction might not write its result to the
register bank or to the FPSCR.

The failure occurs when the following condition is met:

1. The floating point unit is enabled

2. Lazy context saving is not disabled

3. A VDIV or VSQRT is executed

4. The destination register for the VDIV or VSQRT is one of s0 - s15

5. An interrupt occurs and is taken

6. The interrupt service routine being executed does not contain a floating point instruction

7. Within 14 cycles after the VDIV or VSQRT is executed, an interrupt return is executed

A minimum of 12 of these 14 cycles are utilized for the context state stacking, which leaves 2 cycles for
instructions inside the interrupt service routine, or 2 wait states applied to the entire stacking sequence (which
means that it is not a constant wait state for every access).

In general, this means that if the memory system inserts wait states for stack transactions (that is, external
memory is used for stack data), then this erratum cannot be observed.

The effect of this erratum is that the VDIV or VQSRT instruction does not complete correctly and the register bank
and FPSCR are not updated, which means that these registers hold incorrect, out of date, data.

Workaround

A workaround is only required if the floating point unit is enabled. A workaround is not required if the stack is in
external memory.

There are two possible workarounds:

• Disable lazy context save of floating point state by clearing LSPEN to 0 (bit 30 of the FPCCR at address

0xE000EF34).

• Ensure that every interrupt service routine contains more than 2 instructions in addition to the exception

return instruction.

2.2.3 Store immediate overlapping exception return operation might vector to incorrect interrupt

This limitation is registered under Arm ID number 838869 and classified into “Category B (rare)”. Its impact to the
device is minor.

Description

The core includes a write buffer that permits execution to continue while a store is waiting on the bus. Under
specific timing conditions, during an exception return while this buffer is still in use by a store instruction, a late
change in selection of the next interrupt to be taken might result in there being a mismatch between the interrupt
acknowledged by the interrupt controller and the vector fetched by the processor.

ES0438 - Rev 6

page 10/45

STM32MP151x STM32MP153x STM32MP157x

System

The failure occurs when the following condition is met:

1. The handler for interrupt A is being executed.

2. Interrupt B, of the same or lower priority than interrupt A, is pending.

3. A store with immediate offset instruction is executed to a bufferable location.

– STR/STRH/STRB <Rt>, [<Rn>,#imm]

– STR/STRH/STRB <Rt>, [<Rn>,#imm]!

– STR/STRH/STRB <Rt>, [<Rn>],#imm

4. Any number of additional data-processing instructions can be executed.

5. A BX instruction is executed that causes an exception return.

6. The store data has wait states applied to it such that the data is accepted at least two cycles after the BX is

executed.

– Minimally, this is two cycles if the store and the BX instruction have no additional instructions between

them.

– The number of wait states required to observe this erratum needs to be increased by the number of

cycles between the store and the interrupt service routine exit instruction.

7. Before the bus accepts the buffered store data, another interrupt C is asserted which has the same or lower

priority as A, but a greater priority than B.

Example:

The processor should execute interrupt handler C, and on completion of handler C should execute the handler
for B. If the conditions above are met, then this erratum results in the processor erroneously clearing the pending
state of interrupt C, and then executing the handler for B twice. The first time the handler for B is executed it
will be at interrupt C's priority level. If interrupt C is pended by a level-based interrupt which is cleared by C's
handler then interrupt C will be pended again once the handler for B has completed and the handler for C will be
executed.

As the STM32 interrupt C is level based, it eventually becomes pending again and is subsequently handled.

Workaround

For software not using the memory protection unit, this erratum can be worked around by setting DISDEFWBUF
in the Auxiliary Control Register.

In all other cases, the erratum can be avoided by ensuring a DSB occurs between the store and the BX
instruction. For exception handlers written in C, this can be achieved by inserting the appropriate set of intrinsics
or inline assembly just before the end of the interrupt function, for example:

ARMCC:

...
__schedule_barrier();
__asm{DSB};
__schedule_barrier();
}

GCC:

...
__asm volatile ("dsb 0xf":::"memory");
}

2.3

System

2.3.1 TPIU fails to output sync after the pattern generator is disabled in Normal mode

ES0438 - Rev 6

Description

The TPIU includes a pattern generator that can be used by external tool to determine the operating behavior of
the trace port and timing characteristics. This pattern generator includes a mode that transmits the test pattern for
a specified number of cycles, and then reverts to transmitting normal trace data.

page 11/45

STM32MP151x STM32MP153x STM32MP157x

System

When the TPIU is configured to operate in Normal mode (FFCR.EnFCont=0), the synchronization sequence that
is required between the test pattern and the trace data is not generated. Synchronization will be generated at a
later time, as determined by the synchronization counter.

Conditions:

The following conditions must all occur:

• The TPIU is configured in normal mode, FFCR.EnFCont==0

• The TPIU is configured with the formatter enabled, FFCR.EnFTC==1

• The pattern generator is enabled in timed mode, Current_test_pattern_mode.PTIMEEN==1

Implications:

The timed mode of the TPIU is intended to permit the TPIU to transition between an initial synchronization
sequence using the pattern generator and functional mode without any further programming intervention. If the
synchronization sequence is not generated at the end of the test pattern, the trace port analyzer is unlikely to
be able to capture the start of the trace stream correctly. Synchronization will be correctly inserted based on the
value configured in the FSCR, once the specified number of frames of trace data have been output.

Workaround

Workaround requires software interaction to detect the completion of the test pattern sequence. In addition,
any trace data present at the input to the TPIU is lost whilst the pattern generator is active. Any trace data
present in the input to the TPIU before the formatter is re-enabled (and synchronization generated) will not be
de-compressible.

1. After enabling the pattern generator, set FFCR.StopOnFl==1 and FFCR.FOnMan==1.

2. Poll FFSR.FtStopped until 1 is read

3. Set FFCR.EnFTC==1

2.3.2 Serial-wire multi-drop debug not supported

Description

The target instance bitfield TINSTANCE[3:0] of the DP_DLPIDR debug port data link protocol identification
register is frozen to 0, which prevents the debug of multiple instances of the same function connected on same
SWD bus.

Workaround

None.

2.3.3 HSE external oscillator required in some LTDC use cases

Description

Due to capacitive load on the LTDC pins, the LTDC used at high or very high speed (OSPEEDR ≥ 1) may impact
the on-chip HSE crystal oscillator clock, which then could lead to a deterioration of USB HS eye diagram.

Note: This does not apply when the LTDC is internally connected to the DSI host, even at high clock frequencies up to

90 MHz, as it does not drive pins.

Workaround

If using the USB HS interface, avoid using the on‑chip HSE oscillator in the use cases summarized in the table.
Instead, get the clock from an external oscillator connected to the HSE pins, as indicated in the table (mandatory
or recommended).

ES0438 - Rev 6

page 12/45

STM32MP151x STM32MP153x STM32MP157x

Table 5. Use of external oscillator on HSE pins

System

LTDC connected to Conditions

3 V < VDD< 3.6 V

f

up to 74.25 MHz (1280x720 at 60 fps)

pixel

OSPEEDR = 1 for all LTDC signals

USB HS used

HDMI bridge close to

HDMI bridge

Parallel LCD load < 30 pf

the device

load ~15 pf

1.7 V < VDD< 2 V

f

up to 74.25 MHz

pixel

Duty cycle = 40 %

0.1 VDD < VIN < 0.9 V

OSPEEDR = 3 for LCD_CLK

OSPEEDR = 2 for all other LTDC signals

3 V < VDD< 3.6 V

f

up to 90 MHz (1366x768 at 60 fps)

pixel

OSPEEDR = 2 for LCD_CLK

OSPEEDR = 1 for all other LTDC signals

USB HS used

3 V < VDD< 3.6 V

f

up to 48 MHz (800x600 at 60 fps)

pixel

OSPEEDR = 1 for LCD_CLK

OSPEEDR = 0 for all other LTDC signals

1.7 V < VDD< 2 V

f

up to 69 MHz (1024x768 at 60 fps)

pixel

Duty cycle = 40 %

0.1 VDD < VIN < 0.9 V

OSPEEDR = 3 for LCD_CLK

OSPEEDR = 2 for all other LTDC signals

External oscillator on

HSE

Mandatory

Recommended

DD

Mandatory

Recommended

DD

2.3.4 RCC cannot exit Stop and LP-Stop modes

Description

When trying to exit Stop or LP-Stop mode, the handshake mechanism between PWRCTRL and RCC can be
wrong due to a too short internal state within the RCC state machine. In extreme case, the PWRCTRL does not
see the RCC signal, thus causing the whole system going to Stop or LP-Stop mode again, respectively.

Workaround

Set the PWRLP_DLY[21:0] bitfield of the RCC_PWRLPDLYCR register to a value equal to or greater than 0x4.

Note: This register is designed to handle LP-Stop mode, but it can also be used in the present case for Stop mode.

2.3.5 Incorrect reset of glitch-free kernel clock switch

Description

The activation of NRST (by external signal, internal watchdog or software) may not properly reset the glitch-free
clock switches inside the RCC.

ES0438 - Rev 6

page 13/45

STM32MP151x STM32MP153x STM32MP157x

As a consequence, the peripheral kernel clock previously used by the application remains selected. If not enabled
again (by default or by SW), there is no kernel clock present on the related peripheral and the BootROM hangs.

Note: USB boot is usually not affected as the application always uses the same clocking scheme depending on

HSE crystal frequency choice. For example, there is no issue for HSE = 24 MHz as hse_ker_ck is used for
OTG clocking. Other peripherals, such as LPTIM, USART, and I2C, should work without care if the previous
application clock is enabled again to ensure that the clock switch is not stuck.

Workaround

Use one of the following measures:

1. By hardware, ensure that the V

DDCORE

– With STPMIC1

By default, a power cycle on VDDCORE (and VDD) is issued upon activating NRST.

– Without STPMIC1

Connect NRST to NRST_CORE (in case VDD is below 2.745V, connection should be done using a
capacitor with a value of 1/10th of the capacitor value present between NRST and GND, ensure also

that potential capacitors between NRST_CORE to GND are removed).

The drawback is that, the debug logic also being reset, it is not possible to debug the boot chain (TF-A and
U-Boot) as any breakpoints set are lost during the power cycle or NRST_CORE activation.

2.

By software:

– For interfaces required during boot, whether Flash memory peripherals (SDMMC1/2, QUADSPI, or

FMC) or USART/UART (USART2/3/6 or UART4/5/7/8), use the same clock as the one used during the
BootROM execution:

◦ If BOOT[2:0] = 000 or 110 (UART boot), set UARTxxSRC[2:0] to 0 (pclk) or 2 (hsi_ker_ck), for all

UART instances not disabled via uart_intances_disabled bitfield of the BSEC OTP WORD 3.

◦ If BOOT[2:0] = 001 or 111 (QUADSPI boot), set QSPISRC[2:0] to 0 (aclk) or 3 (per_ck).

◦ If BOOT[2:0] = 010 or 101 (SDMMC boot), set SDMMC12SRC[2:0] to 0 (hclk6) or 3 (hsi_ker_ck).

– For SD card, the use of HSI (64 MHz) causes raw bandwidth performance penalty as only 32 or

64 MHz could be used instead of respectively 50 MHz (SDR25/DDR50) and 100 MHz (SDR50)

– For eMMC, the use of HSI (64 MHz) causes raw bandwidth performance penalty as only 32 or 64 MHz

could be used instead of respectively 52 MHz (SDR/DDR) or over 100 MHz (HS200). Note that hclk6/
hclk5/aclk are limited to 200 MHz when hclk6 is used as SDMMC1/SDMMC2 kernel clock

◦ If BOOT[2:0] = 011 (FMC boot), set FMCSRC[2:0] to 0 (aclk) or 3 (per_ck)

logic is reset on NRST activation:

System

2.3.6 Limitation of aclk/hclk5/hclk6 to 200 MHz when used as SDMMC1/2 kernel clock

Description

The SDMMC1 and SDMMC2 kernel clock is limited to 200 MHz whereas hclk6 maximum frequency is 266 MHz.
As a consequence, when SDMMC12SRC[2:0] = 0 (hclk6), the AXI bus clock (aclk), AHB5 bus clock (hclk5), and
AHB6 bus clock (hclk6) cannot exceed 200 MHz.

Workaround

Apply one of the following measures:

• When SDMMC12SRC[2:0] = 0, limit aclk/hclk5/hclk6 to 200 MHz.

• Use another SDMMC1/SDMMC2 kernel clock source, that is, set SDMMC12SRC[2:0] to 1, 2, or 3.

2.3.7 Overconsumption in Standby with on‑board 1.8 V regulator bypassed

Description

The device directly supplied from 1.8 V applied on the VDDA1V8_REG pin (with the on-board regulator bypassed
by connecting BYPASS_REG1V8 to VDD) exhibits an overconsumption of about 900 µA in Standby mode (with

the V

DDCORE

VDDA1V8_REG pin.

supply shutdown) or when NRST_CORE is active, due to an excessive leakage through the

ES0438 - Rev 6

page 14/45