- Last edited 5 months ago ago
STM32MP15 ecosystem errata sheet
The STM32MP15xx device errata sheet lists the different device limitations and explains the corresponding workarounds (software and/or hardware) if any.
The objective of this article is to explain which of the workarounds described in this errata sheet are implemented in STM32MP15 ecosystem releases.
Here is the legend used in the columns "Status STM32MP15xx Rev.B" (collapsed by default) and "Status STM32MP15xx Rev.Z" of the table below. It refers to the availability and status of a given errata workaround for the described erratum:
- A = workaround available
- P = partial workaround available
- - = no workaround needed because the limitation is absent in the given revision
Here is the legend used in the column "STM32MP15-Ecosystem-vx.x.x Status" of the table below. It refers to the availability of a workaround for a given STM32MP15 ecosystem release:
- I = workaround Implemented
- P = workaround Partialy implemented
- N= workaround Not implemented
- NA= workaround Not Applicable
Wave your mouse over a status in the table to display the corresponding legend.
ecosystem release v3.0.0
|Comment about the workaround implemented in STM32MP15 ecosystem|
|Arm® Cortex®-A7 core||2.1.1||Memory locations might be accessed speculatively due to instruction fetches when HCR.VM is set||A||A||N||Workaround not implemented: STM32MPU Embedded Software distribution does not activate Arm® Cortex®-A7 Hypervisor mode and hence the Virtual Memory second stage of translation.|
It is customer responsibility to implement the workaround if the Hypervisor mode is used in his/her product.
|2.1.2||Cache maintenance by set/way operations can execute out of order||A||A||I||Implementation accepted by the community since Linux® kernel v5.3 in arch/arm/Kconfig (refer to ARM_ERRATA_814220).|
|2.1.4||PMU event counter 0x14 does not increment correctly||A||A||N||No impact on the system. Minor impact on performance measurement.|
No workaround provided by Arm for Linux kernel PMU driver.
|Arm® Cortex®-M4 core||2.2.1||Interrupted loads to SP can cause erroneous behavior||A||A||N||Limitation only on hand-written assembly code.|
The customer must implement the workaround in the product assembly code.
|2.2.2||VDIV or VSQRT instructions might not complete correctly when very short ISRs are used||A||A||N||STM32CubeMP1 Package provided as example.|
It is customer responsibility to implement one of the proposed workarounds according to the user code and product configuration.
|2.2.3||Store immediate overlapping exception return operation might vector to incorrect interrupt||A||A||N||Minor impact on the system.|
Workaround to be implemented by customer according to the MPU configuration.
|System||2.3.1||TPIU fails to output sync after the pattern generator is disabled in Normal mode||A||A||N||No workaround implemented.|
No impact on the system since this issue occurs only on the trace port.
|2.3.3||HSE external oscillator required in some LTDC use cases||P||P||I||Hardware implementation of the external oscillator connected to the HSE pins available on STM32MP157x-EV1 MB1263 Rev.C (aka "MB1263C") and STM32MP157x-DKx MB1272 Rev.C (aka "MB1272C").|
|2.3.4||RCC cannot exit Stop and Low-power Stop modes||A||A||I||Implemented in TF-A plat/st/stm32mp1/bl2_plat_setup.c|
|2.3.5||Incorrect reset of glitch-free kernel clock switch||P||P||I||By default, STPMIC1 performs a VDDCORE reset on NRST activation.|
|2.3.6||Limitation of aclk/hclk5/hclk6 to 200 MHz when used as SDMMC1/2 kernel clock||P||P||I||Implemented in TF-A fdts with a clock tree that uses a SDMMC1/SDMMC2 kernel clock source different from the aclk/hclk5/hclk6 bus clock.|
|2.3.8||eMMC boot timeout too short||A||-||I||Rev.B workaround implemented in STM32MP157x-EV1 MB1263 Rev.C (aka "MB1263C") that uses an eMMC that meets the required timing.|
|2.3.9||Cortex-M4 cannot use I/O compensation on Standby mode exit||A||A||I||The examples delivered with STM32Cube use only IOSPEEDR[1:0] settings 00 and 01.|
|2.3.19||DLYB limits SDMMC throughput||A||A||I||OpenSTLinux distribution does not enable HS200 nor SDR104 mode.|
|DDRPHYC||2.4.1||DDRPHYC overconsumption upon reset or Standby mode exit||A||-||NA||DDRPHYC is correctly reinitialized by TF-A after reset and Standby mode exit.|
On Rev.B, the issue is present if Cortex®-M4 standalone wakeup as TF-A is not executed and hence DDRPHYC not reinitialized.
|2.4.2||DDR_CLK jitter out of JEDEC requirement for 32-bit LPDDR2/LPDDR3 at low device Tj||A||A||NA||ST boards use DDR3 instead of LPDDR2/3.|
|2.4.3||Data corruption at low device Tj combined with low 32-bit LPDDR2/LPDDR3 I/O supply voltage||A||A||NA||ST boards use DDR3 instead of LPDDR2/3.|
|DMAMUX||2.7.4||Wrong input DMA request routed upon specific DMAMUX_CxCR register write coinciding with synchronization event||A||A||P||Not applicable to OpenSTLinux distribution since DMA Synchronous mode is not used. |
It is customer responsibility to provide the right DMAMUX signal polarity configuration when calling the HAL_DMAEx_ConfigMuxSync() function provided in STM32CubeMP1 Package Src/stm32mp1xx_hal_dma_ex.c .
|QUADSPI||2.8.1||Memory-mapped read of last memory byte fails||P||P||A||Implemented in OpenSTLinux distribution drivers/spi/spi-stm32-qspi.c|
|ADC||2.9.1||New context conversion initiated without waiting for trigger when writing new context in ADC_JSQR with JQDIS = 0 and JQM = 0||A||A||Not applicable to Linux stm32-adc driver , since JQDIS = 1.|
|2.9.2||Two consecutive context conversions fail when writing new context in ADC_JSQR just after previous context completion with JQDIS = 0 and JQM = 0||P||P||Not applicable to Linux stm32-adc driver , since JQDIS = 1.|
|2.9.3||Unexpected regular conversion when two consecutive injected conversions are performed in Dual interleaved mode||A||A||Not applicable to Linux stm32-adc driver , since Dual mode is not used.|
|2.9.5||ADC ANA0/ANA1 resolution limited when Gigabit Ethernet is used||P||P||P||The customer must implement this workaround by limiting the ADC data resolution in OpenSTLinux distribution device tree configuration or in the STM32CubeMP1 Package application.|
|2.9.6||ADC missing codes in differential 16-bit static acquisition||P||P||P||The customer must implement this workaround by limiting the ADC data resolution in OpenSTLinux distribution device tree configuration or in the STM32CubeMP1 Package application.|
|DAC||2.10.1||Invalid DAC channel analog output if the DAC channel MODE bitfield is programmed before DAC initialization||A||A||P||The Linux DAC driver uses only the Normal mode. It never needs to modify the MODE bitfield.|
Both Normal and Sample and hold modes are supported by the HAL drivers. It is up to the user to properly call HAL_DAC_Init before HAL_DAC_ConfigChannel to avoid the issue.
|VREFBUF||2.11.2||Overshoot on VREFBUF output||A||A||I||The U-Boot stm32-vrefbuf driver and Linux stm32-vrefbuf driver implement the workaround.|
|DTS||2.12.1||Mode using PCLK & LSE (REFCLK_SEL = 1) should not be used||P||P||I||Implemented in OpenSTLinux distribution drivers/thermal/st/stm_thermal.c|
|TIM||2.15.1||One-pulse mode trigger not detected in master-slave reset + trigger configuration||P||P||N||This workaround is proposed only as a recommendation.|
|LPTIM||2.16.1||MCU may remain stuck in LPTIM interrupt when entering Stop mode||A||A||N||The LPTIM interrupt is not used in OpenSTLinux distribution. |
This workaround is not implemented in STM32CubeMP1 Package. It is customer responsibility to implement it in MspDeinit().
|2.16.2||MCU may remain stuck in LPTIM interrupt when clearing event flag||P||P||I||The LPTIM interrupt is not used in OpenSTLinux distribution. |
|RTC and TAMP||2.17.2||Calendar initialization may fail in case of consecutive INIT mode entry||A||A||I||This workaround is implemented in OpenSTLinux distribution drivers/rtc/rtc-stm32.c .|
|I2C||2.18.1||Wrong data sampling when data setup time (tSU;DAT) is shorter than one I2C kernel clock period||P||P||I||This workaround is implemented in TF-A fdts with a clock tree that configures the I2C kernel clock source to a frequency higher than 20 MHz.|
|2.18.2||Spurious bus error detection in master mode||A||A||N||In order to get real bus error notifications, this workaround is implemented neither within OpenSTLinux distribution nor within STM32CubeMP1 Package.|
|2.18.3||Spurious master transfer upon own slave address match||P||P||NA||The multimaster mode implementation of STM32CubeMP1 Package I2C HAL driver prevents such case from happening.|
|2.18.5||Transmission stalled after first byte transfer||A||A||N|
|SPI||2.20.1||Master data transfer stall at system clock much faster than SCK||A||A||I||SPI is disabled after each EOT in OpenSTLinux distribution drivers/spi/spi-stm32.c and in STM32CubeMP1 Package Src/stm32mp1xx_hal_spi.c .|
|2.20.2||Corrupted CRC return at non-zero UDRDET setting||P||P||N||Slave mode and CRC are not supported in OpenSTLinux distribution. |
This workaround is not implemented in STM32CubeMP1 Package.
|2.20.3||TXP interrupt occurring while SPI disabled||A||A||I||This workaround is implemented in OpenSTLinux distribution, drivers/spi/spi-stm32.c ensures that all interrupts are disabled before the SPI is disabled.|
|2.20.4||Possible corruption of last-received data depending on CRCSIZE setting||A||A||N||CRC is not supported in OpenSTLinux distribution.|
|FDCAN||2.21.1||Desynchronization under specific condition with edge filtering enabled||A||A||N|
|2.21.2||Tx FIFO messages inverted under specific buffer usage and priority setting||A||A||N|
|2.21.3||DAR mode transmission failure due to lost arbitration||A||A||N|
|ETH||2.23.2||Rx DMA may fail to recover upon DMA restart following a bus error, with Rx timestamping enabled||A||A||N|
|2.23.3||Spurious receive watchdog timeout interrupt||A||A||N|
|2.23.5||Incorrect flexible PPS output interval under specific conditions||A||A||N|
|2.23.6||Packets dropped in RMII 10Mbps mode due to fake dribble and CRC error||A||A||N|
|2.23.7||ARP offload function not effective||A||A||I||ARP software support is used in OpenSTLinux distribution.|