STM32 MCU errata sheets: Expected preliminary updates

[KDJEM.1]

Introduction

This article includes preliminary updates of STM32 MCU errata sheets reported since 1st January 2024. It highlights the current description requiring update and the expected one if available.

The purpose of this article is to deliver any expected updates to our MCU errata sheets prior to actual documentation releases. We wish to be transparent with our updates and provide them as fast as possible, to assist you in your design process.
This article is updated on a quarterly basis. Once these preliminary updates are manifested in the errata sheets, this article is refreshed with new information.
Moving forward, we are also working on providing errata sheet releases on a more frequent basis.

IMPORTANT NOTICE - READ CAREFULLY:

• STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to this article at any time without notice.
• Information in this article supersedes and replaces information previously supplied in any prior versions of this article.

• The following table gives a quick reference to the preliminary documentation updates which may be changed or improved without notice.
• This article will be reviewed on a quarterly basis and applied updates will be removed from the table.
• The hyperlinks under "Doc Reference - Revision" provides a direct link to the specific document page where the description is located.

Summary of documentation updates: "STM32 MCU errata sheets"

Function	Series/Lines	Doc Reference - Revision	Description	Date of added update
SPI	STM32F427xx STM32F437xx STM32F429xx STM32F439xx	ES0206 Rev23 (Feb 2025)	Add section:  Corrupted last bit of data and/or CRC, received in Master mode with delayed SCK feedback Description When performing a receive transaction in I2S or SPI Master mode, the last bit of the transacted frame is not captured when the signal provided by an internal feedback loop from the SCK pin exceeds a critical delay. The lastly transacted bit of the stored data then keeps the value from the pattern received previously. As a consequence, the last receive data bit may be wrong, and/or the CRCERR flag can be unduly asserted in the SPI mode if any data under checksum, and/or just the CRC pattern is wrongly captured. In SPI mode, data are synchronous with the APB clock. A delay of up to two APB clock periods can thus be tolerated for the internal feedback delay. The I2S mode is more sensitive than the SPI mode, especially in the case where an odd I2S prescaler factor is set and the APB clock is the system clock divided by two. In this case, the internal feedback delay is lower than 1.5 APB clock period. The main factors contributing to the delay increase are low VDD level, high temperature, high SCK pin capacitive load, and low SCK I/O output speed. The SPI communication speed has no impact. Workaround The following workarounds can be adopted, jointly or individually: • Decrease the APB clock speed. • Configure the I/O pad of the SCK pin to be faster. The following table gives the maximum allowable APB frequency (that still prevents the issue from occurring) versus GPIOx_OSPEEDR output speed for the SCK pin, with a 30 pF capacitive load.	Mar 2024
System	STM32G471xx STM32G473xx STM32G474xx STM32G483xx STM32G484xx	ES0430 Rev9 (Jun 2024)	Remove section: The same errata looks to appear 2 times : 2.2.5 MCU cannot enter in Standby mode when HSE bypass used 2.2.10 Device cannot enter Standby mode when HSE bypass used as system clock	Jun 2025
	STM32H503CB STM32H503EB STM32H503KB STM32H503RB	ES0561 Rev5 (Dec 2025)	Current: Debug authentication services unavailable after direct transition from OPEN to CLOSED Description Debug authentication (DA) services fail and debug access through DA is not available if the device is provisioned using the following sequence: 1. The product is in VIRGIN state (never used). 2. A provisioning firmware is downloaded and executed while the device is in PRODUCT_STATE = OPEN. This firmware:–– Programs the OTP for debug authentication, and Directly sets PRODUCT_STATE = CLOSED. No external programmer is used to transition the device from PRODUCT_STATE = PROVISIONING to PRODUCT_STATE = CLOSED. As a result, the internal debug authentication configuration is not correctly established, and DA services cannot be used. Workaround 1. Using a firmware: a. Download a first firmware whose only purpose is to set PRODUCT_STATE = REGRESSION. b. After this first firmware has run successfully, change the product state to PRODUCT_STATE = IROT‑PROVISIONED. c. Reset the device to execute the regression process. 2. Executing the system bootloader: a. While the device is in PRODUCT_STATE = OPEN, set the BOOT0 pin to VDD. 3. Perform a debug authentication discovery procedure via the bootloader. 4. Provision the product using PRODUCT_STATE = PROVISIONING, and then follow the standard provisioning flow. Expected: Debug Authentication fails if change of PRODUCT_STATE is done by embedded firmware Description Debug authentication (DA) services fail and regression through DA is not available if the device is provisioned using the following sequence:  The product is in VIRGIN state (never used).  The firmware is downloaded and executed while the device is in PRODUCT_STATE = Open.  This firmware programs the OTP for debug authentication, and changes PRODUCT_STATE to iROT-Provisioned or Closed. Note: new PRODUCT_STATE is active after changing option byte change followed by a system reset. Firmware can go from Open to Closed through iROT-Provisioning or Provisioned states by changing twice the PRODUCT_STATE and finishing by a system reset. Workaround On a virgin device before flashing the embedded firmware that changes the PRODUCT_STATE Go though a regression triggered by a dedicated firmware Program the dedicated firmware Dedicated firmware detects Open state : changes PRODUCT_STATE to Provisioned and resets Dedicated firmware detects Provisioned state : changed PRODUCT_STATE to Regression and resets Set BOOT0 pin to VDD and reset the target. Set back BOOT0 to VSS Launch DA discovery in Open state and reset the target	Mar 2026
IWDG	STM32F100x4 STM32F100x6 STM32F100x8 STM32F100xB	ES093 Rev8 (Jul 2022)	Remove sections: Delete duplicated sections: - RVU flag not cleared at low APB clock frequency - PVU flag not cleared at low APB clock frequency	Mar 2024
	STM32F10xx4 STM32F10xx6	ES0348 Rev10 (Jun 2022)
	STM32F101xF STM32F101xG STM32F103xF STM32F103xG	ES0346 Rev7 (Jul 2022)
	STM32F101xC STM32F101xD STM32F101xE STM32F103xC STM32F103xD STM32F103xE	ES0340 Rev17 (Jun 2022)
	STM32F105xx STM32F107xx	ES022 Rev11 (Jun 2022)
	STM32F100xC STM32F100xD STM32F100xE	ES0136 Rev7 (Aug 2022)
HRTIM	STM32F334x4 STM32F334x6 STM32F334x8	ES0258 Rev8 (Aug 2021)	Table 4. Summary of silicon limitations Current: A = limitation present, workaround available Expected: With N = limitation present, no workaround available	Nov 2024
ADC	STM32L412xx STM32L422xB	ES0456 Rev6 (Nov 2024)	Remove section: Delete duplicated section: "2.6.9 Writing ADCx_JSQR when JADCSTART and JQDIS are set might lead to incorrect behavior" should be removed. It is duplicated with "2.6.1 Writing ADC_JSQR when JADCSTART and JQDIS are set may lead to incorrect behavior"	Dec 2024
CEC	STM32H7A3xI STM32H7A3xG STM32H7B0xB STM32H7B3xI	ES0478 Rev11 (Apr 2022)	Add section: Unexpected TXERR flag during a message transmission. Description  During the transmission of a 0 or a 1, the HDMI-CEC drives the open-drain output to high-Z, so that the external pull-up implements a voltage rising ramp on the CEC line. In some load conditions, with several powered-off devices connected to the HDMI-CEC line, the rising voltage may not drive the HDMI-CEC GPIO input buffer to VIH within two HDMI-CEC clock cycles from the high-Z activation to TXERR flag assertion. Workaround Limit the maximum number of devices connected to the HDMI-CEC line to ensure the GPIO VIH threshold is reached within a time of two HDMI-CEC clock cycles (~61 µs). The maximum equivalent 10%-90% rise time for the HDMI CEC line is 111.5 µs, considering a VIH threshold equal to 0.7 x VDD.	Dec 2024
OCTOSPI	STM32H7A3xI STM32H7A3xG STM32H7B0xB STM32H7B3xI	ES0478 Rev11 (Apr 2022)	Add section: Transactions are limited to 8 Mbytes in OctaRAM™ memories. Description  When the controller is configured in Macronix OctaRAM™ mode, by setting the MTYP[2:0] bitfield of the OCTOSPI_DCR1 register to 011, only 13 bits of row address are decoded and sent to the memory, meaning that only 8 K of 1-Kbyte blocks can be accessed (8 Mbytes). Workaround None. This limitation is not present for PSRAMs or HyperRAM™ memories.	Dec 2024
Applicability	STM32H7A3xI STM32H7A3xG STM32H7B0xB STM32H7B3xI	ES0478 Rev11 (Apr 2022)	Table 1. Device summary Add: STM32H7A3LG in the part numbers list.	Jun 2025
	STM32U375xx STM32U385xx	ES0626 Rev2 (Jan 2026)	Current: 2. REV_ID[5:0] bitfield of DBGMCU_IDCODE fuse Expected: 2. REV_ID[15:0] bitfield of DBGMCU_IDCODE fuse	Dec 2025