0% found this document useful (0 votes)
13 views

Es0569 stm32c011x4x6 Device Errata Stmicroelectronics

This document applies to the part numbers of STM32C011x4/x6 devices and the device variants as stated in this page.

Uploaded by

fred5678
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

Es0569 stm32c011x4x6 Device Errata Stmicroelectronics

This document applies to the part numbers of STM32C011x4/x6 devices and the device variants as stated in this page.

Uploaded by

fred5678
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

STM32C011x4/x6

Errata sheet

STM32C011x4/x6 device errata

Applicability
This document applies to the part numbers of STM32C011x4/x6 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 RM0490.
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

STM32C011xx STM32C011J6, STM32C011J4, STM32C011F6, STM32C011F4, STM32C011D6

Table 2. Device variants

Silicon revision codes


Reference
Device marking(1) REV_ID(2)

A 0x1000
STM32C011xx
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.

ES0569 - Rev 4 - June 2023 www.st.com


For further information contact your local STMicroelectronics sales office.
STM32C011x4/x6
Summary of device errata

1 Summary of device errata

The following table gives a quick reference to the STM32C011x4/x6 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 HSI48 clock fails to stop upon entering Stop mode A -


2.2.2 PA11 Schmitt trigger remains effective in analog input mode P -
System 2.2.3 Missed wakeup event coinciding with Stop entry A -
2.2.4 A non-zero HSIDIV[2:0] upon Stop entry may lead to a deadlock A -
2.2.5 First SRAM access after reset fails A -
DMA disable failure and error flag omission upon simultaneous transfer
DMA 2.3.1 A A
error and global flag clear
2.4.1 SOFx not asserted when writing into DMAMUX_CCFR register N N
2.4.2 OFx not asserted for trigger event coinciding with last DMAMUX request N N
DMAMUX 2.4.3 OFx not asserted when writing into DMAMUX_RGCFR register N N
Wrong input DMA request routed upon specific DMAMUX_CxCR register
2.4.4 A A
write coinciding with synchronization event
ADC 2.5.1 Overrun flag is not set if EOC reset coincides with new conversion end P P
One-pulse mode trigger not detected in master-slave reset + trigger
2.6.1 P P
configuration
TIM
2.6.2 Consecutive compare event missed in specific conditions N N
2.6.3 Output compare clear not working with external counter reset P P
2.7.1 Calendar initialization may fail in case of consecutive INIT mode entry A A
RTC 2.7.2 Alarm flag may be repeatedly set when the core is stopped in debug N N
2.7.3 Loss of RTC calendar and configuration content upon system reset N N
Wrong data sampling when data setup time (tSU;DAT) is shorter than one
2.8.1 P P
I2C kernel clock period
2.8.2 Spurious bus error detection in master mode A A
I2C
2.8.3 OVR flag not set in underrun condition N N
2.8.4 Transmission stalled after first byte transfer A A
2.8.5 SDA held low upon SMBus timeout expiry in slave mode A A
2.9.1 Anticipated end-of-transmission signaling in SPI slave mode A A
2.9.2 Data corruption due to noisy receive line N N
USART
2.9.3 Received data may be corrupted upon clearing the ABREN bit A A
2.9.4 Noise error flag set while ONEBIT is set N N

ES0569 - Rev 4 page 2/17


STM32C011x4/x6
Summary of device errata

Status
Function Section Limitation Rev. Rev.
A Z

2.10.1 BSY bit may stay high when SPI is disabled A A


SPI
2.10.2 BSY bit may stay high at the end of data transfer in slave mode A A

ES0569 - Rev 4 page 3/17


STM32C011x4/x6
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 HSI48 clock fails to stop upon entering Stop mode

Description
Upon entering Stop mode, all running clocks are expected to automatically stop, to save power.
However, with LSI or LSE selected as system clock, the HSI48 oscillator continues running, which impacts power
consumption.

Workaround
Disable the HSI48 oscillator before entering Stop mode.

2.2.2 PA11 Schmitt trigger remains effective in analog input mode

Description
The input buffer Schmitt trigger on the PA11 GPIO unduly remains effective in analog input mode. This may lead
to an increased power consumption when PA11 is left floating and/or when the input voltage on PA11 used as
analog input is near the GPIO input thresholds.

Workaround
When PA11 is unused, apply a weak pull-up or pull-down device internally or externally to keep the input voltage
far from the GPIO input thresholds.

2.2.3 Missed wakeup event coinciding with Stop entry

Description
When a wakeup event occurs at the same time or one CPU cycle before the core requests to enter Stop mode,
the event may be missed. The device then remains in Stop mode until the following wakeup event.

Workaround
Apply the following steps:
1. Clear the pending events to enter the WFE.
2. Configure both EXTI_EMR1 and EXTI_IMR1 simultaneously to allow the event controller to generate event
and interrupt.
Note: The CPU has to clear the pending interrupt in the EXTI after waking up from WFE (EXTI_RPR1 and
EXTI_FPR1).
The following table shows some examples:

ES0569 - Rev 4 page 4/17


STM32C011x4/x6
DMA

Event and interrupt setup SW setup Interrupt clearing

EXTI_EMR1 = EVT1 EXTI_RTSR1 = EVT1 EXTI_RPR1 = EVT1


EXTI_IMR1 = EVT1 WFE EXTI_FPR1 = EVT1

2.2.4 A non-zero HSIDIV[2:0] upon Stop entry may lead to a deadlock

Description
A non-zero value of the HSIDIV[2:0] bitfield upon entering Stop mode may cause a deadlock in which the device
fails to wake up.

Workaround
Write HSIDIV[2:0] with 0x0 before entering Stop mode and restore the former value upon wakeup.

2.2.5 First SRAM access after reset fails

Description
When asynchronous system reset occurs in a critical phase of SRAM write access, the SRAM controller remains
in a state that causes the first SRAM access after the asynchronous system reset to fail. Any further SRAM
accesses operate as expected.
As the probability of occurrence is extremely low, the failure is rare and difficult to reproduce.

Workaround
Always perform a dummy SRAM access after reset, such as:
MOV32 R0, #0x20000000 //set SRAM address
LDR R1, [R0, #+0] //read access

2.3 DMA

2.3.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.

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.4 DMAMUX

2.4.1 SOFx not asserted when writing into DMAMUX_CCFR 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_CCFR register.

ES0569 - Rev 4 page 5/17


STM32C011x4/x6
DMAMUX

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_CCFR 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.4.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.4.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.

2.4.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.

ES0569 - Rev 4 page 6/17


STM32C011x4/x6
ADC

2.5 ADC

2.5.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 TIM

2.6.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.6.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:
• 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:

ES0569 - Rev 4 page 7/17


STM32C011x4/x6
RTC

• 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.6.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.7 RTC

2.7.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.

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

Description
When the core is stopped in debug mode, the clock is supplied to subsecond RTC alarm downcounter even when
the device is configured to stop the RTC in debug.
As a consequence, when the subsecond counter is used for alarm condition (the MASKSS[3:0] bitfield of the
RTC_ALRMASSR and/or RTC_ALRMBSSR register set to a non-zero value) and the alarm condition is met just
before entering a breakpoint or printf, the ALRAF and/or ALRBF flag of the RTC_SR register is repeatedly set by
hardware during the breakpoint or printf, which makes any attempt to clear the flag(s) ineffective.

ES0569 - Rev 4 page 8/17


STM32C011x4/x6
I2C

Workaround
None.

2.7.3 Loss of RTC calendar and configuration content upon system reset

Description
The system reset unduly resets the RTC registers. As a consequence, the RTC calendar and the configuration
contents are lost.

Workaround
None.

2.8 I2C

2.8.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.8.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.

ES0569 - Rev 4 page 9/17


STM32C011x4/x6
I2C

2.8.3 OVR flag not set in underrun condition

Description
In slave transmission with clock stretching disabled (NOSTRETCH = 1 in the I2C_CR1 register), an underrun
condition occurs if the current byte transmission is completed on the I2C bus, and the next data is not yet written
in the TXDATA[7:0] bitfield. In this condition, the device is expected to set the OVR flag of the I2C_ISR register
and send 0xFF on the bus.
However, if the I2C_TXDR is written within the interval between two I2C kernel clock cycles before and three APB
clock cycles after the start of the next data transmission, the OVR flag is not set, although the transmitted value is
0xFF.

Workaround
None.

2.8.4 Transmission stalled after first byte transfer

Description
When the first byte to transmit is not prepared in the TXDATA register, two bytes are required successively,
through TXIS status flag setting or through a DMA request. If the first of the two bytes is written in the I2C_TXDR
register in less than two I2C kernel clock cycles after the TXIS/DMA request, and the ratio between APB clock
and I2C kernel clock frequencies is between 1.5 and 3, the second byte written in the I2C_TXDR is not internally
detected. This causes a state in which the I2C peripheral is stalled in master mode or in slave mode, with clock
stretching enabled (NOSTRETCH = 0). This state can only be released by disabling the peripheral (PE = 0) or by
resetting it.

Workaround
Apply one of the following measures:
• Write the first data in I2C_TXDR before the transmission starts.
• Set the APB clock frequency so that its ratio with respect to the I2C kernel clock frequency is lower than
1.5 or higher than 3.

2.8.5 SDA held low upon SMBus timeout expiry in slave mode

Description
For the slave mode, the SMBus specification defines tTIMEOUT (detect clock low timeout) and tLOW:SEXT
(cumulative clock low extend time) timeouts. When one of them expires while the I2C peripheral in slave mode
drives SDA low to acknowledge either its address or a data transmitted by the master, the device is expected to
report such an expiry and release the SDA line.
However, although the device duly reports the timeout expiry, it fails to release SDA. This stalls the I2C bus and
prevents the master from generating RESTART or STOP condition.

Workaround
When a timeout is reported in slave mode (TIMEOUT bit of the I2C_ISR register is set), apply this sequence:
1. Wait until the frame is expected to end.
2. Read the STOPF bit of the I2C_ISR register. If it is low, reset the I2C kernel by clearing the PE bit of the
I2C_CR1 register.
3. Wait for at least three APB clock cycles before enabling again the I2C peripheral.

ES0569 - Rev 4 page 10/17


STM32C011x4/x6
USART

2.9 USART

2.9.1 Anticipated end-of-transmission signaling in SPI slave mode

Description
In SPI slave mode, at low USART baud rate with respect to the USART kernel and APB clock frequencies, the
transmission complete flag TC of the USARTx_ISR register may unduly be set before the last bit is shifted on the
transmit line.
This leads to data corruption if, based on this anticipated end-of-transmission signaling, the application disables
the peripheral before the last bit is transmitted.

Workaround
Upon the TC flag rise, wait until the clock line remains idle for more than the half of the communication clock
cycle. Then only consider the transmission as ended.

2.9.2 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.

2.9.3 Received data may be corrupted upon clearing the ABREN bit

Description
The USART receiver may miss data or receive corrupted data when the auto baud rate feature is disabled by
software (ABREN bit cleared in the USART_CR2 register) after an auto baud rate detection, while a reception is
ongoing.

Workaround
Do not clear the ABREN bit.

2.9.4 Noise error flag set while ONEBIT is set

Description
When the ONEBIT bit is set in the USART_CR3 register (one sample bit method is used), the noise error (NE)
flag must remain cleared. Instead, this flag is set upon noise detection on the START bit.

Workaround
None.
Note: Having noise on the START bit is contradictory with the fact that the one sample bit method is used in a noise
free environment.

2.10 SPI

2.10.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).

ES0569 - Rev 4 page 11/17


STM32C011x4/x6
SPI

• 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.10.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.
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.

ES0569 - Rev 4 page 12/17


STM32C011x4/x6

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.

ES0569 - Rev 4 page 13/17


STM32C011x4/x6

Revision history
Table 4. Document revision history

Date Version Changes

24-Mar-2022 1 Initial release.


Added Z product revision definition and updated Table 1. Device summary,
Table 2. Device variants, and Table 3. Summary of device limitations.
Added Important security notice.
Updated RTC function name.
15-Sep-2022 2
Removed errata:
• ADC: Writing ADC_CFGR1 register while ADEN bit is set resets
RES[1:0] bitfield
• Out-of-threshold value is not detected in AWD1 Single mode
• I2C: Spurious master transfer upon own slave address match
First public release.
Added I2C erratum SDA held low upon SMBus timeout expiry in slave mode
01-Dec-2022 3
and updated Table 3. Summary of device limitations.
Corrected core type information.
Added errata:
• RTC: Loss of RTC calendar and configuration content upon system
reset
• I2C: OVR flag not set in underrun condition
• Transmission stalled after first byte transfer
22-Jun-2023 4
• USART: Anticipated end-of-transmission signaling in SPI slave mode
• Received data may be corrupted upon clearing the ABREN bit
• Noise error flag set while ONEBIT is set
Removed erratum REFCKON write protection associated to INIT KEY instead
of CAL KEY.

ES0569 - Rev 4 page 14/17


STM32C011x4/x6
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 HSI48 clock fails to stop upon entering Stop mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 PA11 Schmitt trigger remains effective in analog input mode . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Missed wakeup event coinciding with Stop entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.4 A non-zero HSIDIV[2:0] upon Stop entry may lead to a deadlock . . . . . . . . . . . . . . . . . . . . 5
2.2.5 First SRAM access after reset fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 DMA disable failure and error flag omission upon simultaneous transfer error and
global flag clear. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 DMAMUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1 SOFx not asserted when writing into DMAMUX_CCFR register . . . . . . . . . . . . . . . . . . . . . 5
2.4.2 OFx not asserted for trigger event coinciding with last DMAMUX request . . . . . . . . . . . . . . 6
2.4.3 OFx not asserted when writing into DMAMUX_RGCFR register . . . . . . . . . . . . . . . . . . . . . 6
2.4.4 Wrong input DMA request routed upon specific DMAMUX_CxCR register write
coinciding with synchronization event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.1 Overrun flag is not set if EOC reset coincides with new conversion end . . . . . . . . . . . . . . . 7
2.6 TIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.1 One-pulse mode trigger not detected in master-slave reset + trigger configuration . . . . . . . 7
2.6.2 Consecutive compare event missed in specific conditions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.3 Output compare clear not working with external counter reset . . . . . . . . . . . . . . . . . . . . . . 8
2.7 RTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7.1 Calendar initialization may fail in case of consecutive INIT mode entry . . . . . . . . . . . . . . . . 8
2.7.2 Alarm flag may be repeatedly set when the core is stopped in debug . . . . . . . . . . . . . . . . . 8
2.7.3 Loss of RTC calendar and configuration content upon system reset . . . . . . . . . . . . . . . . . . 9
2.8 I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8.1 Wrong data sampling when data setup time (tSU;DAT) is shorter than one I2C kernel
clock period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8.2 Spurious bus error detection in master mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8.3 OVR flag not set in underrun condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8.4 Transmission stalled after first byte transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8.5 SDA held low upon SMBus timeout expiry in slave mode . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9 USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.9.1 Anticipated end-of-transmission signaling in SPI slave mode . . . . . . . . . . . . . . . . . . . . . . 11

ES0569 - Rev 4 page 15/17


STM32C011x4/x6
Contents

2.9.2 Data corruption due to noisy receive line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11


2.9.3 Received data may be corrupted upon clearing the ABREN bit. . . . . . . . . . . . . . . . . . . . . 11
2.9.4 Noise error flag set while ONEBIT is set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.10 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.10.1 BSY bit may stay high when SPI is disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.10.2 BSY bit may stay high at the end of data transfer in slave mode . . . . . . . . . . . . . . . . . . . . 12
Important security notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

ES0569 - Rev 4 page 16/17


STM32C011x4/x6

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.
© 2023 STMicroelectronics – All rights reserved

ES0569 - Rev 4 page 17/17

You might also like