STM32G0B1xB/xC/xE

Errata sheet

STM32G0B1xB/xC/xE device errata

Applicability
This document applies to the part numbers of STM32G0B1xB/xC/xE 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 RM0444.
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

STM32G0B1xB STM32G0B1CB, STM32G0B1KB, STM32G0B1MB, STM32G0B1RB, STM32G0B1VB

STM32G0B1xC STM32G0B1CC, STM32G0B1KC, STM32G0B1MC, STM32G0B1RC, STM32G0B1VC
STM32G0B1xE STM32G0B1CE, STM32G0B1KE, STM32G0B1ME, STM32G0B1NE, STM32G0B1RE, STM32G0B1VE

Table 2. Device variants

Silicon revision codes

Reference
Device marking(1) REV_ID(2)

A 0x1000
STM32G0B1xB/xC/xE
Z 0x1001

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_IDCODE register.

ES0548 - Rev 3 - October 2022 www.st.com

For further information contact your local STMicroelectronics sales office.
 STM32G0B1xB/xC/xE
Summary of device errata

1 Summary of device errata

The following table gives a quick reference to the STM32G0B1xB/xC/xE 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.
A Z

2.2.1 Unstable LSI when it clocks RTC or CSS on LSE P P

2.2.2 WUFx wakeup flag wrongly set during configuration A A
Overwriting with all zeros a flash memory location previously programmed
2.2.3 N N
with all ones fails
2.2.4 Wakeup from Stop not effective under certain conditions N N
2.2.5 Flash memory PCROP area weakness N -
System
2.2.6 PC13 signal transitions disturb LSE N N
2.2.7 SRAM contents corrupted upon entry in Standby N -
2.2.9 Device lock upon mismatch of option bytes P -
2.2.10 Prefetch failure when branching across flash memory banks N N
Corrupted content of the RTC domain due to a missed power-on reset
2.2.11 A A
after this domain supply voltage drop
Wakeup capability-enabled GPIOs not configurable after wakeup from
GPIO 2.3.1 P -
Standby
DMA disable failure and error flag omission upon simultaneous transfer
DMA 2.4.1 A A
error and global flag clear
2.5.1 SOFx not asserted when writing into DMAMUX_CFR register N N
2.5.2 OFx not asserted for trigger event coinciding with last DMAMUX request N N
DMAMUX 2.5.3 OFx not asserted when writing into DMAMUX_RGCFR register N N
Wrong input DMA request routed upon specific DMAMUX_CxCR register
2.5.4 A A
write coinciding with synchronization event
2.6.1 Overrun flag is not set if EOC reset coincides with new conversion end P P
Writing ADC_CFGR1 register while ADEN bit is set resets RES[1:0]
2.6.2 A A
bitfield
ADC
2.6.3 Out-of-threshold value is not detected in AWD1 Single mode A A
2.6.4 ADC sampling time might be one cycle longer N N
2.6.5 ADC offset may be out of specification A -
One-pulse mode trigger not detected in master-slave reset + trigger
2.7.1 P P
configuration
TIM
2.7.2 Consecutive compare event missed in specific conditions N N
2.7.3 Output compare clear not working with external counter reset P P

ES0548 - Rev 3 page 2/22

 STM32G0B1xB/xC/xE
Summary of device errata

Status
Function Section Limitation Rev. Rev.
A Z

2.8.1 Device may remain stuck in LPTIM interrupt when entering Stop mode A A
LPTIM
2.8.2 Device may remain stuck in LPTIM interrupt when clearing event flag P P
RTC and TAMP 2.9.1 Calendar initialization may fail in case of consecutive INIT mode entry A A
Wrong data sampling when data setup time (tSU;DAT) is shorter than one
2.10.1 P P
I2C I2C kernel clock period
2.10.2 Spurious bus error detection in master mode A A
USART 2.11.1 Data corruption due to noisy receive line N N
2.12.1 BSY bit may stay high when SPI is disabled A A
SPI
2.12.2 BSY bit may stay high at the end of data transfer in slave mode A A
2.13.1 Desynchronization under specific condition with edge filtering enabled A A
FDCAN Tx FIFO messages inverted under specific buffer usage and priority
2.13.2 A A
setting
UCPD 2.14.1 UCPD transmitter output marginality at low temperature N N

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

Table 4. Summary of device documentation errata

Function Section Documentation erratum

System 2.2.8 Boot select after debug interface connection

USART 2.11.2 USART prescaler feature missing in USART implementation section

ES0548 - Rev 3 page 3/22

 STM32G0B1xB/xC/xE
Description of device errata

2 Description of device errata

The following sections describe the errata 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 Core
Reference manual and errata notice for the Arm® Cortex®-M0+ core revision r0p1 is available from http://
infocenter.arm.com.

2.2 System

2.2.1 Unstable LSI when it clocks RTC or CSS on LSE

Description
The LSI clock can become unstable (duty cycle different from 50 %) and its maximum frequency can become
significantly higher than 32 kHz, when:
• LSI clocks the RTC, or it clocks the clock security system (CSS) on LSE (which holds when the LSECSSON
bit set), and
• the VDD power domain is reset while the backup domain is not reset, which happens:
– upon exiting Shutdown mode
– if VBAT is separate from VDD and VDD goes off then on
– if VBAT is tied to VDD (internally in the package for products not featuring the VBAT pin, or externally)
and a short (< 1 ms) VDD drop under VDD(min) occurs

Workaround
Apply one of the following measures:
• Clock the RTC with LSE or HSE/32, without using the CSS on LSE
• If LSI clocks the RTC or when the LSECSSON bit is set, reset the backup domain upon each VDD power up
(when the PWRRSTF flag is set). If VBAT is separate from VDD, also restore the RTC configuration, backup
registers and anti-tampering configuration.

2.2.2 WUFx wakeup flag wrongly set during configuration

Description
Upon configuring a wakeup pin (WKUPx), the corresponding wakeup flag (WUFx) might spuriously go high
depending on the state and configuration of the wakeup pin.

Workaround
After configuring a wakeup pin, clear its corresponding WUFx flag.

2.2.3 Overwriting with all zeros a flash memory location previously programmed with all ones fails

Description
Any attempt to re-program with all zeros (0x0000 0000 0000 0000) a flash memory location previously
programmed with 0xFFFF FFFF FFFF FFFF fails and the PROGERR flag of the FLASH_SR register is set.
Note: Flash memory locations in the erased state (that is, not programmed) are not affected by this failure. They can
be programmed with any value.

ES0548 - Rev 3 page 4/22

 STM32G0B1xB/xC/xE
System

Workaround
None.

2.2.4 Wakeup from Stop not effective under certain conditions

Description
With the HSI clock divider bitfield HSIDIV[2:0] set to a value different from 000, the device fails to enter Stop mode
when SYSCLK is set to HSE clock.
With the HSI clock divider bitfield HSIDIV[2:0] set to a value different from 000, peripherals with clock request
capability fail to wake the device up from Stop modes.

Workaround
None.

2.2.5 Flash memory PCROP area weakness

Description
When the CPU accesses PCROP-protected flash memory areas:
• Fetch requests are allowed and are responded to normally.
• Read access are properly discarded. However, the bus holds and returns the value read during previous
successful access.

Workaround
None.
Note: We recommend to use the PCROP protection in the following RDP and PCROP_RDP configurations:
• RDP = Level 1 and PCROP_RDP = 1
• RDP = Level 2

2.2.6 PC13 signal transitions disturb LSE

Description
The PC13 port toggling disturbs the LSE clock.

Workaround
None.

2.2.7 SRAM contents corrupted upon entry in Standby

Description
Entry of the device in Standby mode causes the SRAM content corruption.

Workaround
None.

2.2.8 Boot select after debug interface connection

Description
Some revisions of the reference manual may omit the following information.

ES0548 - Rev 3 page 5/22

 STM32G0B1xB/xC/xE
System

After connecting the debug interface and until the device power-down, the boot source upon reset or wakeup from
a low-power mode is determined by the PA14-BOOT0 pin level before connecting the debug interface (stored by
the device), as opposed to the actual PA14-BOOT0 pin level. The device power-up restores the operation of the
PA14-BOOT0 pin as direct boot source selector.
This is a documentation issue rather than a device limitation.

Workaround
No application workaround is required or applicable.

2.2.9 Device lock upon mismatch of option bytes

Description
An option byte mismatch (for example, due to its failing modification attempt) detection leads to setting the
BOOT_LOCK register bit high and the RDP to Level 1 or higher. This disables the debug interface, which then
makes the device reprogramming impossible.
Note: On the latest device versions, an option byte mismatch detection results in setting the device in RDP Level 1
with BOOT_LOCK register bit low. This keeps the debug connection available for reprogramming the device.

Workaround
Ensure a safe environment when modifying the option bytes, to prevent any option byte corruption.

2.2.10 Prefetch failure when branching across flash memory banks

Description
In rare cases, the code prefetch may fail upon branching and function calls across flash memory banks,
regardless of the DUAL_BANK and nSWAP_BANK option byte settings. The failing prefetch then provides an
incorrect data to the CPU, which causes code execution corruption and may lead to HardFault interrupt.
Note: The following uses of the dual bank functionality remain safe:
• EEPROM emulation or other data storage in bank 2
• bank 2 used as a download or backup slot for firmware
• mirroring the code in the banks and using bank swapping upon reset
• branching and function calls across flash memory banks, with the prefetch function deactivated

Workaround
None.

2.2.11 Corrupted content of the RTC domain due to a missed power-on reset after this domain supply
voltage drop

Description
The RTC domain reset may be missed upon a power-on following a power-off, if its supply voltage drops during
the power-off phase hitting a window, which is few mV wide before it starts to rise again. In this critical window, the
flip-flops are no longer able to safely retain the information and the RTC domain reset has not yet been triggered.
This window is located in the range between 100 mV and 700 mV, with the exact position depending mainly on
the device and on the temperature.
This missed reset results in unpredictable values of the RTC domain registers. This may cause a spurious
behavior (such as driving the LSCO output pin on PA2 or influencing RTC functions).

Workaround
Apply one of the following measures:
• In the application, let the VDD and VBAT supply voltages fall to a level below 100 mV for more than 200 ms
before a new power‑on.

ES0548 - Rev 3 page 6/22

 STM32G0B1xB/xC/xE
GPIO

• If the above workaround cannot be applied, and the boot follows a power‑on reset, erase the RTC domain
by software.
When the application is using shutdown mode, user needs to discriminate between the power‑on reset or an
exit from a shutdown mode.
For this purpose, at least one backup register must have been previously programmed with a
BKP_REG_VAL value with 16 bits set and 16 bits cleared.
Robustness of this workaround can be significantly improved by using a CRC rather than registers. The
registers are subject to backup domain reset.
The workaround consists of calculating the CRC of the backup registers: RCC_BDCR and RTC registers,
excluding bits modified by HW.
The CRC result can be stored in the backup register instead of a fixed value. This value needs to be
updated for each modification of values covered by CRC, such as by using CRC peripheral.
At the very beginning of the boot code, insert the following software sequence:
1. Check the BORRSTF flag of the RCC_CSR register. If set, the reset is caused by a power on, or is
exiting from shutdown mode.
2. If BORRSTF flag is true, and the shutdown mode is used in the application, check that the backup
register value is different from BKP_REG_VAL. When tamper detection is enabled,check that no
tamper flag is set. If both conditions are met then the reset is caused by a power-on.
3. If the reset is caused by a power-on, apply the following sequence:
a. Enable the PWR clock in the RCC, by setting the PWREN bit.
b. Enable the RTC domain access in the PWR, by setting the DBP bit.
c. Reset the RTC domain, by:
i. Writing 0x0001 0000 in the RCC_BDCR register, which sets the BDRST bit and clears other
register bits that might not be reset.
ii. reading the RCC_BDCR register, to make the reset time long enough
iii. writing 0x0000 0000 in the RCC_BDCR register, to clear the BDRST bit
d. Clear the BORRSTF flag by setting the RMVF bit of the RCC_CSR register.

2.3 GPIO

2.3.1 Wakeup capability-enabled GPIOs not configurable after wakeup from Standby

Description
After the devices wakes up from Standby mode, GPIOs with the wakeup capability enabled cannot further be
configured through the GPIO registers.

Workaround
Disable the wakeup capability of the GPIOs that must remain configurable through the GPIO registers after the
wakeup from Standby.

2.4 DMA

2.4.1 DMA disable failure and error flag omission upon simultaneous transfer error and global flag
clear

Description
Upon a data transfer error in a DMA channel x, both the specific TEIFx and the global GIFx flags are raised and
the channel x is normally automatically disabled. However, if in the same clock cycle the software clears the GIFx
flag (by setting the CGIFx bit of the DMA_IFCR register), the automatic channel disable fails and the TEIFx flag is
not raised.
This issue does not occur with ST's HAL software that does not use and clear the GIFx flag when the channel is
active.

ES0548 - Rev 3 page 7/22

 STM32G0B1xB/xC/xE
DMAMUX

Workaround
Do not clear GIFx flags when the channel is active. Instead, use HTIFx, TCIFx, and TEIFx specific event flags and
their corresponding clear bits.

2.5 DMAMUX

2.5.1 SOFx not asserted when writing into DMAMUX_CFR register

Description
The SOFx flag of the DMAMUX_CSR status register is not asserted if overrun from another DMAMUX channel
occurs when the software writes into the DMAMUX_CFR register.
This can happen when multiple DMA channels operate in synchronization mode, and when overrun can occur
from more than one channel. As the SOFx flag clear requires a write into the DMAMUX_CFR register (to set
the corresponding CSOFx bit), overrun occurring from another DMAMUX channel operating during that write
operation fails to raise its corresponding SOFx flag.

Workaround
None. Avoid the use of synchronization mode for concurrent DMAMUX channels, if at least two of them potentially
generate synchronization overrun.

2.5.2 OFx not asserted for trigger event coinciding with last DMAMUX request

Description
In the DMAMUX request generator, a trigger event detected in a critical instant of the last-generated DMAMUX
request being served by the DMA controller does not assert the corresponding trigger overrun flag OFx. The
critical instant is the clock cycle at the very end of the trigger overrun condition.
Additionally, upon the following trigger event, one single DMA request is issued by the DMAMUX request
generator, regardless of the programmed number of DMA requests to generate.
The failure only occurs if the number of requests to generate is set to more than two (GNBREQ[4:0] > 00001).

Workaround
Make the trigger period longer than the duration required for serving the programmed number of DMA requests,
so as to avoid the trigger overrun condition from occurring on the very last DMA data transfer.

2.5.3 OFx not asserted when writing into DMAMUX_RGCFR register

Description
The OFx flag of the DMAMUX_RGSR status register is not asserted if an overrun from another DMAMUX request
generator channel occurs when the software writes into the DMAMUX_RGCFR register. This can happen when
multiple DMA channels operate with the DMAMUX request generator, and when an overrun can occur from more
than one request generator channel. As the OFx flag clear requires a write into the DMAMUX_RGCFR register
(to set the corresponding COFx bit), an overrun occurring in another DMAMUX channel operating with another
request generator channel during that write operation fails to raise the corresponding OFx flag.

Workaround
None. Avoid the use of request generator mode for concurrent DMAMUX channels, if at least two channels are
potentially generating a request generator overrun.

ES0548 - Rev 3 page 8/22

 STM32G0B1xB/xC/xE
ADC

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

Description
If a write access into the DMAMUX_CxCR register having the SE bit at zero and SPOL[1:0] bitfield at a value
other than 00:
• sets the SE bit (enables synchronization),
• modifies the values of the DMAREQ_ID[5:0] and SYNC_ID[4:0] bitfields, and
• does not modify the SPOL[1:0] bitfield,
and if a synchronization event occurs on the previously selected synchronization input exactly two AHB clock
cycles before this DMAMUX_CxCR write, then the input DMA request selected by the DMAREQ_ID[5:0] value
before that write is routed.

Workaround
Ensure that the SPOL[1:0] bitfield is at 00 whenever the SE bit is 0. When enabling synchronization by setting
the SE bit, always set the SPOL[1:0] bitfield to a value other than 00 with the same write operation into the
DMAMUX_CxCR register.

2.6 ADC

2.6.1 Overrun flag is not set if EOC reset coincides with new conversion end

Description
If the EOC flag is cleared by an ADC_DR register read operation or by software during the same APB cycle in
which the data from a new conversion are written in the ADC_DR register, the overrun event duly occurs (which
results in the loss of either current or new data) but the overrun flag (OVR) may stay low.

Workaround
Clear the EOC flag, by performing an ADC_DR read operation or by software within less than one ADC
conversion cycle period from the last conversion cycle end, in order to avoid the coincidence with the end of
the new conversion cycle.

2.6.2 Writing ADC_CFGR1 register while ADEN bit is set resets RES[1:0] bitfield

Description
Modifying the ADC_CFGR1 register while ADC is enabled (ADEN set in ADC_CR) resets RES[1:0] to 00
whatever the bitfield previous value.

Workaround
Apply the following sequence:
1. Set ADDIS to disable the ADC, and wait until ADEN is cleared.
2. Program the ADC_CFGR1 register according to the application requirements.
3. Set ADEN bit.

2.6.3 Out-of-threshold value is not detected in AWD1 Single mode

Description
AWD1 analog watchdog does not detect that the result of a converted channel has reached the programmed
threshold when the ADC operates in Single mode, performs a sequence of conversions, and one of the converted
channels other than the first one is monitored by the AWD1 analog watchdog.

ES0548 - Rev 3 page 9/22

 STM32G0B1xB/xC/xE
ADC

Workaround
Apply one of the following measures:
• Use a conversion sequence of one single channel.
• Configure the monitored channel as the first one of the sequence.

2.6.4 ADC sampling time might be one cycle longer

Description
For sampling time set to 1.5 or 3.5 cycles, the sampling in a single ADC conversion or in the first conversion of a
sequence takes one extra cycle.

Workaround
None.

2.6.5 ADC offset may be out of specification

Description
When the VREF+ voltage is lower than 3.0 V, the ADC hardware calibration may not fully compensate for the offset
error caused by the diffusion process variation. When this occurs, the CALFACT register value is either 0x00 or
0x7F and the EO parameter is out of the maximum stated in the device data sheet. To reflect this, the following
specification substitutes the one in the device datasheet:

Symbol Parameter Condition Min Typ Max Unit

2 V < VDDA = VREF+ < 3 V

fADC = 35 MHz, fs ≤ 2.5 Msps - 1.5 31
TA = entire range

EO Offset error 1.65 V < VDDA = VREF+ < 3 V

fADC = 35 MHz, fs ≤ 2.2 Msps
- 1.5 50
fADC = 16 MHz; fs ≤ 1.1 Msps
TA = entire range
LSB
2 V < VDDA = VREF+ < 3 V
fADC = 35 MHz, fs ≤ 2.5 Msps - 3 33
TA = entire range
Total
ET unadjusted 1.65 V < VDDA = VREF+ < 3 V
error
fADC = 35 MHz, fs ≤ 2.2 Msps
- 3 52
fADC = 16 MHz; fs ≤ 1.1 Msps
TA = entire range

ES0548 - Rev 3 page 10/22

 STM32G0B1xB/xC/xE
TIM

Workaround
Apply one of the following measures:
• Use VDDA and VREF+ higher than 3V.
• Use the ADC for measuring a difference between two DC voltages or for measuring AC voltages with a head
room to VREF+ and VSSA greater than the voltage corresponding to EO(max).
• In the hardware application, make VREF+ and VSSA available on the ADC GPIO inputs. Then if CALFACT
register value indicates 0x00 or 0x7F after the hardware calibration, compensate A/D conversions by
software for the ADC offset remaining after the hardware compensation as follows:
– For CALFACT equal to 0x00:
1. With the ADC, measure the VREF+ voltage through the GPIO channel. Subtract the A/D
conversion result from the full-scale value plus one (4096 for a 12-bit ADC), to obtain the offset
value. For example, if the A/D conversion result is 4093, the offset value is 3 (3 LSBs).
2. Add the offset value to any further A/D conversion result. For example, if the A/D conversion
result is 1550, the result after this compensation is 1553.
– For CALFACT equal to 0x7F:
1. With the ADC, measure the VSSA voltage through the GPIO channel, to obtain the offset value, for
example 4 (4 LSBs).
2. Subtract the offset value from any further A/D conversion result. For example, if the A/D
conversion result is 1550, the result after this compensation is 1546.
Note: For better accuracy of the remaining offset measurement, it is recommended to use an average of multiple
(for example eight) A/D conversions.
Note: The compensation for the offset remaining after the hardware calibration reduces the effective ADC
conversion range.

2.7 TIM

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

Description
The failure occurs when several timers configured in one-pulse mode are cascaded, and the master timer is
configured in combined reset + trigger mode with the MSM bit set:
OPM = 1 in TIMx_CR1, SMS[3:0] = 1000 and MSM = 1 in TIMx_SMCR.
The MSM delays the reaction of the master timer to the trigger event, so as to have the slave timers cycle-
accurately synchronized.
If the trigger arrives when the counter value is equal to the period value set in the TIMx_ARR register, the
one-pulse mode of the master timer does not work and no pulse is generated on the output.

Workaround
None. However, unless a cycle-level synchronization is mandatory, it is advised to keep the MSM bit reset, in
which case the problem is not present. The MSM = 0 configuration also allows decreasing the timer latency to
external trigger events.

2.7.2 Consecutive compare event missed in specific conditions

Description
Every match of the counter (CNT) value with the compare register (CCR) value is expected to trigger a compare
event. However, if such matches occur in two consecutive counter clock cycles (as consequence of the CCR
value change between the two cycles), the second compare event is missed for the following CCR value
changes:

ES0548 - Rev 3 page 11/22

 STM32G0B1xB/xC/xE
LPTIM

• in edge-aligned mode, from ARR to 0:

– first compare event: CNT = CCR = ARR
– second (missed) compare event: CNT = CCR = 0
• in center-aligned mode while up-counting, from ARR-1 to ARR (possibly a new ARR value if the period is
also changed) at the crest (that is, when TIMx_RCR = 0):
– first compare event: CNT = CCR = (ARR-1)
– second (missed) compare event: CNT = CCR = ARR
• in center-aligned mode while down-counting, from 1 to 0 at the valley (that is, when TIMx_RCR = 0):
– first compare event: CNT = CCR = 1
– second (missed) compare event: CNT = CCR = 0
This typically corresponds to an abrupt change of compare value aiming at creating a timer clock single-cycle-
wide pulse in toggle mode.
As a consequence:
• In toggle mode, the output only toggles once per counter period (squared waveform), whereas it is expected
to toggle twice within two consecutive counter cycles (and so exhibit a short pulse per counter period).
• In center mode, the compare interrupt flag does note rise and the interrupt is not generated.
Note: The timer output operates as expected in modes other than the toggle mode.

Workaround
None.

2.7.3 Output compare clear not working with external counter reset

Description
The output compare clear event (ocref_clr) is not correctly generated when the timer is configured in the following
slave modes: Reset mode, Combined reset + trigger mode, and Combined gated + reset mode.
The PWM output remains inactive during one extra PWM cycle if the following sequence occurs:
1. The output is cleared by the ocref_clr event.
2. The timer reset occurs before the programmed compare event.

Workaround
Apply one of the following measures:
• Use BKIN (or BKIN2 if available) input for clearing the output, selecting the Automatic output enable mode
(AOE = 1).
• Mask the timer reset during the PWM ON time to prevent it from occurring before the compare event (for
example with a spare timer compare channel open-drain output connected with the reset signal, pulling the
timer reset line down).

2.8 LPTIM

2.8.1 Device may remain stuck in LPTIM interrupt when entering Stop mode

Description
This limitation occurs when disabling the low-power timer (LPTIM).
When the user application clears the ENABLE bit in the LPTIM_CR register within a small time window around
one LPTIM interrupt occurrence, then the LPTIM interrupt signal used to wake up the device from Stop mode may
be frozen in active state. Consequently, when trying to enter Stop mode, this limitation prevents the device from
entering low-power mode and the firmware remains stuck in the LPTIM interrupt routine.
This limitation applies to all Stop modes and to all instances of the LPTIM. Note that the occurrence of this issue
is very low.

ES0548 - Rev 3 page 12/22

 STM32G0B1xB/xC/xE
RTC and TAMP

Workaround
In order to disable a low power timer (LPTIMx) peripheral, do not clear its ENABLE bit in its respective LPTIM_CR
register. Instead, reset the whole LPTIMx peripheral via the RCC controller by setting and resetting its respective
LPTIMxRST bit in RCC_APByRSTRz register.

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

Description
This limitation occurs when the LPTIM is configured in interrupt mode (at least one interrupt is enabled) and
the software clears any flag in LPTIM_ISR register by writing its corresponding bit in LPTIM_ICR register. If the
interrupt status flag corresponding to a disabled interrupt is cleared simultaneously with a new event detection,
the set and clear commands might reach the APB domain at the same time, leading to an asynchronous interrupt
signal permanently stuck high.
This issue can occur either during an interrupt subroutine execution (where the flag clearing is usually done), or
outside an interrupt subroutine.
Consequently, the firmware remains stuck in the LPTIM interrupt routine, and the device cannot enter Stop mode.

Workaround
To avoid this issue, it is strongly advised to follow the recommendations listed below:
• Clear the flag only when its corresponding interrupt is enabled in the interrupt enable register.
• If for specific reasons, it is required to clear some flags that have corresponding interrupt lines disabled in
the interrupt enable register, it is recommended to clear them during the current subroutine prior to those
which have corresponding interrupt line enabled in the interrupt enable register.
• Flags must not be cleared outside the interrupt subroutine.
Note: The standard clear sequence implemented in the HAL_LPTIM_IRQHandler in the STM32Cube is considered as
the proper clear sequence.

2.9 RTC and TAMP

2.9.1 Calendar initialization may fail in case of consecutive INIT mode entry

Description
If the INIT bit of the RTC_ICSR register is set between one and two RTCCLK cycles after being cleared, the
INITF flag is set immediately instead of waiting for synchronization delay (which should be between one and two
RTCCLK cycles), and the initialization of registers may fail. Depending on the INIT bit clearing and setting instants
versus the RTCCLK edges, it can happen that, after being immediately set, the INITF flag is cleared during one
RTCCLK period then set again. As writes to calendar registers are ignored when INITF is low, a write occurring
during this critical period might result in the corruption of one or more calendar registers.

Workaround
After existing the initialization mode, clear the BYPSHAD bit (if set) then wait for RSF to rise, before entering the
initialization mode again.
Note: It is recommended to write all registers in a single initialization session to avoid accumulating synchronization
delays.

ES0548 - Rev 3 page 13/22

 STM32G0B1xB/xC/xE
I2C

2.10 I2C

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

Description

The I2C-bus specification and user manual specify a minimum data setup time (tSU;DAT) as:
• 250 ns in Standard mode
• 100 ns in Fast mode
• 50 ns in Fast mode Plus
The device does not correctly sample the I2C-bus SDA line when tSU;DAT is smaller than one I2C kernel clock
(I2C-bus peripheral clock) period: the previous SDA value is sampled instead of the current one. This can result in
a wrong receipt of slave address, data byte, or acknowledge bit.

Workaround
Increase the I2C kernel clock frequency to get I2C kernel clock period within the transmitter minimum data setup
time. Alternatively, increase transmitter’s minimum data setup time. If the transmitter setup time minimum value
corresponds to the minimum value provided in the I2C-bus standard, the minimum I2CCLK frequencies are as
follows:
• In Standard mode, if the transmitter minimum setup time is 250 ns, the I2CCLK frequency must be at least
4 MHz.
• In Fast mode, if the transmitter minimum setup time is 100 ns, the I2CCLK frequency must be at least
10 MHz.
• In Fast-mode Plus, if the transmitter minimum setup time is 50 ns, the I2CCLK frequency must be at least
20 MHz.

2.10.2 Spurious bus error detection in master mode

Description
In master mode, a bus error can be detected spuriously, with the consequence of setting the BERR flag of the
I2C_SR register and generating bus error interrupt if such interrupt is enabled. Detection of bus error has no effect
on the I2C-bus transfer in master mode and any such transfer continues normally.

Workaround
If a bus error interrupt is generated in master mode, the BERR flag must be cleared by software. No other action
is required and the ongoing transfer can be handled normally.

2.11 USART

2.11.1 Data corruption due to noisy receive line

Description
In UART mode with oversampling by 8 or 16 and with 1 or 2 stop bits, the received data may be corrupted if a
glitch to zero shorter than the half-bit occurs on the receive line within the second half of the stop bit.

Workaround
None.

ES0548 - Rev 3 page 14/22

 STM32G0B1xB/xC/xE
SPI

2.11.2 USART prescaler feature missing in USART implementation section

Description
Some reference manual revisions may omit the information that the USART prescaler is not present in all USART
instances. This information is provided in the USART implementation section of the corresponding reference
manual.
This is a documentation issue rather than a product limitation.

Workaround
No application workaround is required or applicable.

2.12 SPI

2.12.1 BSY bit may stay high when SPI is disabled

Description
The BSY flag may remain high upon disabling the SPI while operating in:
• master transmit mode and the TXE flag is low (data register full).
• master receive-only mode (simplex receive or half-duplex bidirectional receive phase) and an SCK strobing
edge has not occurred since the transition of the RXNE flag from low to high.
• slave mode and NSS signal is removed during the communication.

Workaround
When the SPI operates in:
• master transmit mode, disable the SPI when TXE = 1 and BSY = 0.
• master receive-only mode, ignore the BSY flag.
• slave mode, do not remove the NSS signal during the communication.

2.12.2 BSY bit may stay high at the end of data transfer in slave mode

Description
BSY flag may sporadically remain high at the end of a data transfer in slave mode. This occurs upon coincidence
of internal CPU clock and external SCK clock provided by master.
In such an event, if the software only relies on BSY flag to detect the end of SPI slave data transaction (for
example to enter low-power mode or to change data line direction in half-duplex bidirectional mode), the detection
fails.
As a conclusion, the BSY flag is unreliable for detecting the end of data transactions.

Workaround
Depending on SPI operating mode, use the following means for detecting the end of transaction:
• When NSS hardware management is applied and NSS signal is provided by master, use NSS flag.
• In SPI receiving mode, use the corresponding RXNE event flag.
• In SPI transmit-only mode, use the BSY flag in conjunction with a timeout expiry event. Set the timeout such
as to exceed the expected duration of the last data frame and start it upon TXE event that occurs with the
second bit of the last data frame. The end of the transaction corresponds to either the BSY flag becoming
low or the timeout expiry, whichever happens first.
Prefer one of the first two measures to the third as they are simpler and less constraining.
Alternatively, apply the following sequence to ensure reliable operation of the BSY flag in SPI transmit mode:
1. Write last data to data register.
2. Poll the TXE flag until it becomes high, which occurs with the second bit of the data frame transfer.
3. Disable SPI by clearing the SPE bit mandatorily before the end of the frame transfer.
4. Poll the BSY bit until it becomes low, which signals the end of transfer.

ES0548 - Rev 3 page 15/22

 STM32G0B1xB/xC/xE
FDCAN

Note: The alternative method can only be used with relatively fast CPU speeds versus relatively slow SPI clocks
or/and long last data frames. The faster is the software execution, the shorter can be the duration of the last data
frame.

2.13 FDCAN

2.13.1 Desynchronization under specific condition with edge filtering enabled

Description
FDCAN may desynchronize and incorrectly receive the first bit of the frame if:
• the edge filtering is enabled (the EFBI bit of the FDCAN_CCCR register is set), and
• the end of the integration phase coincides with a falling edge detected on the FDCAN_Rx input pin
If this occurs, the CRC detects that the first bit of the received frame is incorrect, flags the received frame as faulty
and responds with an error frame.
Note: This issue does not affect the reception of standard frames.

Workaround
Disable edge filtering or wait for frame retransmission.

2.13.2 Tx FIFO messages inverted under specific buffer usage and priority setting

Description
Two consecutive messages from the Tx FIFO may be inverted in the transmit sequence if:
• FDCAN uses both a dedicated Tx buffer and a Tx FIFO (the TFQM bit of the FDCAN_TXBC register is
cleared), and
• the messages contained in the Tx buffer have a higher internal CAN priority than the messages in the Tx
FIFO.

Workaround
Apply one of the following measures:
• Ensure that only one Tx FIFO element is pending for transmission at any time:
The Tx FIFO elements may be filled at any time with messages to be transmitted, but their transmission
requests are handled separately. Each time a Tx FIFO transmission has completed and the Tx FIFO gets
empty (TFE bit of FDACN_IR set to 1) the next Tx FIFO element is requested.
• Use only a Tx FIFO:
Send both messages from a Tx FIFO, including the message with the higher priority. This message has to
wait until the preceding messages in the Tx FIFO have been sent.
• Use two dedicated Tx buffers (for example, use Tx buffer 4 and 5 instead of the Tx FIFO). The following
pseudo-code replaces the function in charge of filling the Tx FIFO:
Write message to Tx Buffer 4
Transmit Loop:
Request Tx Buffer 4 - write AR4 bit in FDCAN_TXBAR
Write message to Tx Buffer 5
Wait until transmission of Tx Buffer 4 complete (IR bit in FDCAN_IR),
read TO4 bit in FDCAN_TXBTO
Request Tx Buffer 5 - write AR5 bit of FDCAN_TXBAR
Write message to Tx Buffer 4
Wait until transmission of Tx Buffer 5 complete (IR bit in FDCAN_IR),
read TO5 bit in FDCAN_TXBTO

ES0548 - Rev 3 page 16/22

 STM32G0B1xB/xC/xE
UCPD

2.14 UCPD

2.14.1 UCPD transmitter output marginality at low temperature

Description
At low temperature, the UCPD transmitter high level may go as low as 1.04 V, not respecting the specified
minimum of 1.05 V. The external load (Rp/Rd) can mitigate this slight marginality observed on a low percentage of
parts.

Workaround
None.

ES0548 - Rev 3 page 17/22

 STM32G0B1xB/xC/xE

Important security notice

The STMicroelectronics group of companies (ST) places a high value on product security, which is why the
ST product(s) identified in this documentation may be certified by various security certification bodies and/or
may implement our own security measures as set forth herein. However, no level of security certification and/or
built-in security measures can guarantee that ST products are resistant to all forms of attacks. As such, it is the
responsibility of each of ST's customers to determine if the level of security provided in an ST product meets the
customer needs both in relation to the ST product alone, as well as when combined with other components and/or
software for the customer end product or application. In particular, take note that:
• ST products may have been certified by one or more security certification bodies, such as Platform
Security Architecture (www.psacertified.org) and/or Security Evaluation standard for IoT Platforms
(www.trustcb.com). For details concerning whether the ST product(s) referenced herein have received
security certification along with the level and current status of such certification, either visit the relevant
certification standards website or go to the relevant product page on www.st.com for the most up to date
information. As the status and/or level of security certification for an ST product can change from time to
time, customers should re-check security certification status/level as needed. If an ST product is not shown
to be certified under a particular security standard, customers should not assume it is certified.
• Certification bodies have the right to evaluate, grant and revoke security certification in relation to ST
products. These certification bodies are therefore independently responsible for granting or revoking
security certification for an ST product, and ST does not take any responsibility for mistakes, evaluations,
assessments, testing, or other activity carried out by the certification body with respect to any ST product.
• Industry-based cryptographic algorithms (such as AES, DES, or MD5) and other open standard technologies
which may be used in conjunction with an ST product are based on standards which were not developed
by ST. ST does not take responsibility for any flaws in such cryptographic algorithms or open technologies
or for any methods which have been or may be developed to bypass, decrypt or crack such algorithms or
technologies.
• While robust security testing may be done, no level of certification can absolutely guarantee protections
against all attacks, including, for example, against advanced attacks which have not been tested for, against
new or unidentified forms of attack, or against any form of attack when using an ST product outside of
its specification or intended use, or in conjunction with other components or software which are used
by customer to create their end product or application. ST is not responsible for resistance against such
attacks. As such, regardless of the incorporated security features and/or any information or support that
may be provided by ST, each customer is solely responsible for determining if the level of attacks tested
for meets their needs, both in relation to the ST product alone and when incorporated into a customer end
product or application.
• All security features of ST products (inclusive of any hardware, software, documentation, and the like),
including but not limited to any enhanced security features added by ST, are provided on an "AS
IS" BASIS. AS SUCH, TO THE EXTENT PERMITTED BY APPLICABLE LAW, ST DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, unless the applicable written and
signed contract terms specifically provide otherwise.

ES0548 - Rev 3 page 18/22

 STM32G0B1xB/xC/xE

Revision history
Table 5. Document revision history

Date Version Changes

12-Jan-2021 1 Initial release.

Added device variant Z.
Added section Important security notice.
Added errata:
• Device lock upon mismatch of option bytes
• Prefetch failure when branching across flash memory banks
• ADC offset may be out of specification
11-Apr-2022 2
Modified errata:
• Unstable LSI when it clocks RTC or CSS on LSE (BORRSTF corrected
to PWRRSTF)
• Overwriting with all zeros a flash memory location previously
programmed with all ones fails (a note added)
• Device may remain stuck in LPTIM interrupt when clearing event flag
(note modified)
Added:
• Section 2.2.11 Corrupted content of the RTC domain due to a missed
06-Oct-2022 3 power-on reset after this domain supply voltage drop
Updated:
• Section 2.6.5 ADC offset may be out of specification

ES0548 - Rev 3 page 19/22

 STM32G0B1xB/xC/xE
Contents

Contents
1 Summary of device errata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Description of device errata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Unstable LSI when it clocks RTC or CSS on LSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 WUFx wakeup flag wrongly set during configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Overwriting with all zeros a flash memory location previously programmed with all ones fails
......................................................................4
2.2.4 Wakeup from Stop not effective under certain conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.5 Flash memory PCROP area weakness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.6 PC13 signal transitions disturb LSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.7 SRAM contents corrupted upon entry in Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.8 Boot select after debug interface connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.9 Device lock upon mismatch of option bytes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.10 Prefetch failure when branching across flash memory banks . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.11 Corrupted content of the RTC domain due to a missed power-on reset after this domain
supply voltage drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 GPIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Wakeup capability-enabled GPIOs not configurable after wakeup from Standby . . . . . . . . 7
2.4 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 DMA disable failure and error flag omission upon simultaneous transfer error and global
flag clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 DMAMUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 SOFx not asserted when writing into DMAMUX_CFR register . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2 OFx not asserted for trigger event coinciding with last DMAMUX request . . . . . . . . . . . . . . 8
2.5.3 OFx not asserted when writing into DMAMUX_RGCFR register . . . . . . . . . . . . . . . . . . . . . 8
2.5.4 Wrong input DMA request routed upon specific DMAMUX_CxCR register write coinciding
with synchronization event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1 Overrun flag is not set if EOC reset coincides with new conversion end . . . . . . . . . . . . . . . 9
2.6.2 Writing ADC_CFGR1 register while ADEN bit is set resets RES[1:0] bitfield . . . . . . . . . . . . 9
2.6.3 Out-of-threshold value is not detected in AWD1 Single mode . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.4 ADC sampling time might be one cycle longer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6.5 ADC offset may be out of specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 TIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.1 One-pulse mode trigger not detected in master-slave reset + trigger configuration . . . . . . 11
2.7.2 Consecutive compare event missed in specific conditions . . . . . . . . . . . . . . . . . . . . . . . . 11

ES0548 - Rev 3 page 20/22

 STM32G0B1xB/xC/xE
Contents

2.7.3 Output compare clear not working with external counter reset . . . . . . . . . . . . . . . . . . . . . 12
2.8 LPTIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.1 Device may remain stuck in LPTIM interrupt when entering Stop mode . . . . . . . . . . . . . . 12
2.8.2 Device may remain stuck in LPTIM interrupt when clearing event flag . . . . . . . . . . . . . . . 13
2.9 RTC and TAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9.1 Calendar initialization may fail in case of consecutive INIT mode entry . . . . . . . . . . . . . . . 13
2.10 I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10.1 Wrong data sampling when data setup time (tSU;DAT) is shorter than one I2C kernel clock
period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10.2 Spurious bus error detection in master mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.11 USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.11.1 Data corruption due to noisy receive line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.11.2 USART prescaler feature missing in USART implementation section . . . . . . . . . . . . . . . . 15
2.12 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.12.1 BSY bit may stay high when SPI is disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.12.2 BSY bit may stay high at the end of data transfer in slave mode . . . . . . . . . . . . . . . . . . . . 15
2.13 FDCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.13.1 Desynchronization under specific condition with edge filtering enabled. . . . . . . . . . . . . . . 16
2.13.2 Tx FIFO messages inverted under specific buffer usage and priority setting . . . . . . . . . . . 16
2.14 UCPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.14.1 UCPD transmitter output marginality at low temperature. . . . . . . . . . . . . . . . . . . . . . . . . . 17
Important security notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

ES0548 - Rev 3 page 21/22

 STM32G0B1xB/xC/xE

IMPORTANT NOTICE – READ CAREFULLY

STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST
products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. ST
products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgment.
Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of
purchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
ST and the ST logo are trademarks of ST. For additional information about ST trademarks, refer to www.st.com/trademarks. All other product or service names
are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
© 2022 STMicroelectronics – All rights reserved

ES0548 - Rev 3 page 22/22