STM32F405/407xx and STM32F415/417xx

Errata sheet

STM32F405/407xx and STM32F415/417xx device errata

Applicability
This document applies to the part numbers of STM32F405/407xx and STM32F415/417xx 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 RM0090.
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

STM32F405xx STM32F405OG, STM32F405OE, STM32F405RG, STM32F405VG, STM32F405ZG

STM32F407xx, STM32F407IG, STM32F407VG, STM32F407ZG, STM32F407ZE, STM32F407IE, STM32F407VE
STM32F415xx STM32F415OG, STM32F415RG, STM32F415VG, STM32F415ZG
STM32F417xx STM32F417VG, STM32F417IG, STM32F417ZG, STM32F417VE, STM32F417ZE, STM32F417IE

Table 2. Device variants

Silicon revision codes

Reference
Device marking(1) REV_ID(2)

A 0x1000
Z 0x1001
1 0x1003

STM32F405xx, STM32F407xx, 2 0x1007

STM32F415xx, STM32F417xx Y
0x100F
4
5
0x101F
6

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.

ES0182 - Rev 14 - February 2023 www.st.com

For further information contact your local STMicroelectronics sales office.
 STM32F405/407xx and STM32F415/417xx
Summary of device errata

1 Summary of device errata

The following table gives a quick reference to the STM32F405/407xx and STM32F415/417xx 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 Re Re Re Re Re Re Re Re
v. A v. Z v. 1 v. 2 v. Y v. 4 v. 5 v. 6

Interrupted loads to SP can cause erroneous

2.1.1 A A A A A A A A
behavior
VDIV or VSQRT instructions might not complete
Core 2.1.2 A A A A A A A A
correctly when very short ISRs are used
Store immediate overlapping exception return
2.1.3 A A A A A A A A
operation might vector to incorrect interrupt
ART Accelerator prefetch queue instruction is not
2.2.1 N - - - - - - -
supported
2.2.2 MCU device ID is incorrect A - - - - - - -
2.2.3 Debugging Stop mode and SysTick timer A A A A A A A A
2.2.4 Debugging Stop mode with WFE entry A A A A A A A A
2.2.5 Debugging Sleep/Stop mode with WFE/WFI entry A A A A A A A A
Wake-up sequence from Standby mode when using
2.2.6 A A A A A A A A
more than one wake-up source
Full JTAG configuration without NJTRST pin cannot
2.2.7 A A A A A A A A
be used
PDR_ON pin not available on LQFP100 package
2.2.8 - N N N N N N N
except for revision A devices
Incorrect BOR option byte when consecutively
2.2.9 A A A A A A A A
System programming BOR option byte
Configuration of PH10 and PI10 as external
2.2.10 N N N N N N N N
interrupts is erroneous
2.2.11 Slowing down APB clock during a DMA transfer A A A A A A A A
MPU attribute to RTC and IWDG registers incorrectly
2.2.12 A A A A A A A A
managed
2.2.13 Delay after an RCC peripheral clock enabling A A A A A A A A
2.2.14 Battery charge monitoring lower than 2.4 V P P P P P P P P
2.2.15 Internal noise impacting the ADC accuracy A A A A A A A A
2.2.16 RDP level 2 and sector write protection configuration A A A A A A A A
Possible delay in backup domain protection
2.2.17 A A A A A A A A
disabling/enabling after programming the DBP bit
2.2.18 PC13 signal transitions disturb LSE A A A A A A A A

ES0182 - Rev 14 page 2/45

 STM32F405/407xx and STM32F415/417xx
Summary of device errata

Status
Function Section Limitation Re Re Re Re Re Re Re Re
v. A v. Z v. 1 v. 2 v. Y v. 4 v. 5 v. 6

In some specific cases, DMA2 data corruption occurs

System 2.2.19 when managing AHB and APB2 peripherals in a A A A A A A A A
concurrent way
Dummy read cycles inserted when reading
2.3.1 N N N N N N N N
synchronous memories
FSMC synchronous mode and NWAIT signal
2.3.2 A A A A A A A A
FSMC disabled
FSMC NOR/PSRAM controller: asynchronous read
2.3.3 access on bank 2 to 4 returns wrong data when bank A A A A A A A A
1 is in synchronous mode (BURSTEN bit is set)
ADC 2.4.1 ADC sequencer modification during conversion A A A A A A A A
DMA request not automatically cleared by clearing
2.5.1 A A A A A A A A
DMAEN
DAC DMA underrun flag not set when an internal trigger
2.5.2 is detected on the clock cycle of the DMA request N N N N N N N N
acknowledge
PWM re-enabled in automatic output enable mode
2.6.1 P P P P P P P P
despite of system break
Consecutive compare event missed in specific
TIM 2.6.3 N N N N N N N N
conditions
Output compare clear not working with external
2.6.4 P P P P P P P P
counter reset
2.7.1 RVU flag not reset in Stop A A A A A A A A
2.7.2 PVU flag not reset in Stop A A A A A A A A
IWDG
2.7.3 RVU flag not cleared at low APB clock frequency A A A A A A A A
2.7.4 PVU flag not cleared at low APB clock frequency A A A A A A A A
Spurious tamper detection when disabling the tamper
2.8.1 N N N N N N N N
channel
2.8.2 RTC calendar registers are not locked properly A A A A A A A A
RTC interrupt can be masked by another RTC
2.8.3 A A A A A A A A
interrupt

RTC Calendar initialization may fail in case of consecutive

2.8.4 A A A A A A A A
INIT mode entry
Alarm flag may be repeatedly set when the core is
2.8.5 N N N N N N N N
stopped in debug
Detection of a tamper event occurring before
2.8.6 enabling the tamper detection is not supported in A A A A A A A A
edge detection mode
2.9.1 SMBus standard not fully supported A A A A A A A A
2.9.2 Start cannot be generated after a misplaced Stop A A A A A A A A
Mismatch on the “Setup time for a repeated Start
2.9.3 A A A A A A A A
condition” timing parameter

I2C Data valid time (tVD;DAT) violated without the OVR

2.9.4 A A A A A A A A
flag being set
Both SDA and SCL maximum rise times (tr) violated
2.9.5 when the VDD_I2C bus voltage is higher than A A A A A A A A
((VDD + 0.3) / 0.7) V

2.9.6 Spurious bus error detection in Master mode A A A A A A A A

ES0182 - Rev 14 page 3/45

 STM32F405/407xx and STM32F415/417xx
Summary of device errata

Status
Function Section Limitation Re Re Re Re Re Re Re Re
v. A v. Z v. 1 v. 2 v. Y v. 4 v. 5 v. 6

Idle frame is not detected if the receiver clock speed

2.10.1 N N N N N N N N
is deviated
In full-duplex mode, the Parity Error (PE) flag can be
2.10.2 A A A A A A A A
cleared by writing to the data register
Parity Error (PE) flag is not set when receiving in
2.10.3 N N N N N N N N
Mute mode using address mark detection
Break frame is transmitted regardless of CTS input
2.10.4 N N N N N N N N
line status
USART RTS signal abnormally driven low after a protocol
2.10.5 A A A A A A A A
violation
Start bit detected too soon when sampling for NACK
2.10.6 N N N N N N N N
signal from the smartcard
Break request can prevent the transmission complete
2.10.7 A A A A A A A A
flag (TC) from being set
Guard time not respected when data are sent on
2.10.8 A A A A A A A A
TXE events
2.10.9 RTS is active while RE or UE = 0 A A A A A A A A
2.11.4 Wrong CRC calculation when the polynomial is even A A A A A A A A
Corrupted last bit of data and/or CRC received in
2.11.5 A A A A A A A A
Master mode with delayed SCK feedback
BSY flag may stay high at the end of a data transfer
2.11.6 A A A A A A A A
in Slave mode
I2S2 in full-duplex mode may not work properly when
SPI/I2S 2.11.7 SCK and WS signals are mapped on PI1 and PI0, A A A A A A A A
respectively
2.11.1 BSY bit may stay high when SPI is disabled A A A A A A A A

In I2S slave mode, enabling I2S while WS is active

2.11.2 A A A A A A A A
causes desynchronization
Anticipated communication upon SPI transit from
2.11.3 A A A A A A A A
slave receiver to master
Wrong data written during SDIO hardware flow
2.12.1 N N N N N N N N
control
Wrong CCRCFAIL status after a response without
2.12.2 A A A A A A A A
CRC is received
SDIO clock divider Bypass mode may not work
2.12.3 A A A A A A A A
SDIO properly
Data corruption in SDIO clock dephasing
2.12.4 N N N N N N N N
(NEGEDGE) mode
CE-ATA multiple write command and card busy
2.12.5 A A A A A A A A
signal management
2.12.6 No underrun detection with wrong data transmission A A A A A A A A
bxCAN time-triggered communication mode not
bxCAN 2.13.1 N N N N N N N N
supported
Data in RxFIFO is overwritten when all channels are
2.14.3 A A A A A A A A
disabled simultaneously
OTG host blocks the receive channel when receiving
OTG_FS 2.14.4 A A A A A A A A
IN packets and no TxFIFO is configured
Host channel-halted interrupt not generated when the
2.14.5 A A A A A A A A
channel is disabled

ES0182 - Rev 14 page 4/45

 STM32F405/407xx and STM32F415/417xx
Summary of device errata

Status
Function Section Limitation Re Re Re Re Re Re Re Re
v. A v. Z v. 1 v. 2 v. Y v. 4 v. 5 v. 6

Wrong software-read OTG_FS_DCFG register

2.14.6 A A A A A A A A
values
Transmit data FIFO is corrupted when a write
OTG_FS 2.14.1 sequence to the FIFO is interrupted with accesses A A A A A A A A
to certain OTG_FS registers
Host packet transmission may hang when connecting
2.14.2 N N N N N N N N
through a hub to a low-speed device
Transmit data FIFO is corrupted when a write
2.15.1 sequence to the FIFO is interrupted with accesses A A A A A A A A
to certain OTG_HS registers
OTG_HS
Host packet transmission may hang when connecting
2.15.2 the full speed interface through a hub to a low-speed N N N N N N N N
device
Incorrect L3 checksum is inserted in transmitted IPv6
2.16.1 A A A A A A A A
packets without TCP, UDP or ICMP payloads
The ethernet MAC processes invalid extension
2.16.2 N N N N N N N N
headers in the received IPv6 frames
MAC stuck in the idle state on receiving the TxFIFO
2.16.3 flush command exactly one clock cycle after a P P P P P P P P
transmission completes
2.16.4 Transmit frame data corruption A A A A A A A A
Incorrect status and corrupted frames when RxFIFO
2.16.5 overflow occurs on the penultimate word of Rx A A A A A A A A
frames
Successive write operations to the same register
ETH 2.16.6 A A A A A A A A
might not be fully taken into account
2.16.7 Incorrect remote wakeup on global unicast packet P P P P P P P P
Overflow status bits of missed frame and buffer
2.16.8 overflow counters are cleared without a read A A A A A A A A
operation
MAC may provide incorrect Rx status for the MAC
2.16.9 control frames when receive checksum offload is A A A A A A A A
enabled
MAC may provide an inaccurate Rx status when
2.16.10 receive checksum offload is enabled in cut-through P P P P P P P P
mode
2.16.11 MAC may not drop received giant error frames A A A A A A A A

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

Table 4. Summary of device documentation errata

Function Section Documentation erratum

TIM 2.6.2 TRGO and TRGO2 trigger output failure

ES0182 - Rev 14 page 5/45

 STM32F405/407xx and STM32F415/417xx
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®-M4F core revision r0p1 is available from http://
infocenter.arm.com.

2.1.1 Interrupted 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.2 VDIV 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.

ES0182 - Rev 14 page 6/45

 STM32F405/407xx and STM32F415/417xx
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.3 Store 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.

ES0182 - Rev 14 page 7/45

 STM32F405/407xx and STM32F415/417xx
System

Example:
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.2 System

2.2.1 ART Accelerator prefetch queue instruction is not supported

Description
The ART Accelerator prefetch queue instruction is not supported on revision A devices.
This limitation does not prevent the ART Accelerator from using the cache enable/disable capability and the
selection of the number of wait states according to system frequency.

Workaround
• Revision A: None.
• Other revisions: fixed.

2.2.2 MCU device ID is incorrect

Description
On revision A devices, the STM32F40x and STM32F41x have the same MCU device ID as the STM32F20x and
STM32F21x devices. Reading the revision identifier returns 0x2000 instead of 0x1000. The device ID and revision
ID can be read from address 0xE004 2000.

ES0182 - Rev 14 page 8/45

 STM32F405/407xx and STM32F415/417xx
System

Workaround
• Revision A:
To differentiate the STM32F4xxx from the STM32F2xxx series, read the MCU device ID and the core
device:
– For STM32F2xxx
◦ MCU device ID = STM32F2xxx device ID
◦ Core device = Cortex®-M3
– For STM32F4xxx
◦ MCU device ID = STM32F4xxx device ID
◦ Core device = Cortex®-M4
• Other revisions: fixed.

2.2.3 Debugging Stop mode and SysTick timer

Description
If the SysTick timer interrupt is enabled during the Stop mode debug (DBG_STOP bit set in the DBGMCU_CR
register), it wakes up the system from Stop mode.

Workaround
To debug the Stop mode, disable the SysTick timer interrupt.

2.2.4 Debugging Stop mode with WFE entry

Description
When the Stop debug mode is enabled (DBG_STOP bit set in the DBGMCU_CR register), the software
debugging is allowed during Stop mode. However, if the application software uses the WFE instruction to enter
Stop mode, after wake-up, some instructions may be missed if the WFE is followed by sequential instructions.
This affects only Stop debug mode with WFE entry.

Workaround
To debug Stop mode with WFE entry, the WFE instruction must be inside a dedicated function with one instruction
(NOP) between the execution of the WFE and the Bx LR. For example:
__asm void _WFE(void)
WFE
NOP
BX lr }

2.2.5 Debugging Sleep/Stop mode with WFE/WFI entry

Description
When the Sleep debug or Stop debug mode is enabled (DBG_SLEEP bit or DBG_STOP bit are set in the
DBGMCU_CR register), software debugging is allowed during Sleep or Stop mode. After wake-up, some
unreachable instructions can be executed if the following conditions are met:
• The application software disables the Prefetch queue,
• the number of wait states configured for the flash memory interface is higher than zero, and
• the linker places the WFE or WFI instruction on a 4-byte aligned addresses (0x080xx xxx4).

ES0182 - Rev 14 page 9/45

 STM32F405/407xx and STM32F415/417xx
System

Workaround
Apply one of the following measures:
• Add three NOPs after WFI/WFE instruction.
• Keep one AHB master active during Sleep (example keep DMA1 or DMA2 RCC clock enable bit set).
• Execute WFI/WFE instruction from routines inside the SRAM.

2.2.6 Wake-up sequence from Standby mode when using more than one wake-up source

Description
The various wake-up sources are logically OR-ed in front of the rising-edge detector that generates the wake-up
flag (WUF). The WUF needs to be cleared before Standby mode entry, otherwise the MCU wakes up immediately.
If one of the configured wake-up sources is kept high during the clearing of the WUF (by setting the CWUF bit), it
may mask further wake-up events on the input of the edge detector. As a consequence, the MCU may not be able
to wake up from Standby mode.

Workaround
To avoid this problem, apply the following sequence before entering Standby mode:
1. Disable all used wake-up sources.
2. Clear all related wake-up flags.
3. Reenable all used wake-up sources.
4. Enter Standby mode.
Note: Be aware that, when applying this workaround, if one of the wake-up sources is still kept high, the MCU enters
Standby mode but then it wakes up immediately and generates a power reset.

2.2.7 Full 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.8 PDR_ON pin not available on LQFP100 package except for revision A devices

Description
On all device revisions except for revision A, the PDR_ON pin (pin 99), available on LQFP100 package, is
replaced by VSS. As a consequence, the POR/PDR feature is always enabled.

Workaround
• Applications using revision A devices with PDR_ON pin connected to VDD (POR/PDR feature enabled):
Connect the former PDR_ON pin to VSS on revision Z devices.
• Applications using revision A devices with PDR_ON pin connected to VSS (POR/PDR feature disabled):
No modification is required when migrating to other device revisions. However, it is no longer possible to
supply the product from a 1.7 V VDD on LQFP100 package since VDD minimum value is 1.8 V when the
POR/PDR feature is enabled.

ES0182 - Rev 14 page 10/45

 STM32F405/407xx and STM32F415/417xx
System

2.2.9 Incorrect BOR option byte when consecutively programming BOR option byte

Description
When the AHB prescaler is greater than 2, and consecutive BOR option byte program operations are performed
without resetting the device, then an incorrect value may be programmed in the BOR option byte.

Workaround
To program consecutive BOR option byte values, either configure the AHB prescaler to 1 or 2, or perform a
system reset between each BOR option byte program operation.

2.2.10 Configuration of PH10 and PI10 as external interrupts is erroneous

Description
PH10 or PI10 is selected as the source for the EXTI10 external interrupt by setting bits EXTI10[3:0] of the
SYSCFG_EXTICR3 register to 0x0111 or 0x1000, respectively. Instead, this operation wrongly enables PH2 and
PI2 as external interrupt inputs.
As a result, it is not possible to use PH10/PI10 as interrupt sources if PH2/PI2 are not selected as interrupt
source as well. This means that bits EXTI10[3:0] of the SYSCFG_EXTICR3 register and bits EXTI2[3:0] of the
SYSCFG_EXTICR1 must be programmed to the same value:
• 0x0111 to select PH10/PH2
• 0x1000 to select PI10/PI2

Workaround
None.

2.2.11 Slowing down APB clock during a DMA transfer

Description
When the CPU modifies the APB clock (slows down the clock by changing the AHB/APB prescaler from 1 to 2, 1
to 4, 1 to 8 or 1 to 16) while the DMA is performing a write access to the same APB peripherals, the current DMA
transfer is blocked. Only a system reset recovers.

Workaround
Before slowing down the APB clock, wait until the end of the DMA transfer on this APB.

2.2.12 MPU attribute to RTC and IWDG registers incorrectly managed

Description
If the MPU is used and the nonbufferable attribute is set to the RTC or IWDG memory map region, the
CPU access to the RTC or IWDG registers may be treated as bufferable, provided there is no APB prescaler
configured (AHB/APB prescaler is equal to 1).

Workaround
If the nonbufferable attribute is required for these registers, perform by software a read after the write to guaranty
the completion of the write access.

2.2.13 Delay after an RCC peripheral clock enabling

Description
A delay may be observed between an RCC peripheral clock enable and the effective peripheral enabling. It must
be taken into account in order to manage the peripheral read/write from/to registers.

ES0182 - Rev 14 page 11/45

 STM32F405/407xx and STM32F415/417xx
System

This delay depends on the peripheral mapping:

• If the peripheral is mapped on the AHB: the delay may be equal to two AHB cycles.
• If the peripheral is mapped on the APB: the delay may be equal to 1 + (AHB/APB prescaler) cycles.

Workaround
Apply one of the following measures:
• Use the DSB instruction to stall the Arm® Cortex®-M4 CPU pipeline until the instruction has completed.
• Insert “n” NOPs between the RCC enable bit write and the peripheral register writes (n = 2 for AHB
peripherals, n = 1 + AHB/APB prescaler for APB peripherals).
• Simply insert a dummy read operation from the corresponding register just after enabling the peripheral
clock.

2.2.14 Battery charge monitoring lower than 2.4 V

Description
If VDD = VDDA is lower than or equal to 2.4 V, the VBAT conversion correctness is not guaranteed in full
temperature and voltage ranges. When VBAT is set, the voltage divider bridge is enabled, and VBAT / 2 is
connected to the ADC input. In order to correctly monitor the battery charge, the input of the ADC must not be
higher than VDDA - 0.6 V. Thus, VBAT / 2 < VDD – 0.6 V implies that VDD > 2.4 V.

Workaround
None. VDD = VDDA must be greater than 2.4 V.

2.2.15 Internal noise impacting the ADC accuracy

Description
An internal noise generated on VDD supplies and propagated internally may impact the ADC accuracy. This noise
is always present whatever the power mode of the MCU (Run or Sleep).

Workaround
Use the following sequence to adapt the accuracy level to the application requirements:
1. Configure the flash memory ART with prefetch OFF and data + instruction cache ON.
2. Use averaging and filtering algorithms on ADC output codes.
For more detailed workarounds, refer to the application note "How to improve ADC accuracy when using
STM32F2xx and STM32F4xx microcontrollers" (AN4073).

2.2.16 RDP level 2 and sector write protection configuration

Description
When the MCU is protected with RDP level2, the configuration of the sector write protection remains changeable
by the user code.

Workaround

Protect sensitive sectors and the FLASH_OPTCR register using the Arm® Cortex®-M MPU (memory protection
unit) taking special care of ISR management.

2.2.17 Possible delay in backup domain protection disabling/enabling after programming the DBP bit

Description
Depending on the AHB/APB1 prescaler, a delay between DBP bit programming and the effective disabling/
enabling of the backup domain protection can be observed and must be taken into account.
The higher the APB1 prescaler value, the higher the delay.

ES0182 - Rev 14 page 12/45

 STM32F405/407xx and STM32F415/417xx
FSMC

Workaround
Apply one of the following measures:
• Insert a dummy read operation to the PWR_CR register just after programming the DBP bit.
• Wait for the end of the operation (reset through the BDRST bit or write to the backup domain) via a polling
loop on targeted registers.

2.2.18 PC13 signal transitions disturb LSE

Description
The PC13 input/output toggling disturbs the LSE clock. As a result, PC13 may not be usable when LSE is used.

Workaround
Use an external clock with the LSE in bypass mode.

2.2.19 In some specific cases, DMA2 data corruption occurs when managing AHB and APB2
peripherals in a concurrent way

Description
When the DMA2 is managing concurrent requests of AHB and APB2 peripherals, the transfer on the AHB can be
performed several times. Impacted peripheral are:
• QUADSPI: indirect mode read and write transfers
• FSMC: read and write operation with external device having FIFO
• GPIO: DMA2 transfers to GPIO registers (in memory-to-peripheral transfer mode). The transfers from the
GPIOs register are not impacted.
The data corruption is due to multiple DMA2 accesses over the AHB peripheral port impacting peripherals
embedding a FIFO.
For transfer to the internal SRAM through the DMA2 AHB peripheral port, the accesses can be performed several
times but without data corruptions in cases of concurrent requests.

Workaround
• Use the DMA2 AHB memory port when reading/writing from/to QUADSPI and FSMC instead of DMA2 AHB
default peripheral port.
• Use the DMA2 AHB memory port when writing to GPIOs instead of DMA2 AHB default peripheral port.
For more details about DMA controller features, refer to the section Take benefits of DMA2 controller and
system architecture flexibility of the application note "Using the STM32F2, STM32F4 and STM32F7 Series DMA
controller" (AN4031).

2.3 FSMC

2.3.1 Dummy read cycles inserted when reading synchronous memories

Description
When performing a burst read access from a synchronous memory, two dummy read accesses are performed at
the end of the burst cycle whatever the type of burst access.
The extra data values read are not used by the FSMC and there is no functional failure.

Workaround
None.

ES0182 - Rev 14 page 13/45

 STM32F405/407xx and STM32F415/417xx
ADC

2.3.2 FSMC synchronous mode and NWAIT signal disabled

Description
When the FSMC operates in synchronous mode with the NWAIT signal disabled, if the polarity (WAITPOL in the
FSMC_BCRx register) of the NWAIT signal is identical to that of the NWAIT input signal level, the system hangs
and no fault is generated.

Workaround
Do not set the PD6 port to AF12 (NWAIT input). Configure the NWAIT polarity to active high by setting the
WAITPOL bit of the FSMC_BCRx register.

2.3.3 FSMC NOR/PSRAM controller: asynchronous read access on bank 2 to 4 returns wrong data
when bank 1 is in synchronous mode (BURSTEN bit is set)

Description
If an interrupt occurs during a CPU AHB read access to one NOR/PSRAM bank (bank 2 to 4) which is enabled
in asynchronous mode, while bank 1 of the NOR/PSRAM controller is configured in synchronous read mode
(BURSTEN bit set), then the FSMC NOR/PSRAM controller returns wrong data. This limitation does not occur
when using the DMA or when only bank 1 is used in synchronous mode.

Workaround
If multiple banks are enabled in mixed asynchronous and synchronous modes, use any NOR/PSRAM bank for
synchronous read accesses, except for bank 1. As a consequence the continuous clock feature is not available.

2.4 ADC

2.4.1 ADC sequencer modification during conversion

Description
When a software start-of-conversion is used as an ADC trigger, and if the ADC_SQRx or ADC_JSQRx register
is modified during the conversion, the current conversion is reset and the ADC does not automatically restart the
new conversion sequence. The hardware start-of-conversion trigger is not impacted and the ADC automatically
restarts the new sequence when the next hardware trigger occurs.

Workaround
When a software start-of-conversion is used, apply the following sequence:
1. First set the SWSART bit in the ADC_CR2 register.
2. Then restart the new conversion sequence.

2.5 DAC

2.5.1 DMA request not automatically cleared by clearing DMAEN

Description
Upon an attempt to stop a DMA-to-DAC transfer, the DMA request is not automatically cleared by clearing the
DAC channel bit of the DAC_CR register (DMAEN) or by disabling the DAC clock.
If the application stops the DAC operation while the DMA request is pending, the request remains pending while
the DAC is reinitialized and restarted, with the risk that a spurious DMA request is serviced as soon as the DAC is
enabled again.

Workaround
Apply the following sequence to stop the current DMA-to-DAC transfer and restart the DAC:
1. Check if DMAUDR bit is set in DAC_CR.

ES0182 - Rev 14 page 14/45

 STM32F405/407xx and STM32F415/417xx
TIM

2. Clear the DAC channel DMAEN bit.

3. Disable the DAC clock.
4. Reconfigure the DAC, DMA and the triggers.
5. Restart the application.

2.5.2 DMA underrun flag not set when an internal trigger is detected on the clock cycle of the DMA
request acknowledge

Description
When the DAC channel operates in DMA mode (DMAEN of DAC_CR register set), the DMA channel underrun
flag (DMAUDR of DAC_SR register) fails to rise upon an internal trigger detection if that detection occurs during
the same clock cycle as a DMA request acknowledge. As a result, the user application is not informed that an
underrun error occurred.
This issue occurs when software and hardware triggers are used concurrently to trigger DMA transfers.

Workaround
None.

2.6 TIM

2.6.1 PWM re-enabled in automatic output enable mode despite of system break

Description
In automatic output enable mode (AOE bit set in TIMx_BDTR register), the break input can be used to do a
cycle-by-cycle PWM control for a current mode regulation. A break signal (typically a comparator with a current
threshold ) disables the PWM output(s) and the PWM is re-armed on the next counter period.
However, a system break (typically coming from the CSS Clock security System) is supposed to stop definitively
the PWM to avoid abnormal operation (for example with PWM frequency deviation).
In the current implementation, the timer system break input is not latched. As a consequence, a system break
indeed disables the PWM output(s) when it occurs, but PWM output(s) is (are) re-armed on the following counter
period.

Workaround
Preferably, implement control loops with the output clear enable function (OCxCE bit in the TIMx_CCMR1/CCMR2
register), leaving the use of break circuitry solely for internal and/or external fault protection (AOE bit reset).

2.6.2 TRGO and TRGO2 trigger output failure

Description
Some reference manual revisions may omit the following information.
The timers can be linked using ITRx inputs and TRGOx outputs. Additionally, the TRGOx outputs can be used as
triggers for other peripherals (for example ADC). Since this circuitry is based on pulse generation, care must be
taken when initializing master and slave peripherals or when using different master/slave clock frequencies:
• If the master timer generates a trigger output pulse on TRGOx prior to have the destination peripheral clock
enabled, the triggering system may fail.
• If the frequency of the destination peripheral is modified on-the-fly (clock prescaler modification), the
triggering system may fail.
As a conclusion, the clock of the slave timer or slave peripheral must be enabled prior to receiving events from
the master timer, and must not be changed on-the-fly while triggers are being received from the master timer.
This is a documentation issue rather than a product limitation.

Workaround
No application workaround is required or applicable as long as the application handles the clock as indicated.

ES0182 - Rev 14 page 15/45

 STM32F405/407xx and STM32F415/417xx
TIM

2.6.3 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:
• 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.4 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).

ES0182 - Rev 14 page 16/45

 STM32F405/407xx and STM32F415/417xx
IWDG

2.7 IWDG

2.7.1 RVU flag not reset in Stop

Description
Successful write to the IWDG_RLR register raises the RVU flag and prevents further write accesses to the
register until the RVU flag is automatically cleared by hardware. However, if the device enters Stop mode while
the RVU flag is set, the hardware never clears that flag, and writing to the IWDG_RLR register is no longer
possible.

Workaround
Ensure that the RVU flag is cleared before entering Stop mode.

2.7.2 PVU flag not reset in Stop

Description
Successful write to the IWDG_PR register raises the PVU flag and prevents further write accesses to the register
until the PVU flag is automatically cleared by hardware. However, if the device enters Stop mode while the PVU
flag is set, the hardware never clears that flag, and writing to the IWDG_PR register is no longer possible.

Workaround
Ensure that the PVU flag is cleared before entering Stop mode.

2.7.3 RVU flag not cleared at low APB clock frequency

Description
Successful write to the IWDG_RLR register raises the RVU flag and prevents further write accesses to the
register until the RVU flag is automatically cleared by hardware. However, at APB clock frequency lower than
twice the IWDG clock frequency, the hardware never clears that flag, and writing to the IWDG_RLR register is no
longer possible.

Workaround
Set the APB clock frequency higher than twice the IWDG clock frequency.

2.7.4 PVU flag not cleared at low APB clock frequency

Description
Successful write to the IWDG_PR register raises the PVU flag and prevents further write accesses to the register
until the PVU flag is automatically cleared by hardware. However, at APB clock frequency lower than twice the
IWDG clock frequency, the hardware never clears that flag, and writing to the IWDG_PR register is no longer
possible.

Workaround
Set the APB clock frequency higher than twice the IWDG clock frequency.

2.8 RTC

2.8.1 Spurious tamper detection when disabling the tamper channel

Description
If the tamper detection is configured for detecting on the falling edge event (TAMPFLT = 00 and TAMPxTRG = 1)
and if the tamper event detection is disabled when the tamper pin is at high level, a false tamper event is
detected.

ES0182 - Rev 14 page 17/45

 STM32F405/407xx and STM32F415/417xx
RTC

Workaround
None.

2.8.2 RTC calendar registers are not locked properly

Description
When reading the calendar registers with BYPSHAD = 0, the RTC_TR and RTC_DR registers may not be locked
after reading the RTC_SSR register. This happens if the read operation is initiated one APB clock period before
the shadow registers are updated. This can result in a non-consistency of the three registers. Similarly, the
RTC_DR register can be updated after reading the RTC_TR register instead of being locked.

Workaround
Apply one of the following measures:
• Use BYPSHAD = 1 mode (bypass shadow registers), or
• If BYPSHAD = 0, read SSR again after reading SSR/TR/DR to confirm that SSR is still the same, otherwise
read the values again.

2.8.3 RTC interrupt can be masked by another RTC interrupt

Description
One RTC interrupt request can mask another RTC interrupt request if they share the same EXTI configurable line.
For example, interrupt requests from Alarm A and Alarm B or those from tamper and timestamp events are OR-ed
to the same EXTI line (refer to the EXTI line connections table in the Extended interrupt and event controller
(EXTI) section of the reference manual).
The following code example and figure illustrate the failure mechanism: The Alarm A event is lost (fails to
generate interrupt) as it occurs in the failure window, that is, after checking the Alarm A event flag but before the
effective clear of the EXTI interrupt flag by hardware. The effective clear of the EXTI interrupt flag is delayed with
respect to the software instruction to clear it.
Alarm interrupt service routine:
void RTC_Alarm_IRQHandler(void)
{
CLEAR_ALARM_EXTI(); /* Clear the EXTI line flag for RTC alarms*/
If(ALRAF) /* Check if Alarm A triggered ISR */
{
CLEAR_FLAG(ALRAF); /* Clear the Alarm A interrupt pending bit */
PROCESS_AlarmAEvent(); /* Process Alarm A event */
}
If(ALRBF) /* Check if Alarm B triggered ISR */
{
CLEAR_FLAG(ALRBF); /* Clear the Alarm B interrupt pending bit */
PROCESS_AlarmBEvent(); /* Process Alarm B event */
}
}

ES0182 - Rev 14 page 18/45

 STM32F405/407xx and STM32F415/417xx
RTC

Figure 1. Masked RTC interrupt

Failure window:
Alarm A Flag is being set after the software checks
its value
Alarm A Flag does not raise EXTI flag because this
one is not yet hardware cleared.

Alarm B Flag

Alarm A Flag

EXTI Flag
Alarm A is never processed
If (ALRBF)
CLEAR_ If { because no interrupt is generated

DT47477V1
ALARM_ (ALRA CLEAR_FLAG(ALRBF);
ISR execution EXTI(); F) PROCESS_AlarmBEvent(); through EXTI
}

Workaround
In the interrupt service routine, apply three consecutive event flag ckecks - source one, source two, and source
one again, as in the following code example:
void RTC_Alarm_IRQHandler(void)
{
CLEAR_ALARM_EXTI(); /* Clear the EXTI's line Flag for RTC Alarm */
If(ALRAF) /* Check if AlarmA triggered ISR */
{
CLEAR_FLAG(ALRAF); /* Clear the AlarmA interrupt pending bit */
PROCESS_AlarmAEvent(); /* Process AlarmA Event */
}
If(ALRBF) /* Check if AlarmB triggered ISR */
{
CLEAR_FLAG(ALRBF); /* Clear the AlarmB interrupt pending bit */
PROCESS_AlarmBEvent(); /* Process AlarmB Event */
}
If(ALRAF) /* Check if AlarmA triggered ISR */
{
CLEAR_FLAG(ALRAF); /* Clear the AlarmA interrupt pending bit */
PROCESS_AlarmAEvent(); /* Process AlarmA Event */
}
}

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

Description
If the INIT bit of the RTC_ISR 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 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.

ES0182 - Rev 14 page 19/45

 STM32F405/407xx and STM32F415/417xx
I2C

Note: It is recommended to write all registers in a single initialization session to avoid accumulating synchronization
delays.

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

Workaround
None.

2.8.6 Detection of a tamper event occurring before enabling the tamper detection is not supported in
edge detection mode

Description
When the tamper detection is enabled in edge detection mode (TAMPFLT = 00):
• When TAMPxTRG = 0 (rising edge detection): if the tamper input is already high before enabling the
tamper detection, the tamper event may or may not be detected when enabling the tamper detection. The
probability to detect it increases with the APB frequency.
• When TAMPxTRG = 1 (falling edge detection): if the tamper input is already low before enabling the tamper
detection, the tamper event is not detected when enabling the tamper detection.

Workaround
Check the I/O state by software in the GPIO registers, just after enabling the tamper detection and before writing
sensitive values in the backup registers. This ensures that no active edge occurred before enabling the tamper
event detection.

2.9 I2C

2.9.1 SMBus standard not fully supported

Description
The I2C peripheral is not fully compliant with the SMBus v2.0 standard since it does not support the capability to
NACK an invalid byte/command.

Workaround
A higher-level mechanism must be used to verify that a write operation is being performed correctly at the target
device, such as:
• the SMBAL pin if it is supported by the host
• the alert response address (ARA) protocol
• the host-notify protocol

2.9.2 Start cannot be generated after a misplaced Stop

Description
If a master generates a misplaced Stop on the bus (bus error) while the microcontroller I2C peripheral attempts to
switch to Master mode by setting the START bit, the Start condition is not properly generated.

ES0182 - Rev 14 page 20/45

 STM32F405/407xx and STM32F415/417xx
I2C

Workaround

In the I2C standard, it is allowed to send a Stop only at the end of the full byte (8 bits + acknowledge), so this
scenario is not allowed. Other derived protocols such as CBUS allow it, but they are not supported by the I2C
peripheral.
A software workaround consists in asserting the software reset using the SWRST bit of the I2C_CR1 control
register.

2.9.3 Mismatch on the “Setup time for a repeated Start condition” timing parameter

Description

In case of repeated Start, the “Setup time for a repeated Start condition” (named Tsu;sta in the I2C specification)
can be slightly violated when the I2C operates in Master standard mode at a frequency between 88 kHz and
100 kHz.
The issue can occur only in the following configuration:
• In Master mode
• In Standard mode at a frequency between 88 kHz and 100 kHz (no limitation in Fast mode)
• SCL rise time:
– If the slave does not stretch the clock and the SCL rise time is more than 300 ns (if the SCL rise time
is less than 300 ns, the issue does not occur).
– If the slave stretches the clock.
The setup time can be violated independently of the APB peripheral frequency.

Workaround

Reduce the frequency down to 88 kHz or use the I2C Fast mode, if it is supported by the slave.

2.9.4 Data valid time (tVD;DAT) violated without the OVR flag being set

Description

The data valid time (tVD;DAT, tVD;ACK) described by the I2C standard can be violated (as well as the maximum data
hold time of the current data (tHD;DAT)) under the conditions described below. This violation cannot be detected
because the OVR flag is not set (no transmit buffer underrun is detected).
This limitation can occur only under the following conditions:
• in Slave transmit mode
• with clock stretching disabled (NOSTRETCH = 1)
• if the software is late to write to the DR data register, but not late enough to set the OVR flag (the data
register is written before)

Workaround
If the master device allows it, use the clock stretching mechanism by clearing the bit NOSTRETCH of the
I2C_CR1 register.
If the master device does not allow it, ensure that the software is fast enough when polling the TXE or ADDR flag
to immediately write to the DR data register. For instance, use an interrupt on the TXE or ADDR flag and boost its
priority to the higher level.

ES0182 - Rev 14 page 21/45

 STM32F405/407xx and STM32F415/417xx
USART

2.9.5 Both SDA and SCL maximum rise times (tr) violated when the VDD_I2C bus voltage is higher
than ((VDD + 0.3) / 0.7) V

Description

When an external legacy I2C bus voltage (VDD_I2C) is set to 5 V while the MCU is powered from VDD, the internal
5-Volt tolerant circuitry is activated as soon the input voltage (VIN) reaches the VDD + diode threshold level. An
additional internal large capacitance then prevents the external pull-up resistor (RP) from rising the SDA and SCL
signals within the maximum timing (tr), which is 300 ns in Fast mode and 1000 ns in Standard mode.
The rise time (tr) is measured from VIL and VIH with levels set at 0.3 VDD_I2C and 0.7 VDD_I2C.

Workaround
The external VDD_I2C bus voltage must be limited to a maximum value of ((VDD + 0.3) / 0.7) V. As a result, when
the MCU is powered from VDD = 3.3 V, VDD_I2Cmust not exceed 5.14 V to be compliant with I2C specifications.

2.9.6 Spurious bus error detection in Master mode

Description
In Master mode, a bus error can be detected by mistake, thus causing the BERR flag to be wrongly raised in the
status register. This generates a spurious Bus Error interrupt if the interrupt is enabled. A bus error detection has
no effect on the transfer in Master mode, therefore the I2C transfer can continue 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.10 USART

2.10.1 Idle frame is not detected if the receiver clock speed is deviated

Description
If the USART receives an idle frame followed by a character, and the clock of the transmitter device is faster than
the USART receiver clock, the USART receive signal falls too early when receiving the character start bit, with the
result that the idle frame is not detected (the IDLE flag is not set).

Workaround
None.

2.10.2 In full-duplex mode, the Parity Error (PE) flag can be cleared by writing to the data register

Description
In full-duplex mode, when the Parity Error flag is set by the receiver at the end of a reception, it may be cleared
while transmitting by reading the USART_SR register to check the TXE or TC flags and writing data to the data
register. Consequently, the software receiver can read the PE flag as '0' even if a parity error occurred.

Workaround
The Parity Error flag should be checked after the end of reception and before transmission.

ES0182 - Rev 14 page 22/45

 STM32F405/407xx and STM32F415/417xx
USART

2.10.3 Parity Error (PE) flag is not set when receiving in Mute mode using address mark detection

Description
If the USART receiver is in Mute mode, and is configured to exit from Mute mode using the address mark
detection, when the USART receiver recognizes a valid address with a parity error, it exits from Mute mode
without setting the Parity Error flag.

Workaround
None.

2.10.4 Break frame is transmitted regardless of CTS input line status

Description
When the CTS hardware flow control is enabled (CTSE = 1) and the send break bit (SBK) is set, the transmitter
sends a break frame at the end of the current transmission regardless of CTS input line status. Consequently, if
an external receiver device is not ready to accept a frame, the transmitted break frame is lost.

Workaround
None.

2.10.5 RTS signal abnormally driven low after a protocol violation

Description
When RTS hardware flow control is enabled, the RTS signal goes high when data is received. If this data was not
read and new data is sent to the USART (protocol violation), the RTS signal goes back to low level at the end of
this new data.
Consequently, the sender gets the wrong information that the USART is ready to receive further data.
On the USART side, an overrun is detected, which indicates that data has been lost.

Workaround
A workaround is required only if the other USART device violates the communication protocol, which is not the
case in most applications.
Two workarounds can be used:
• After data reception and before reading the data in the data register, the software takes over the control
of the RTS signal as a GPIO, and holds it high as long as needed. If the USART device is not ready, the
software holds the RTS pin high, and releases it when the device is ready to receive new data.
• Make sure the time required by the software to read the received data is always lower than the duration of
the second data reception. For example, this can be ensured by handling all the receptions in DMA mode.

2.10.6 Start bit detected too soon when sampling for NACK signal from the smartcard

Description
According to ISO/IEC 7816-3 standard, when a character parity error is detected, the receiver shall transmit a
NACK error signal 10.5 ± 0.2 ETUs after the character START bit falling edge. In this case, the transmitter is able
to detect correctly the NACK signal until 11 ± 0.2 ETUs after the character START bit falling edge. In Smartcard
mode, the USART peripheral monitors the NACK signal during the receiver time frame (10.5 ± 0.2 ETUs), while
it should wait for it during the transmitter one (11 ± 0.2 ETUs). In real cases, this would not be a problem as the
card itself needs to respect a 10.7 ETU period when sending the NACK signal. However, this may be an issue to
undertake a certification.

Workaround
None.

ES0182 - Rev 14 page 23/45

 STM32F405/407xx and STM32F415/417xx
SPI/I2S

2.10.7 Break request can prevent the transmission complete flag (TC) from being set

Description
After the end of transmission of a data (D1), the transmission complete (TC) flag is not set if the following
conditions are met:
• CTS hardware flow control is enabled,
• D1 is being transmitted,
• a break transfer is requested before the end of D1 transfer,
• CTS is de-asserted before the end of D1 data transfer.

Workaround
If the application needs to detect the end of a data transfer, check that the TC flag is set, and issue a break
request.

2.10.8 Guard time not respected when data are sent on TXE events

Description
In Smartcard mode, when sending a data on TXE event, the programmed guard time is not respected, that is the
data written in the data register is transferred to the bus without waiting the completion of the guard-time duration
corresponding to the previous transmitted data.

Workaround
Since in Smartcard mode the TC flag is set at the end of the guard time duration, wait until TC is set, then write
the data.

2.10.9 RTS is active while RE or UE = 0

Description
The RTS line is driven low as soon as the RTSE bit is set, even if the USART is disabled (UE = 0) or if the
receiver is disabled (RE = 0) that is not ready to receive data.

Workaround
After setting the UE and RE bits, configure the I/O used for RTS as an alternate function.

2.11 SPI/I2S

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

ES0182 - Rev 14 page 24/45

 STM32F405/407xx and STM32F415/417xx
SPI/I2S

2.11.2 In I2S slave mode, enabling I2S while WS is active causes desynchronization

Description

In I2S slave mode, the WS signal level is used to start the communication. If the I2S peripheral is enabled while
the WS line is active (low for I2S protocol, high for LSB- or MSB-justified mode), and if the master is already
sending the clock, the I2S peripheral (slave) starts communicating data from the instant of its enable, which
causes desynchronization between the master and the slave throughout the whole communication.

Workaround
Enable I2S peripheral while the WS line is at:
• high level, for I2S protocol.
• low level, for LSB- or MSB-justified mode.

2.11.3 Anticipated communication upon SPI transit from slave receiver to master

Description
Regardless of the master mode configured, the communication clock starts upon setting the MSTR bit even
though the SPI is disabled, if transiting from receive‑only (RXONLY = 1) or half‑duplex receive (BIDIMODE = 1
and BIDIOE = 0) slave mode to master mode.

Workaround
Apply one of the following measures:
• Before transiting to master mode, hardware‑reset the SPI via the reset controller.
• Set the MSTR and SPE bits of the SPI configuration register simultaneously, which forces the immediate
start of the communication clock. In transmitter configuration, load the data register in advance with the
data to send.

2.11.4 Wrong CRC calculation when the polynomial is even

Description
When the CRC is enabled, the CRC calculation is wrong if the polynomial is even.

Workaround
Use odd polynomial.

2.11.5 Corrupted last bit of data and/or CRC received in Master mode with delayed SCK feedback

Description
When performing a receive transaction in I2S or SPI Master mode, the last bit of the transacted frame is not
captured when the signal provided by an internal feedback loop from the SCK pin exceeds a critical delay.
The lastly transacted bit of the stored data then keeps the value from the pattern received previously. As a
consequence, the last receive data bit may be wrong, and/or the CRCERR flag can be unduly asserted in the SPI
mode if any data under checksum, and/or just the CRC pattern is wrongly captured.
In SPI mode, data are synchronous with the APB clock. A delay of up to two APB clock periods can thus be
tolerated for the internal feedback delay.
The I2S mode is more sensitive than the SPI mode, especially in the case where an odd I2S prescaler factor is
set and the APB clock is the system clock divided by two. In this case, the internal feedback delay is lower than
1.5 APB clock period.
The main factors contributing to the delay increase are low VDD level, high temperature, high SCK pin capacitive
load, and low SCK I/O output speed. The SPI communication speed has no impact.

ES0182 - Rev 14 page 25/45

 STM32F405/407xx and STM32F415/417xx
SPI/I2S

Workaround
The following workarounds can be adopted, jointly or individually:
• Decrease the APB clock speed.
• Configure the I/O pad of the SCK pin to be faster.
The following table gives the maximum allowable APB frequency (that still prevents the issue from occurring)
versus GPIOx_OSPEEDR output speed for the SCK pin, with a 30 pF capacitive load.

Table 5. Maximum allowable APB frequency at 30 pF load

Max. APB frequency for SPI mode Max. APB frequency for I2S mode
OSPEEDR [1:0] for SCK pin
(MHz) (MHz)

11 (very high), 10 (high) 84 42

01 (medium) 75 35
00 (low) 25 16

2.11.6 BSY flag may stay high at the end of a data transfer in Slave mode

Description
The BSY flag may sporadically remain high at the end of a data transfer in Slave mode. The issue appears when
an accidental synchronization happens between the internal CPU clock and the external SCK clock provided by
the master.
This is related to the end of data transfer detection while the SPI is enabled in Slave mode.
As a consequence, the end of the data transaction may be not recognized when the software needs to monitor it
(for example at the end of a session before entering the low-power mode or before the direction of the data line
has to be changed at half duplex bidirectional mode). The BSY flag is unreliable to detect the end of any data
sequence transaction.

Workaround
When the NSS hardware management is applied and the NSS signal is provided by the master, the end of a
transaction can be detected by the NSS polling by the slave:
• If the SPI receiving mode is enabled, the end of a transaction with the master can be detected by the
corresponding RXNE event signaling the last data transfer completion.
• In SPI transmit mode, the user can check the BSY under timeout corresponding to the time necessary to
complete the last data frame transaction. The timeout must be measured from TXE event signaling the last
data frame transaction start (it is raised once the second bit transaction is ongoing). Either BSY becomes
low normally or the timeout expires when the synchronization issue happens.
When the above workarounds are not applicable, the following sequence can be used to prevent the
synchronization issue during SPI transmit mode:
1. Write the last data to the data register.
2. Poll TXE until it becomes high to ensure the data transfer has started.
3. Disable SPI by clearing SPE while the last data transfer is still ongoing.
4. Poll the BSY bit until it becomes low.
5. The BSY flag works correctly and can be used to recognize the end of the transaction.
Note: This workaround can be used only when the CPU has enough performance to disable the SPI after a TXE event
is detected, while the data frame transfer is still ongoing. It is impossible to achieve it when the ratio between
CPU and SPI clock is low, and the data frame is short. In this specific case, the timeout can be measured from
TXE, while calculating the fixed number of CPU clock periods corresponding to the time necessary to complete
the data frame transaction.

ES0182 - Rev 14 page 26/45

 STM32F405/407xx and STM32F415/417xx
SDIO

2.11.7 I2S2 in full-duplex mode may not work properly when SCK and WS signals are mapped on PI1
and PI0, respectively

Description
When the SCK and WS signals are used to support the I2S full-duplex through the GPIO port PI1 and PI0,
respectively, the I2S2 peripheral may not be able to provide internally the SCK and WS signals to the I2S2_ext
interface. In this case, the I2S2_ext interface is not able to send/receive data.

Workaround
Use other mapped pins for SCK and WS signals:
• I2S2 CK signal: PB10 or PB13 pin.
• I2S2 WS signal: PB12 or PB9 pin.

2.12 SDIO

2.12.1 Wrong data written during SDIO hardware flow control

Description
When enabling the hardware flow control by setting bit 14 of the SDIO_CLKCR register, glitches may occur on
the SDIOCLK output clock, resulting in wrong data to be written to the SD/MMC card or to the SDIO device. As a
consequence, a CRC error is reported to the SD/SDIO MMC host interface (DCRCFAIL bit set in the SDIO_STA
register).

Workaround
None.
Note: Do not use the hardware flow control. Overrun errors (Rx mode) and FIFO underrun (Tx mode) must be
managed by the application software.

2.12.2 Wrong CCRCFAIL status after a response without CRC is received

Description
The CRC is calculated even if the response to a command does not contain any CRC field. As a consequence,
after the SDIO command IO_SEND_OP_COND (CMD5) is sent, the CCRCFAIL bit of the SDIO_STA register is
set.

Workaround
The CCRCFAIL bit in the SDIO_STA register must be ignored by the software. CCRCFAIL must be cleared by
setting the CCRCFAILC bit of the SDIO_ICR register after receiving the response to the CMD5 command.

2.12.3 SDIO clock divider Bypass mode may not work properly

Description
In high speed communication mode, when SDIO_CK is equal to 48 MHz (PLL48_output = 48 MHz), the BYPASS
bit is equal to 1 and the NEGEDGE bit is equal to 0 (respectively bit 10 and bit 13 of the SDIO_CLKCR register),
the hold timing at the I/O pin is not aligned with the SD/MMC 2.0 specifications.

Workaround
When neither the USB nor the RNG is used, the PLL48_output (SDIOCLK) frequency can be raised to 75 MHz,
enabling to reach 37.5 MHz on SDIO_CK in high speed mode. The BYPASS bit, the CLKDIV bit, and the
NEGEDGE bit are equal to 0.

ES0182 - Rev 14 page 27/45

 STM32F405/407xx and STM32F415/417xx
bxCAN

2.12.4 Data corruption in SDIO clock dephasing (NEGEDGE) mode

Description
Setting the NEGEDGE bit may lead to invalid data and command response read.

Workaround
None.
Avoid configuring the NEGEDGE bit to 1.

2.12.5 CE-ATA multiple write command and card busy signal management

Description
The CE-ATA card may inform the host that it is busy by driving the SDIO_D0 line low, two cycles after the transfer
of a write command (RW_MULTIPLE_REGISTER or RW_MULTIPLE_BLOCK). When the card is in a busy state,
the host must not send any data until the BUSY signal is de-asserted (SDIO_D0 released by the card).
This condition is not respected if the data state machine leaves the IDLE state (write operation programmed and
started, DTEN = 1, DTDIR = 0 in the SDIO_DCTRL register, and TXFIFOE = 0 in the SDIO_STA register).
As a consequence, the write transfer fails and the data lines are corrupted.

Workaround
After sending the write command (RW_MULTIPLE_REGISTER or RW_MULTIPLE_BLOCK), the application must
check that the card is not busy by polling the BSY bit of the ATA status register using the FAST_IO (CMD39)
command before enabling the data state machine.

2.12.6 No underrun detection with wrong data transmission

Description
In case there is an ongoing data transfer from the SDIO host to the SD card and the hardware flow control is
disabled (bit 14 of the SDIO_CLKCR is not set), if an underrun condition occurs, the controller may transmit
a corrupted data block (with a wrong data word) without detecting the underrun condition when the clock
frequencies have the following relationship:
3 × period PCLK2 + 3 × period SDIOCLK ≥ 32/ BusWidth × period SDIO_CK

Workaround
Avoid the above-mentioned clock frequency relationship, by applying one of the following measures:
• Increment the APB frequency, or
• decrease the transfer bandwidth, or
• reduce SDIO_CK frequency.

2.13 bxCAN

2.13.1 bxCAN time-triggered communication mode not supported

Description
The time-triggered communication mode described in the reference manual is not supported. As a result,
timestamp values are not available. The TTCM bit of the CAN_MCR register must be kept cleared (time-triggered
communication mode disabled).

Workaround
None.

ES0182 - Rev 14 page 28/45

 STM32F405/407xx and STM32F415/417xx
OTG_FS

2.14 OTG_FS

2.14.1 Transmit data FIFO is corrupted when a write sequence to the FIFO is interrupted with
accesses to certain OTG_FS registers

Description
When the USB on-the-go full-speed peripheral is in Device mode, interrupting transmit FIFO write sequence with
read or write accesses to OTG_FS endpoint-specific registers (those ending in 0 or x) leads to corruption of the
next data written to the transmit FIFO.

Workaround
Ensure that the transmit FIFO write sequence is not interrupted with accesses to the OTG_FS registers.

2.14.2 Host packet transmission may hang when connecting through a hub to a low-speed device

Description
When the USB on-the-go full-speed peripheral connects to a low-speed device via a hub, the transmitter internal
state machine may hang. This leads, after a timeout expiry, to a port disconnect interrupt.

Workaround
None. However, increasing the capacitance on the data lines may reduce the occurrence.

2.14.3 Data in RxFIFO is overwritten when all channels are disabled simultaneously

Description
If the available RxFIFO is just large enough to host one packet plus its data status, and it is currently occupied by
the last received data plus its status, and, at the same time, the application requests that more IN channels are
disabled, the OTG_FS peripheral does not first check for available space before inserting the disabled status of
the IN channels. It just inserts them by overwriting the existing data payload.

Workaround
Use one of the following measures:
• Configure the RxFIFO to host a minimum of 2 × MPSIZ + 2 × data status entries.
• Check the RXFLVL bit (RxFIFO nonempty) of the OTG_FS_GINTSTS register before disabling each IN
channel. If this bit is cleared, then disable an IN channel at a time. Each time the application disables an IN
channel, it first has to check that the RXFLVL bit = 0 condition is true.

2.14.4 OTG host blocks the receive channel when receiving IN packets and no TxFIFO is configured

Description
When receiving data, the OTG_FS core erroneously checks for available TxFIFO space when it should only
check for RxFIFO space. If the OTG_FS core cannot see any space allocated for data transmission, it blocks the
reception channel, and no data is received.

Workaround
Set at least one TxFIFO equal to the maximum packet size. In this way, the host application, which intends to
supports only IN traffic, also has to allocate some space for the TxFIFO.
Since a USB host is expected to support any kind of connected endpoint, it is good practice to always configure
enough TxFIFO space for OUT endpoints.

ES0182 - Rev 14 page 29/45

 STM32F405/407xx and STM32F415/417xx
OTG_HS

2.14.5 Host channel-halted interrupt not generated when the channel is disabled

Description
When the application enables then immediately disables the host channel before the OTG_FS host has had time
to begin the transfer sequence, the OTG_FS core, as a host, does not generate a channel-halted interrupt. The
OTG_FS core continues to operate normally.

Workaround
Do not disable the host channel immediately after enabling it.

2.14.6 Wrong software-read OTG_FS_DCFG register values

Description
When the application writes to the DAD and PFIVL bitfields of the OTG_FS_DCFG register, and then reads the
newly written bitfield values, the read values may not be correct.
However, the values written by the application are correctly retained by the core, and the normal operation of the
device is not affected.

Workaround
Do not read the OTG_FS_DCFG register DAD and PFIVL bitfields just after programming them.

2.15 OTG_HS

2.15.1 Transmit data FIFO is corrupted when a write sequence to the FIFO is interrupted with
accesses to certain OTG_HS registers

Description
When the USB on-the-go high-speed peripheral is in Device mode, interrupting transmit FIFO write sequence with
read or write accesses to OTG_HS endpoint-specific registers (those ending in 0 or x) leads to corruption of the
next data written to the transmit FIFO.

Workaround
Ensure that the transmit FIFO write sequence is not interrupted with accesses to the OTG_HS registers. Note that
enabling DMA mode guarantees this.

2.15.2 Host packet transmission may hang when connecting the full speed interface through a hub to
a low-speed device

Description
When the USB on-the-go high-speed peripheral is used with the full speed interface (DM and DP pins, N.B. not
available on all devices), and connects to a low-speed device via a hub, the transmitter internal state machine
may hang. This leads, after a timeout expiry, to a port disconnect interrupt.

Workaround
None. However, increasing the capacitance on the data lines may reduce the occurrence.

ES0182 - Rev 14 page 30/45

 STM32F405/407xx and STM32F415/417xx
ETH

2.16 ETH

2.16.1 Incorrect L3 checksum is inserted in transmitted IPv6 packets without TCP, UDP or ICMP
payloads

Description
The application provides a frame-by-frame control to instruct the MAC to insert the layer 3 (L3) checksums for
TCP, UDP and ICMP packets. When automatic checksum insertion is enabled and the input packet is an IPv6
packet without the TCP, UDP or ICMP payload, then the MAC may incorrectly insert a checksum into the packet.
For IPv6 packets without a TCP, UDP or ICMP payload, the MAC core considers the next header (NH) field as
the extension header and continues to parse the extension header. Sometimes, the payload data in such packets
matches the NH field for TCP, UDP or ICMP and, as a result, the MAC core inserts a checksum.

Workaround
When the IPv6 packets have a TCP, UDP or ICMP payload, enable checksum insertion for transmit frames, or
bypass checksum insertion by using the CIC bits of the TDES0 transmit descriptor word0.

2.16.2 The ethernet MAC processes invalid extension headers in the received IPv6 frames

Description
In IPv6 frames, the extension headers which precede the actual IP payload may or may not be present. The
Ethernet MAC processes the following extension headers defined in the IPv6 protocol: hop-by-hop options
header, routing header and destination options header.
All extension headers, except the hop-by-hop extension header, can be present multiple times and in any order
before the actual IP payload. The hop-by-hop extension header, if present, has to come immediately after the
IPv6 main header.
The Ethernet MAC processes all extension headers whether valid or invalid including the hop-by-hop extension
headers that are present after the first extension header. For this reason, the GMAC core will accept IPv6 frames
with invalid hop-by-hop extension headers. As a consequence, it will accept any IP payload as valid IPv6 frames
with TCP, UDP or ICMP payload, and then incorrectly update the receive status of the corresponding frame.

Workaround
None.

2.16.3 MAC stuck in the idle state on receiving the TxFIFO flush command exactly one clock cycle
after a transmission completes

Description
When the software issues a TxFIFO flush command, the transfer of frame data stops, even in the middle of a
frame transfer. The TxFIFO read controller goes into the Idle state by clearing the TFRS [1:0] bit field of the
ETH_MACDBGR register. It then resumes its normal operation.
However, if the TxFIFO read controller receives the TxFIFO flush command exactly one clock cycle after receiving
the status from the MAC, the controller remains stuck in the Idle state and stops transmitting frames from the
TxFIFO. The system only recovers from this state with a reset (for example a soft reset).

Workaround
Wait until the TxFIFO is empty before using the TxFIFO flush command.

2.16.4 Transmit frame data corruption

Description
Frame data may get corrupted when the TxFIFO repeatedly switches from non-empty to empty, and back to
non-empty again for a very short period, without causing any underflow.

ES0182 - Rev 14 page 31/45

 STM32F405/407xx and STM32F415/417xx
ETH

The issue occurs when switching back and forth between non-empty and empty happens when the rate the data
is being written to the TxFIFO is almost equal to or a little slower than the rate at which the data is read.
This corruption cannot be detected by the receiver when the CRC is inserted by the MAC, as the corrupted data is
used for the CRC computation.

Workaround
Use the transmit Store-and-Forward mode by setting the TSF bit of the ETH_DMAOMR register. In this mode, the
data is transmitted only when the whole packet is available in the TxFIFO.

2.16.5 Incorrect status and corrupted frames when RxFIFO overflow occurs on the penultimate word
of Rx frames

Description
When operating in Threshold mode, the RxFIFO may overflow when the received frame data is written faster than
the speed at which the application reads it from the RxFIFO. The RxFIFO overflow is declared at the moment that
a non-EOF word is received and the RxFIFO has only two locations available. The receiver descriptor overflow
error (OE) bit of the RDES0 receive descriptor word0 is set to indicate that the receive frame is incomplete.
The problem occurs after the following events:
1. RxFIFO overflow is declared exactly on the penultimate word of the Rx Frame.
The EOF word is received in the next clock cycle.
2. The EOF word has exactly one valid byte. This is possible only when the length of the packet, after CRC or
PAD stripping (if enabled), is a multiple of 4 bytes plus 1 (for example, 5, 9, 13, 17).
After the above sequence, the frames status information is corrupted and the overflow error flag is not set.
Furthermore, if the next frame arrives soon enough, the MAC might falsely interpret that there is space in the
RxFIFO and overwrite unread data with the next frame, thus corrupting the existing frames.
The MAC recovers automatically after transferring a few corrupt or incorrect packets.

Workaround
Operate the RxFIFO in the Store-and-Forward mode.

2.16.6 Successive write operations to the same register might not be fully taken into account

Description
A write to a register might not be fully taken into account if a previous write to the same register is performed
within a time period of four TX_CLK/RX_CLK clock cycles. When this error occurs, reading the register returns
the most recently written value, but the Ethernet MAC continues to operate as if the latest write operation never
occurred.
Refer to the following table for the registers and bits impacted by this limitation.
Impacted registers and bits

Register name Bit number Bit name

DMA registers
ETH_DMABMR 7 EDFE
26 DTCEFD
25 RSF
20 FTF
ETH_DMAOMR
7 FEF
6 FUGF
4:3 RTC
GMAC registers

ETH_MACCR 25 CSTF

ES0182 - Rev 14 page 32/45

 STM32F405/407xx and STM32F415/417xx
ETH

Register name Bit number Bit name

23 WD
22 JD
19:17 IFG
16 CSD
14 FES
13 ROD
12 LM
ETH_MACCR 11 DM
10 IPCO
9 RD
7 APCS
6:5 BL
4 DC
3 TE
2 RE
ETH_MACFFR MAC - frame filter register
ETH_MACHTHR 31:0 Hash Table High Register
ETH_MACHTLR 31:0 Hash Table Low Register
31:16 PT
7 ZQPD
5:4 PLT
ETH_MACFCR 3 UPFD
2 RFCE
1 TFCE
0 FCB/BPA
16 VLANTC
ETH_MACVLANTR
15:0 VLANTI
ETH_MACRWUFFR - all remote wakeup registers
31 WFFRPR
9 GU
ETH_MACPMTCSR 2 WFE
1 MPE
0 PD
ETH_MACA0HR - MAC address 0 high register
ETH_MACA0LR - MAC address 0 low register
ETH_MACA1HR - MAC address 1 high register
ETH_MACA1LR - MAC address 1 low register
ETH_MACA2HR - MAC address 2 high register
ETH_MACA2LR - MAC address 2 low register
ETH_MACA3HR - MAC address 3 high register
ETH_MACA3LR - MAC address 3 low register

ES0182 - Rev 14 page 33/45

 STM32F405/407xx and STM32F415/417xx
ETH

Register name Bit number Bit name

IEEE 1588 time stamp registers

18 TSPFFMAE
17:16 TSCNT
15 TSSMRME
14 TSSEME
13 TSSIPV4FE
12 TSSIPV6FE
11 TSSPTPOEFE
ETH_PTPTSCR 10 TSPTPPSV2E
9 TSSSR
8 TSSARFE
5 TSARU
3 TSSTU
2 TSSTI
1 TSFCU
0 TSE

Workaround
Applty on of the following measures:
• Ensure a delay of four TX_CLK/RX_CLK clock cycles between the successive write operations to the same
register.
• Make several successive write operations without delay, then read the register when all the operations are
complete, and finally reprogram it after a delay of four TX_CLK/RX_CLK clock cycles.

2.16.7 Incorrect remote wakeup on global unicast packet

Description
The PMT remote wakeup block can be enabled to generate remote wakeup interrupt on receiving a global unicast
packet, for example a unicast destination address (DA) that perfectly matches one of the MAC address registers
enabled for DA.
However, the PMT remote wakeup block generates interrupts for any unicast packet that passes the DA filter (not
necessarily for a unicast packet that passes DA perfect filter). For example, the address filter is set for inverse
filtering or hash filtering, it gives a PASS for any packet whose DA is accepted by the inverse/hash filter. This
results in power down exit on unintended received packets.

Workaround
Only enable DA perfect filter when global unicast based remote wakeup is enabled.

2.16.8 Overflow status bits of missed frame and buffer overflow counters are cleared without a read
operation

Description
The direct memory access (DMA) controller maintains two counters to track the number of frames missed
because of the following events:
• Rx descriptor not being available
• Rx FIFO buffer overflow during reception

ES0182 - Rev 14 page 34/45

 STM32F405/407xx and STM32F415/417xx
ETH

The missed frame and buffer overflow counter of the ETH_DMAMFBOCR register indicate the current value of
the missed frames and FIFO overflow frame counters. This register also has the overflow status bits: OFOC
bit OMFC bit which indicate whether the rollover occurred for the respective counters and are set when the
respective counters roll over. They should remain set until this register is read.
However, when the counter rollover occurs a second time after the status bit is set, the respective status bits
are cleared. Therefore, the application may incorrectly detect that the rollover did not occur since the last read
operation.

Workaround
The application should read the missed frame and buffer overflow counter register periodically (or after the
overflow or rollover status bits are set) such that the counter rollover does not occur twice between read
operations.

2.16.9 MAC may provide incorrect Rx status for the MAC control frames when receive checksum
offload is enabled

Description
The MAC can be programmed to forward the MAC control frames (with length/type field 0x8808) to the application
by setting the PCF bits of the ETH_MACFFR register. When the IPv4 checksum offload function is enabled by
setting the IPCO bit of the ETH_MACCR register and clearing the EDFE bit of the ETH_DMABMR register, the
MAC provides the encoded Rx status in the FT bit, IPHCE/TSV bit, and the PCE/ESA bit of the RDES0 receive
descriptor word0. When a MAC control frame is received, the MAC should provide 0b011 in RDES0 receive
descriptor word0 of Rx status. This indicates that an Ethernet type frame is received, which is neither IPv4 nor
IPv6 (the checksum offload engine bypasses the checksum completely).
However, when a MAC control frame is received with IPv4 checksum offload function enabled without the
extended status, the MAC provides incorrect Rx status (0b100) in RDES0 receive descriptor word0, indicating
that an IPv4 or IPv6 type frame is received with no checksum error.

Workaround
Ignore these status bits, as reported in the RDES0 receive descriptor word0, about IP header error after it
identifies the control packet from the received packet and processes it accordingly.

2.16.10 MAC may provide an inaccurate Rx status when receive checksum offload is enabled in cut-
through mode

Description
The MAC can be programmed in cut-through mode by resetting the DTCEFD bit of the ETH_DMAOMR register.
When IPv4 checksum offload function is enabled by setting the IPCO bit of ETH_MACCR register and extended
status is not enabled, the MAC provides the bit 25 (error summary), bit 14 (descriptor error), bit 11 (overflow
error), bit 7 (IPC checksum error), bit 6 (late collision), bit 4 (watchdog error), bit 3 (receive error) and bit 0
(payload checksum error) of the RDES0: Receive descriptor Word0.
However, when a frame with a payload checksum error is received with the IPv4 checksum offload function
enabled without the extended status, the MAC provides a correct error summary status but an incorrect Rx status
on bit 0, indicating the IPv4 or IPv6 type frame is received with no checksum error. The source of the error is not
specified, none of the individual status bits are set.

Workaround
Enable the Store-and-Forward mode by setting the RSF bit of the ETH_DMAOMR register. In this case the faulty
frames are silently discarded as expected.

ES0182 - Rev 14 page 35/45

 STM32F405/407xx and STM32F415/417xx
ETH

2.16.11 MAC may not drop received giant error frames

Description
The MAC considers a received frame with a length of more than 1522 bytes, as a giant error frame. When
RxFIFO is operating in the Store-and-Forward mode and is programmed to drop error frames, by resetting the
FEF bit of the ETH_DMAOMR, all error frames should be dropped in the FIFO layer. Due to the error frames
being dropped in the FIFO layer, the DMA controller does not send them to the host.
However, the MAC does not drop the giant error frames and the DMA controller unnecessarily wastes system
bandwidth transferring the giant frame to the host.

Workaround
The software driver must check the FL bits of the RDES0 receive descriptor word0, ignore or drop the frame and
not forward it to the upper layer.
The frame length field is valid only when the LS bit of the RDES0 receive descriptor word0 register is set and the
DE bit of the RDES0 receive descriptor word0 is reset.

ES0182 - Rev 14 page 36/45

 STM32F405/407xx and STM32F415/417xx

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.

ES0182 - Rev 14 page 37/45

 STM32F405/407xx and STM32F415/417xx

Revision history
Table 6. Document revision history

Date Version Changes

19-Sep-2011 1 Initial release.

Replaced STM42F4xx by STM32F4xx on cover page.
Added silicon revision Z.

Modified link to Arm 32-bit Cortex-M4F errata notice in Section 1: Arm® 32-bit
Cortex®-M4 with FPU limitations.
Updated status of ART Accelerator prefetch queue and MCU device ID
limitations for revision Z in Table 4: Summary of silicon limitations.
Updated Section 2.1.1: ART Accelerator prefetch queue instruction is not
supported and Section 2.1.2: MCU device ID is incorrect to make differentiate
12-Dec-2011 2 between revision A and revision Z devices.
Added Section 2.1.6: Full JTAG configuration without NJTRST pin cannot
be used, Section 2.1.7: PDR_ON pin not available on LQFP100 package
for revision Z devices, Section 2.1.8: Incorrect BOR option byte when
consecutively programming BOR option byte, and Section 2.1.9: Configuration
of PH10 and PI10 as external interrupts is erroneous.
Updated workaround for Section 2.8.5: nRTS signal abnormally riven low after
a protocol violation.
Added Section 2.13.2: Wrong CCRCFAIL status after a response without CRC
is received and Section 2.3.1: RVU and PVU flags are not reset in Stop mode.
Added Section : None., Section 2.1.11: Slowing down APB clock during a
DMA transfer, Section 2.1.12: MPU attribute to RTC and IWDG registers could
be managed incorrectly, Section 2.1.13: Delay after an RCC peripheral clock
enabling, Section 2.1.14: Battery charge monitoring lower than 2.4 Volts and
Appendix A: Revision code on device marking.
Added Section 2.12.2: FSMC synchronous mode and NWAIT signal disabled.
03-Aug-2012 3 Added Section 2.13.3: SDIO clock divider BYPASS mode may not
work properly, Section 2.13.4: Data corruption in SDIO clock dephasing
(NEGEDGE) mode and Section 2.13.5: CE-ATA multiple write command and
card busy signal management.
Added Section 2.15: DAC peripheral limitations with Section 2.15.1:
DMA underrun flag management and Section 2.15.2: DMA request not
automatically cleared by DMAEN=0.
Added Section 1.2: VDIV or VSQRT instructions might not complete correctly
when very short ISRs are used.
Removed the reference to ‘Cortex-M4F’ in the whole document.
Updated Table 2: Device summary, Section 2.1.2: MCU device ID is incorrect.
Added Section 2.1.5: Wakeup sequence from Standby mode when using
more than one wakeup source.
Updated Section 2.12.1: Dummy read cycles inserted when reading
synchronous memories.
25-Apr-2013 4
Added Section 2.2: TIM limitations, Section 2.7.2: I2S2 in full-duplex mode
may not work properly when SCK and WS signals are mapped on PI1 and
PI0 respectively, Section 2.11.5: Successive write operations to the same
register might not be fully taken into account and Section 2.12.3: FSMC NOR
Flash/PSRAM controller asynchronous access on bank 2 to 4 when bank 1 is
in synchronous mode (CBURSTRW bit is set) , Section 2.13.6: No underrun
detection with wrong data transmission and Section 2.14.1: ADC sequencer
modification during conversion.
Added Figure 6: WLCSP90 top package view.
Added silicon revision 1.
11-Oct-2013 5 Added Section 2.5.5: Both SDA and SCL maximum rise time (tr) violated
when VDD_I2C bus higher than ((VDD+0.3) / 0.7) V.

ES0182 - Rev 14 page 38/45

 STM32F405/407xx and STM32F415/417xx

Date Version Changes

Moved device marking to datasheets.
Added: rev 2 and Y on Table 1: Device identification, Section 1.2: VDIV or
VSQRT instructions might not complete correctly when very short ISRs are
used.
Section 2.4: RTC limitations: updated Section 2.8.6: Start bit detected too
21-Jan-2015 6
soon when sampling for NACK signal from the smartcard to Section 2.8.9:
nRTS is active while RE or UE = 0
Section 2.9: bxCAN limitations: updated Table 4: Summary of silicon
limitations.
Added:Section 2.6: SPI peripheral limitations, Section 2.6.1: Wrong CRC
calculation when the polynomial is even, Section 2.5.6: Spurious Bus Error
detection in Master mode. Section 2.4.7: Wrong behavior related with MCU
Stop mode when wakeup from Stop mode by I2C peripheral is disabled.
Section 2.6.3: BSY bit may stay high at the end of a data transfer in Slave
mode. Section 2.6.2: Corrupted last bit of data and/or CRC, received in
14-Sep-2015 7
Master mode with delayed SCK feedback.
Updated:Section 2.1.10: DMA2 data corruption when managing AHB and APB
peripherals in a concurrent way.
Replaced Section 2.1.5: Debugging Stop mode with WFE entry with Section
2.1.3: Debugging Sleep/Stop mode with WFE/WFI entry.
Added workaround in Section 2.1.13: Delay after an RCC peripheral clock
enabling.
Added Section 2.4.3: RTC calendar registers are not locked properly.
Updated Section 2.6.2: Corrupted last bit of data and/or CRC, received in
Master mode with delayed SCK feedback and added Section 2.5.3: Wrong
CRC transmitted in Master mode with delayed SCK feedback. Updated
24-Nov-2016 8 Section 2.6.3: BSY bit may stay high at the end of a data transfer in Slave
mode.
Updated limitation description in Section 2.5.2: Start cannot be generated
after a misplaced Stop.
Added Section 2.7.3: Corrupted last bit of data and/or CRC, received in
Master mode with delayed SCK feedback in Section 2.7: I2S peripheral
limitations
Removed Section Wrong CRC transmitted in Master mode with delayed
SCK feedback and Section 2.4.7: Wrong behavior related with MCU Stop
mode when wakeup from Stop mode by I2C peripheral is disabled. The I2C
04-Jul-2017 9 limitation does not apply to STM32F40x and STM32F41x microcontrollers.
Updated Section 2.6.2: Corrupted last bit of data and/or CRC, received in
Master mode with delayed SCK feedback
Added revision code “4” in Table 1: Device identification.
24-Apr-2019 10 Updated Table 4: Summary of silicon limitations.
Added Section 2.1.16: RDP level 2 and sector write protection configuration.
Added Section 2.1.17: Possible delay in backup domain protection disabling/
05-Dec-2019 11
enabling after programming the DBP bit.
08-Apr-2020 12 Added revision code “4” on document cover page.
Removed list of revisions from Section : Silicon identification introduction.
04-Jan-2021 13
Added revision 5 and 6. Added Section 2.2: TIM limitations.

21-Feb-2023 14 Core: added Store immediate overlapping exception return operation might
vector to incorrect interrupt erratum.

ES0182 - Rev 14 page 39/45

 STM32F405/407xx and STM32F415/417xx

Date Version Changes

System:
• Updated workaround of ART Accelerator prefetch queue instruction
is not supported, MCU device ID is incorrect, Debugging Sleep/Stop
mode with WFE/WFI entry, and Delay after an RCC peripheral clock
enabling errata.
• Updated Configuration of PH10 and PI10 as external interrupts is
erroneous erratum description.
• Updated In some specific cases, DMA2 data corruption occurs when
managing AHB and APB2 peripherals in a concurrent way erratum.
• Added PC13 signal transitions disturb LSE erratum.
IWDG: added RVU flag not cleared at low APB clock frequency and PVU flag
not cleared at low APB clock frequency errata.
RTC: added RTC interrupt can be masked by another RTC interrupt, Calendar
initialization may fail in case of consecutive INIT mode entry and Alarm flag
may be repeatedly set when the core is stopped in debug errata.
USART:
• Changed nCTS and nRTS to CTS and RTS respectively.
• Updated Break request can prevent the transmission complete flag
(TC) from being set and Guard time not respected when data are sent
on TXE events erratum workarounds.
SPI/I2S: added BSY bit may stay high when SPI is disabled, and Anticipated
communication upon SPI transit from slave receiver to master errata.
SDIO: updated Wrong data written during SDIO hardware flow control erratum
title.
OTG_FS: added Transmit data FIFO is corrupted when a write sequence to
the FIFO is interrupted with accesses to certain OTG_FS registers and Host
packet transmission may hang when connecting through a hub to a low-speed
device errata.
Added OTG_HS errata.
ETH: added Incorrect status and corrupted frames when RxFIFO overflow
occurs on the penultimate word of Rx frames, Incorrect remote wakeup
on global unicast packet, Overflow status bits of missed frame and buffer
overflow counters are cleared without a read operation, MAC may provide
incorrect Rx status for the MAC control frames when receive checksum
offload is enabled, MAC may provide an inaccurate Rx status when receive
checksum offload is enabled in cut-through mode and MAC may not drop
received giant error frames errata.
Added Section Important security notice.

ES0182 - Rev 14 page 40/45

 STM32F405/407xx and STM32F415/417xx
Contents

Contents
1 Summary of device errata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Description of device errata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Interrupted loads to SP can cause erroneous behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 VDIV or VSQRT instructions might not complete correctly when very short ISRs are used . 6
2.1.3 Store immediate overlapping exception return operation might vector to incorrect interrupt 7
2.2 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 ART Accelerator prefetch queue instruction is not supported . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 MCU device ID is incorrect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Debugging Stop mode and SysTick timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Debugging Stop mode with WFE entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Debugging Sleep/Stop mode with WFE/WFI entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.6 Wake-up sequence from Standby mode when using more than one wake-up source . . . . 10
2.2.7 Full JTAG configuration without NJTRST pin cannot be used . . . . . . . . . . . . . . . . . . . . . . 10
2.2.8 PDR_ON pin not available on LQFP100 package except for revision A devices . . . . . . . . 10
2.2.9 Incorrect BOR option byte when consecutively programming BOR option byte. . . . . . . . . 11
2.2.10 Configuration of PH10 and PI10 as external interrupts is erroneous . . . . . . . . . . . . . . . . . 11
2.2.11 Slowing down APB clock during a DMA transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.12 MPU attribute to RTC and IWDG registers incorrectly managed . . . . . . . . . . . . . . . . . . . . 11
2.2.13 Delay after an RCC peripheral clock enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.14 Battery charge monitoring lower than 2.4 V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.15 Internal noise impacting the ADC accuracy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.16 RDP level 2 and sector write protection configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.17 Possible delay in backup domain protection disabling/enabling after programming the DBP
bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.18 PC13 signal transitions disturb LSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.19 In some specific cases, DMA2 data corruption occurs when managing AHB and APB2
peripherals in a concurrent way . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 FSMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Dummy read cycles inserted when reading synchronous memories . . . . . . . . . . . . . . . . . 13
2.3.2 FSMC synchronous mode and NWAIT signal disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 FSMC NOR/PSRAM controller: asynchronous read access on bank 2 to 4 returns wrong
data when bank 1 is in synchronous mode (BURSTEN bit is set) . . . . . . . . . . . . . . . . . . . 14
2.4 ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 ADC sequencer modification during conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 DAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 DMA request not automatically cleared by clearing DMAEN . . . . . . . . . . . . . . . . . . . . . . . 14

ES0182 - Rev 14 page 41/45

 STM32F405/407xx and STM32F415/417xx
Contents

2.5.2 DMA underrun flag not set when an internal trigger is detected on the clock cycle of the
DMA request acknowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 TIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.1 PWM re-enabled in automatic output enable mode despite of system break. . . . . . . . . . . 15
2.6.2 TRGO and TRGO2 trigger output failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.3 Consecutive compare event missed in specific conditions . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.4 Output compare clear not working with external counter reset . . . . . . . . . . . . . . . . . . . . . 16
2.7 IWDG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.1 RVU flag not reset in Stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.2 PVU flag not reset in Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.3 RVU flag not cleared at low APB clock frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.4 PVU flag not cleared at low APB clock frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 RTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.1 Spurious tamper detection when disabling the tamper channel. . . . . . . . . . . . . . . . . . . . . 17
2.8.2 RTC calendar registers are not locked properly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.3 RTC interrupt can be masked by another RTC interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.4 Calendar initialization may fail in case of consecutive INIT mode entry . . . . . . . . . . . . . . . 19
2.8.5 Alarm flag may be repeatedly set when the core is stopped in debug . . . . . . . . . . . . . . . . 20
2.8.6 Detection of a tamper event occurring before enabling the tamper detection is not
supported in edge detection mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9 I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.1 SMBus standard not fully supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.2 Start cannot be generated after a misplaced Stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.3 Mismatch on the “Setup time for a repeated Start condition” timing parameter . . . . . . . . . 21
2.9.4 Data valid time (tVD;DAT) violated without the OVR flag being set . . . . . . . . . . . . . . . . . . . 21
2.9.5 Both SDA and SCL maximum rise times (tr) violated when the VDD_I2C bus voltage is
higher than ((VDD + 0.3) / 0.7) V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.6 Spurious bus error detection in Master mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10 USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10.1 Idle frame is not detected if the receiver clock speed is deviated . . . . . . . . . . . . . . . . . . . 22
2.10.2 In full-duplex mode, the Parity Error (PE) flag can be cleared by writing to the data register .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10.3 Parity Error (PE) flag is not set when receiving in Mute mode using address mark detection
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.10.4 Break frame is transmitted regardless of CTS input line status . . . . . . . . . . . . . . . . . . . . . 23
2.10.5 RTS signal abnormally driven low after a protocol violation. . . . . . . . . . . . . . . . . . . . . . . . 23
2.10.6 Start bit detected too soon when sampling for NACK signal from the smartcard . . . . . . . . 23
2.10.7 Break request can prevent the transmission complete flag (TC) from being set . . . . . . . . 24
2.10.8 Guard time not respected when data are sent on TXE events. . . . . . . . . . . . . . . . . . . . . . 24

ES0182 - Rev 14 page 42/45

 STM32F405/407xx and STM32F415/417xx
Contents

2.10.9 RTS is active while RE or UE = 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.11 SPI/I2S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.11.1 BSY bit may stay high when SPI is disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.11.2 In I2S slave mode, enabling I2S while WS is active causes desynchronization . . . . . . . . . 25
2.11.3 Anticipated communication upon SPI transit from slave receiver to master. . . . . . . . . . . . 25
2.11.4 Wrong CRC calculation when the polynomial is even . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.11.5 Corrupted last bit of data and/or CRC received in Master mode with delayed SCK feedback
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.11.6 BSY flag may stay high at the end of a data transfer in Slave mode . . . . . . . . . . . . . . . . . 26
2.11.7 I2S2 in full-duplex mode may not work properly when SCK and WS signals are mapped on
PI1 and PI0, respectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.12 SDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.12.1 Wrong data written during SDIO hardware flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.12.2 Wrong CCRCFAIL status after a response without CRC is received . . . . . . . . . . . . . . . . . 27
2.12.3 SDIO clock divider Bypass mode may not work properly . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.12.4 Data corruption in SDIO clock dephasing (NEGEDGE) mode . . . . . . . . . . . . . . . . . . . . . . 28
2.12.5 CE-ATA multiple write command and card busy signal management . . . . . . . . . . . . . . . . 28
2.12.6 No underrun detection with wrong data transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.13 bxCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.13.1 bxCAN time-triggered communication mode not supported. . . . . . . . . . . . . . . . . . . . . . . . 28
2.14 OTG_FS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.14.1 Transmit data FIFO is corrupted when a write sequence to the FIFO is interrupted with
accesses to certain OTG_FS registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.14.2 Host packet transmission may hang when connecting through a hub to a low-speed device
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.14.3 Data in RxFIFO is overwritten when all channels are disabled simultaneously . . . . . . . . . 29
2.14.4 OTG host blocks the receive channel when receiving IN packets and no TxFIFO is
configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.14.5 Host channel-halted interrupt not generated when the channel is disabled . . . . . . . . . . . . 30
2.14.6 Wrong software-read OTG_FS_DCFG register values . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.15 OTG_HS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.15.1 Transmit data FIFO is corrupted when a write sequence to the FIFO is interrupted with
accesses to certain OTG_HS registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.15.2 Host packet transmission may hang when connecting the full speed interface through a hub
to a low-speed device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.16 ETH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.16.1 Incorrect L3 checksum is inserted in transmitted IPv6 packets without TCP, UDP or ICMP
payloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.16.2 The ethernet MAC processes invalid extension headers in the received IPv6 frames . . . . 31
2.16.3 MAC stuck in the idle state on receiving the TxFIFO flush command exactly one clock cycle
after a transmission completes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

ES0182 - Rev 14 page 43/45

 STM32F405/407xx and STM32F415/417xx
Contents

2.16.4 Transmit frame data corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.16.5 Incorrect status and corrupted frames when RxFIFO overflow occurs on the penultimate
word of Rx frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.16.6 Successive write operations to the same register might not be fully taken into account . . 32
2.16.7 Incorrect remote wakeup on global unicast packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.16.8 Overflow status bits of missed frame and buffer overflow counters are cleared without a
read operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.16.9 MAC may provide incorrect Rx status for the MAC control frames when receive checksum
offload is enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.16.10 MAC may provide an inaccurate Rx status when receive checksum offload is enabled in
cut-through mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.16.11 MAC may not drop received giant error frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Important security notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

ES0182 - Rev 14 page 44/45

 STM32F405/407xx and STM32F415/417xx

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

ES0182 - Rev 14 page 45/45