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		Silicon revision codes
	Device marking(1)		REV_ID(2)
STM32MP151x/3x/7x	B		0x2000
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.

ES0438 - Rev 6 - February 2021	www.st.com
For further information contact your local STMicroelectronics sales office.

STM32MP151x STM32MP153x STM32MP157x

Summary of device errata

1Summary 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

				Status
	Function	Section	Limitation	Rev.	Rev.
				B	Z
		2.1.1	Memory locations might be accessed speculatively due to instruction	A	A
			fetches when HCR.VM is set
	Arm Cortex-A7	2.1.2	Cache maintenance by set/way operations can execute out of order	A	A
	core	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
	Arm Cortex-M4	2.2.2	VDIV or VSQRT instructions might not complete correctly when very short	A	A
			ISRs are used
	core
		2.2.3	Store immediate overlapping exception return operation might vector to	A	A
			incorrect interrupt
		2.3.1	TPIU fails to output sync after the pattern generator is disabled in Normal	A	A
			mode
		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	Limitation of aclk/hclk5/hclk6 to 200 MHz when used as SDMMC1/2 kernel	P	P
			clock
		2.3.7	Overconsumption in Standby with on board 1.8 V regulator bypassed	A	-
	System
		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	RCC security settings for Cortex-M4 access are not kept upon wake up	N	N
			from Standby
		2.3.13	Wakeup pin flags cleared at Standby mode exit with MCU_BEN high and	N	N
			MPU_BEN low
		2.3.14	Boundary scan data unduly sampled on TCK falling edge	A	A
		2.3.15	Boundary scan SAMPLE/PRELOAD behavior not compliant with	A	A
			IEE1149.1

ES0438 - Rev 6	page 2/45

STM32MP151x STM32MP153x STM32MP157x

Summary of device errata

				Status
	Function	Section	Limitation	Rev.	Rev.
				B	Z
		2.3.16	Boot with a specific combination of NAND Flash memories fails	N	-
		2.3.17	Boot with 1-bit error correction on SLC NAND Flash memory fails	A	-
	System	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	DDR_CLK jitter out of JEDEC requirement for 32-bit LPDDR2/LPDDR3 at	A	A
	DDRPHYC		low device Tj
		2.4.3	Data corruption at low device Tj combined with low 32-bit LPDDR2/	A	A
			LPDDR3 I/O supply voltage
	GPIO	2.5.1	GPIO assigned to DAC cannot be used in output mode when the DAC	N	N
			output is connected to on-chip peripheral
	DMA	2.6.1	USART/UART/LPUART DMA transfer abort	D	D
		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
	DMAMUX
		2.7.3	OFx not asserted when writing into DMAMUX_RGCFR register	N	N
		2.7.4	Wrong input DMA request routed upon specific DMAMUX_CxCR register	A	A
			write coinciding with synchronization event
	QUADSPI	2.8.1	Memory-mapped read of last memory byte fails	P	P
		2.9.1	New context conversion initiated without waiting for trigger when writing	A	A
			new context in ADC_JSQR with JQDIS = 0 and JQM = 0
			Two consecutive context conversions fail when writing new context in
		2.9.2	ADC_JSQR just after previous context completion with JQDIS = 0 and	A	A
			JQM = 0
	ADC
		2.9.3	Unexpected regular conversion when two consecutive injected	A	A
			conversions are performed in Dual interleaved mode
		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
	VREFBUF	2.11.1	VREFBUF Hold mode cannot be used	N	N
		2.11.2	Overshoot on VREFBUF output	A	A
		2.10.1	Invalid DAC channel analog output if the DAC channel MODE bitfield is	A	A
			programmed before DAC initialization
	DAC
		2.10.2	DMA underrun flag not set when an internal trigger is detected on the	N	N
			clock cycle of the DMA request acknowledge
	DTS	2.12.1	Mode using PCLK & LSE (REFCLK_SEL = 1) should not be used	P	P
	DSI	2.13.1	DSI PHY compliant with MIPI DPHY v0.81 specification, not with DSI PHY	N	-
			v1.0
		2.15.1	One-pulse mode trigger not detected in master-slave reset + trigger	P	P
			configuration
	TIM
		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
	LPTIM	2.16.1	Device may remain stuck in LPTIM interrupt when entering Stop mode	A	A

ES0438 - Rev 6	page 3/45

STM32MP151x STM32MP153x STM32MP157x

Summary of device errata

				Status
	Function	Section	Limitation	Rev.	Rev.
				B	Z
	LPTIM	2.16.2	Device may remain stuck in LPTIM interrupt when clearing event flag	P	P
		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
	RTC and TAMP
		2.17.4	A tamper event fails to trigger timestamp or timestamp overflow events	N	N
			during a few cycles after clearing TSF
		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	Wrong data sampling when data setup time (tSU;DAT) is shorter than one	P	P
			I2C kernel clock period
		2.18.2	Spurious bus error detection in master mode	A	A
	I2C
		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
	USART	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
	SPI	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
	FDCAN	2.21.2	Tx FIFO messages inverted under specific buffer usage and priority	A	A
			setting
		2.21.3	DAR mode transmission failure due to lost arbitration	A	A
	OTG_HS	2.22.1	Host packet transmission may hang when connecting through a hub to a	N	N
			low-speed device
		2.23.1	Incorrect L4 inverse filtering results for corrupted packets	N	N
		2.23.2	Rx DMA may fail to recover upon DMA restart following a bus error, with	A	A
			Rx timestamping enabled
		2.23.3	Spurious receive watchdog timeout interrupt	A	A
		2.23.4	Incorrect flexible PPS output interval under specific conditions	A	A
	ETH	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	Bus error coinciding with start-of-packet corrupts MAC-generated packet	N	N
			transmission
		2.23.10	DMA spurious state upon AXI DMA slave bus error	P	P

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

ES0438 - Rev 6	page 4/45

			STM32MP151x STM32MP153x STM32MP157x
			Summary of device errata
			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

ES0438 - Rev 6	page 5/45

STM32MP151x STM32MP153x STM32MP157x

Description of device errata

2Description 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.1Arm 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.1Memory 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.2Cache 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.3PMU 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.4PMU 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.5Exception 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.2Arm Cortex-M4 core

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

2.2.1Interrupted 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.2VDIV 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.3Store 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.3System

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

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.

ES0438 - Rev 6	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.2Serial-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.3HSE 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
				System
		Table 5. Use of external oscillator on HSE pins
	LTDC connected to		Conditions	External oscillator on
				HSE
			3 V < VDD< 3.6 V
			fpixel up to 74.25 MHz (1280x720 at 60 fps)	Mandatory
			OSPEEDR = 1 for all LTDC signals
			USB HS used
		HDMI bridge close to
			1.7 V < VDD< 2 V
	HDMI bridge	the device
			fpixel up to 74.25 MHz
		load ~15 pf
			Duty cycle = 40 %	Recommended
			0.1 VDD < VIN < 0.9 VDD
			OSPEEDR = 3 for LCD_CLK
			OSPEEDR = 2 for all other LTDC signals
			3 V < VDD< 3.6 V
			fpixel up to 90 MHz (1366x768 at 60 fps)
			OSPEEDR = 2 for LCD_CLK	Mandatory
			OSPEEDR = 1 for all other LTDC signals
			USB HS used
			3 V < VDD< 3.6 V
			fpixel up to 48 MHz (800x600 at 60 fps)
	Parallel LCD	load < 30 pf	OSPEEDR = 1 for LCD_CLK
			OSPEEDR = 0 for all other LTDC signals
			1.7 V < VDD< 2 V	Recommended
			fpixel up to 69 MHz (1024x768 at 60 fps)
			Duty cycle = 40 %
			0.1 VDD < VIN < 0.9 VDD
			OSPEEDR = 3 for LCD_CLK
			OSPEEDR = 2 for all other LTDC signals

2.3.4RCC 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.5Incorrect 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
		System
	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 VDDCORE logic is reset on NRST activation:
	–	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)

2.3.6Limitation 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.7Overconsumption 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 VDDCORE supply shutdown) or when NRST_CORE is active, due to an excessive leakage through the VDDA1V8_REG pin.

ES0438 - Rev 6	page 14/45