STMicroelectronics STM32G431C6, STM32G431C8, STM32G431CB, STM32G431K6, STM32G431K8 Datasheet

STM32G431xx STM32G441xx

Errata sheet

STM32G431xx/441xx device errata

Applicability

This document applies to the part numbers of STM32G431xx/441xx 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 RM0440.

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
	STM32G431C6, STM32G431C8, STM32G431CB, STM32G431K6, STM32G431K8, STM32G431KB,
STM32G431xx	STM32G431M6, STM32G431M8, STM32G431MB, STM32G431R6, STM32G431R8, STM32G431RB,
	STM32G431V6, STM32G431V8, STM32G431VB
STM32G441xx	STM32G441CB, STM32G441KB, STM32G441MB, STM32G441RB, STM32G441VB

Table 2. Device variants

Reference		Silicon revision codes
	Device marking(1)		REV_ID(2)
STM32G431xx/441xx	Z		0x2001
STM32G431xx/441xx	Y		0x2002
STM32G431xxx/441xx	X		0x2003

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.

ES0431 - Rev 7 - April 2021	www.st.com
For further information contact your local STMicroelectronics sales office.

STM32G431xx STM32G441xx

Summary of device errata

1Summary of device errata

The following table gives a quick reference to the STM32G431xx/441xx device limitations and their status: A = workaround available

N = no workaround available

P = partial workaround available

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.	Rev.
				Z	Y	X
		2.1.1	Interrupted loads to SP can cause erroneous behavior	A	A	A
	Core	2.1.2	VDIV or VSQRT instructions might not complete correctly when very	A	A	A
			short ISRs are used
		2.1.3	Store immediate overlapping exception return operation might vector	A	A	A
			to incorrect interrupt
		2.2.1	Full JTAG configuration without NJTRST pin cannot be used	A	A	A
		2.2.2	FLASH_ECCR corrupted upon reset or power-down occurring during	A	A	A
			Flash memory program or erase operation
	System
		2.2.3	Unstable LSI when it clocks RTC or CSS on LSE	P	P	P
		2.2.4	PCROP_RDP option bit production value not inline with the	N	-	-
			specification
	DMA	2.3.1	DMA disable failure and error flag omission upon simultaneous	A	A	A
			transfer error and global flag clear
		2.4.1	SOFx not asserted when writing into DMAMUX_CFR register	N	N	N
		2.4.2	OFx not asserted for trigger event coinciding with last DMAMUX	N	N	N
			request
	DMAMUX
		2.4.3	OFx not asserted when writing into DMAMUX_RGCFR register	N	N	N
		2.4.4	Wrong input DMA request routed upon specific DMAMUX_CxCR	A	A	A
			register write coinciding with synchronization event
		2.5.1	New context conversion initiated without waiting for trigger when	A	A	A
			writing new context in ADC_JSQR with JQDIS = 0 and JQM = 0
			Two consecutive context conversions fail when writing new context
		2.5.2	in ADC_JSQR just after previous context completion with JQDIS = 0	A	A	A
			and JQM = 0
		2.5.3	Unexpected regular conversion when two consecutive injected	A	A	A
			conversions are performed in Dual interleaved mode
	ADC
		2.5.4	ADC_AWDy_OUT reset by non-guarded channels	A	A	A
		2.5.5	End of 10/8/6-bit ADC conversion disturbing other ADCs	A	-	-
		2.5.6	ADC input channel switching disturbs ongoing conversions	P	-	-
		2.5.7	Wrong ADC result if conversion done late after calibration or previous	A	A	A
			conversion
		2.5.8	ADC channel 0 converted instead of the required ADC channel	-	A	-
	COMP	2.6.1	Comparator previously not fully tested in production	N	N	-

ES0431 - Rev 7	page 2/28

STM32G431xx STM32G441xx

Summary of device errata

					Status
	Function	Section	Limitation	Rev.	Rev.	Rev.
				Z	Y	X
	OPAMP	2.7.1	OPAMP disturbed by fast-edge toggle on GPIO pin corresponding to	P	P	P
			VINM0
		2.8.1	One-pulse mode trigger not detected in master-slave reset + trigger	P	P	P
			configuration
	TIM	2.8.2	Consecutive compare event missed in specific conditions	N	N	N
		2.8.3	Compare event missed in center-aligned mode 1 and 2 with dithering	N	N	N
			enabled
		2.8.4	Output compare clear not working with external counter reset	P	P	P
		2.9.1	Device may remain stuck in LPTIM interrupt when entering Stop	A	A	A
			mode
	LPTIM
		2.9.2	Device may remain stuck in LPTIM interrupt when clearing event flag	P	P	P
		2.9.3	LPTIM events and PWM output are delayed by 1 kernel clock cycle	P	P	P
		2.10.1	Calendar initialization may fail in case of consecutive INIT mode entry	A	A	A
		2.10.2	Alarm flag may be repeatedly set when the core is stopped in debug	N	N	N
		2.10.3	A tamper event fails to trigger timestamp or timestamp overflow	N	N	N
	RTC and TAMP		events during a few cycles after clearing TSF
		2.10.4	REFCKON write protection associated to INIT KEY instead of CAL	A	A	A
			KEY
		2.10.5	Tamper flag not set on LSE failure detection	N	N	N
		2.11.1	Wrong data sampling when data setup time (tSU;DAT) is shorter than	P	P	P
			one I2C kernel clock period
		2.11.2	Spurious bus error detection in master mode	A	A	A
	I2C
		2.11.3	Spurious master transfer upon own slave address match	P	P	P
		2.11.4	OVR flag not set in underrun condition	N	N	N
		2.11.5	Transmission stalled after first byte transfer	A	A	A
	USART	2.12.1	Anticipated end-of-transmission signaling in SPI slave mode	A	A	A
		2.12.2	Data corruption due to noisy receive line	N	N	N
	SPI	2.13.1	BSY bit may stay high when SPI is disabled	A	A	A
		2.13.2	BSY bit may stay high at the end of data transfer in slave mode	A	A	A
		2.14.1	Desynchronization under specific condition with edge filtering enabled	A	A	A
	FDCAN
		2.14.2	Tx FIFO messages inverted under specific buffer usage and priority	A	A	A
			setting
	USB	2.15.1	ESOF interrupt timing desynchronized after resume signaling	A	A	A
		2.15.2	Incorrect CRC16 in the memory buffer	N	N	N

ES0431 - Rev 7	page 3/28

STM32G431xx STM32G441xx

Description of device errata

2Description of device errata

	The following sections describe limitations of the applicable devices with Arm® core and provide workarounds if
	available. They are grouped by device functions.
Note:	Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

2.1Core

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

2.1.1Interrupted loads to SP can cause erroneous behavior

This limitation is registered under Arm ID number 752770 and classified into “Category B”. Its impact to the device is minor.

Description

If an interrupt occurs during the data-phase of a single word load to the stack-pointer (SP/R13), erroneous behavior can occur. In all cases, returning from the interrupt will result in the load instruction being executed an additional time. For all instructions performing an update to the base register, the base register will be erroneously updated on each execution, resulting in the stack-pointer being loaded from an incorrect memory location.

The affected instructions that can result in the load transaction being repeated are:

•LDR SP, [Rn],#imm

•LDR SP, [Rn,#imm]!

•LDR SP, [Rn,#imm]

•LDR SP, [Rn]

•LDR SP, [Rn,Rm]

The affected instructions that can result in the stack-pointer being loaded from an incorrect memory address are:

•LDR SP,[Rn],#imm

•LDR SP,[Rn,#imm]!

As compilers do not generate these particular instructions, the limitation is only likely to occur with hand-written assembly code.

Workaround

Both issues may be worked around by replacing the direct load to the stack-pointer, with an intermediate load to a general-purpose register followed by a move to the stack-pointer.

2.1.2VDIV or VSQRT instructions might not complete correctly when very short ISRs are used

This limitation is registered under Arm ID number 776924 and classified into “Category B”. Its impact to the device is limited.

Description

The VDIV and VSQRT instructions take 14 cycles to execute. When an interrupt is taken a VDIV or VSQRT instruction is not terminated, and completes its execution while the interrupt stacking occurs. If lazy context save of floating point state is enabled then the automatic stacking of the floating point context does not occur until a floating point instruction is executed inside the interrupt service routine.

Lazy context save is enabled by default. When it is enabled, the minimum time for the first instruction in the interrupt service routine to start executing is 12 cycles. In certain timing conditions, and if there is only one or two instructions inside the interrupt service routine, then the VDIV or VSQRT instruction might not write its result to the register bank or to the FPSCR.

ES0431 - Rev 7	page 4/28

STM32G431xx STM32G441xx

Core

The failure occurs when the following condition is met:

1.The floating point unit is enabled

2.Lazy context saving is not disabled

3.A VDIV or VSQRT is executed

4.The destination register for the VDIV or VSQRT is one of s0 - s15

5.An interrupt occurs and is taken

6.The interrupt service routine being executed does not contain a floating point instruction

7.Within 14 cycles after the VDIV or VSQRT is executed, an interrupt return is executed

A minimum of 12 of these 14 cycles are utilized for the context state stacking, which leaves 2 cycles for instructions inside the interrupt service routine, or 2 wait states applied to the entire stacking sequence (which means that it is not a constant wait state for every access).

In general, this means that if the memory system inserts wait states for stack transactions (that is, external memory is used for stack data), then this erratum cannot be observed.

The effect of this erratum is that the VDIV or VQSRT instruction does not complete correctly and the register bank and FPSCR are not updated, which means that these registers hold incorrect, out of date, data.

Workaround

A workaround is only required if the floating point unit is enabled. A workaround is not required if the stack is in external memory.

There are two possible workarounds:

•Disable lazy context save of floating point state by clearing LSPEN to 0 (bit 30 of the FPCCR at address 0xE000EF34).

•Ensure that every interrupt service routine contains more than 2 instructions in addition to the exception return instruction.

2.1.3Store immediate overlapping exception return operation might vector to incorrect interrupt

This limitation is registered under Arm ID number 838869 and classified into “Category B (rare)”. Its impact to the device is minor.

Description

The core includes a write buffer that permits execution to continue while a store is waiting on the bus. Under specific timing conditions, during an exception return while this buffer is still in use by a store instruction, a late change in selection of the next interrupt to be taken might result in there being a mismatch between the interrupt acknowledged by the interrupt controller and the vector fetched by the processor.

The failure occurs when the following condition is met:

1.The handler for interrupt A is being executed.

2.Interrupt B, of the same or lower priority than interrupt A, is pending.

3.A store with immediate offset instruction is executed to a bufferable location.

–STR/STRH/STRB <Rt>, [<Rn>,#imm]

–STR/STRH/STRB <Rt>, [<Rn>,#imm]!

–STR/STRH/STRB <Rt>, [<Rn>],#imm

4.Any number of additional data-processing instructions can be executed.

5.A BX instruction is executed that causes an exception return.

6.The store data has wait states applied to it such that the data is accepted at least two cycles after the BX is executed.

–Minimally, this is two cycles if the store and the BX instruction have no additional instructions between them.

–The number of wait states required to observe this erratum needs to be increased by the number of cycles between the store and the interrupt service routine exit instruction.

7.Before the bus accepts the buffered store data, another interrupt C is asserted which has the same or lower priority as A, but a greater priority than B.

Example:

ES0431 - Rev 7	page 5/28

STM32G431xx STM32G441xx

System

The processor should execute interrupt handler C, and on completion of handler C should execute the handler for B. If the conditions above are met, then this erratum results in the processor erroneously clearing the pending state of interrupt C, and then executing the handler for B twice. The first time the handler for B is executed it

will be at interrupt C's priority level. If interrupt C is pended by a level-based interrupt which is cleared by C's handler then interrupt C will be pended again once the handler for B has completed and the handler for C will be executed.

As the STM32 interrupt C is level based, it eventually becomes pending again and is subsequently handled.

Workaround

For software not using the memory protection unit, this erratum can be worked around by setting DISDEFWBUF in the Auxiliary Control Register.

In all other cases, the erratum can be avoided by ensuring a DSB occurs between the store and the BX instruction. For exception handlers written in C, this can be achieved by inserting the appropriate set of intrinsics or inline assembly just before the end of the interrupt function, for example:

ARMCC:

...

__schedule_barrier(); __asm{DSB}; __schedule_barrier();

}

GCC:

...

__asm volatile ("dsb 0xf":::"memory");

}

2.2System

2.2.1Full JTAG configuration without NJTRST pin cannot be used

Description

When using the JTAG debug port in Debug mode, the connection with the debugger is lost if the NJTRST pin (PB4) is used as a GPIO. Only the 4-wire JTAG port configuration is impacted.

Workaround

Use the SWD debug port instead of the full 4-wire JTAG port.

2.2.2FLASH_ECCR corrupted upon reset or power-down occurring during Flash memory program or erase operation

Description

Reset or power-down occurring during a Flash memory location program or erase operation, followed by a read of the same memory location, may lead to a corruption of the FLASH_ECCR register content.

Workaround

Under such condition, erase the page(s) corresponding to the Flash memory location.

2.2.3Unstable LSI when it clocks RTC or CSS on LSE

Description

ES0431 - Rev 7	page 6/28

STM32G431xx STM32G441xx

DMA

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 BORRSTF flag is set). If VBAT is separate from VDD, also restore the RTC configuration, backup registers and anti-tampering configuration.

2.2.4PCROP_RDP option bit production value not inline with the specification

Description

According to the specification, the PCROP_RDP option bit production value is “0”. In STM32G431 Rev Z devices, with date code 947 and date codes less than 944, the PCROP_RDP option bit production value is “1”

Workaround

None

2.3DMA

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

2.4.1SOFx 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.

ES0431 - Rev 7	page 7/28

STM32G431xx STM32G441xx

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_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.4.2OFx 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.3OFx 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.4Wrong 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.

ES0431 - Rev 7	page 8/28

STM32G431xx STM32G441xx

ADC

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.5ADC

2.5.1New context conversion initiated without waiting for trigger when writing new context in ADC_JSQR with JQDIS = 0 and JQM = 0

Description

Once an injected conversion sequence is complete, the queue is consumed and the context changes according to the new ADC_JSQR parameters stored in the queue. This new context is applied for the next injected sequence of conversions.

However, the programming of the new context in ADC_JSQR (change of injected trigger selection and/or trigger polarity) may launch the execution of this context without waiting for the trigger if:

•the queue of context is enabled (JQDIS cleared to 0 in ADC_CFGR), and

•the queue is never empty (JQM cleared to 0 in ADC_CFGR), and

•the injected conversion sequence is complete and no conversion from previous context is ongoing

Workaround

Apply one of the following measures:

•Ignore the first conversion.

•Use a queue of context with JQM = 1.

•Use a queue of context with JQM = 0, only change the conversion sequence but never the trigger selection and the polarity.

2.5.2Two consecutive context conversions fail when writing new context in ADC_JSQR just after previous context completion with JQDIS = 0 and JQM = 0

Description

When an injected conversion sequence is complete and the queue is consumed, writing a new context in ADC_JSQR just after the completion of the previous context and with a length longer that the previous context, may cause both contexts to fail. The two contexts are considered as one single context. As an example, if the first context contains element 1 and the second context elements 2 and 3, the first context is consumed followed by elements 2 and 3 and element 1 is not executed.

This issue may happen if:

•the queue of context is enabled (JQDIS cleared to 0 in ADC_CFGR), and

•the queue is never empty (JQM cleared to 0 in ADC_CFGR), and

•the length of the new context is longer than the previous one

Workaround

If possible, synchronize the writing of the new context with the reception of the new trigger.

ES0431 - Rev 7	page 9/28