All Errata Descriptions
[RMT-176] The Idle State Signal Level Might Run into Error in RMT Continuous TX Mode
Description
In ESP32-P4’s RMT module, if the continuous TX mode is enabled, it is expected that the data transmission stops after the data is sent for RMT_TX_LOOP_NUM_CHn rounds, and after that, the signal level in idle state should be controlled by the “level” field of the end-marker.
However, in real situation, after the data transmission stops, the channel’s idle state signal level is not controlled by the “level” field of the end-marker, but by the level in the data wrapped back, which is indeterminate.
Workarounds
Users are suggested to set RMT_IDLE_OUT_EN_CHn to 1 to only use registers to control the idle level.
This issue has been bypassed since the first ESP-IDF version that supports continuous TX mode (v5.2). In these versions of ESP-IDF, it is configured that the idle level can only be controlled by registers.
Solution
Fixed in chip revision v3.0.
[I2C-308] I2C Slave Fails in Multiple-read Under Non-FIFO Mode
Description
If the I2C slave non-FIFO mode is enabled and the master performs multiple-read operation on the slave, the master can not correctly read the data from the slave.
Workarounds
Set I2C_FIFO_ADDR_CFG_EN and I2C_SLV_TX_AUTO_START_EN to 1 and I2C_FIFO_PRT_EN to 0 for the slave.
After configuration, the master must access the slave using the following command sequence: RSTART -> WRITE (slave addr, fifo addr) -> RSTART -> WRITE (slave addr) -> READ (NACK) -> STOP, with only one byte allowed to be read each time.
Solution
Fixed in chip revision v3.0.
[MSPI-749] Load Access Fault During Chip Power-on or Deep-Sleep Wake-up
Description
During the power-on or wake-up process of ESP32-P4, due to abnormal handling inside the MSPI IP read-request channel, the MSPI may fail to correctly process the first and second access requests initiated by the AXI system bus. This can occasionally result in unexpected error responses, causing the boot process to fail.
Workarounds
Power-on sequence: The power-on sequence is fixed. If the sequence fails, the system can only rely on the watchdog timeout to reset the chip and perform a “second power-on”. After this second power-on, the flash MSPI module can resume normal operation.
Wake-up sequence: During the Deep-sleep wake-up, the LP memory region remains powered and retains its contents. A small executable program can be pre-loaded into LP memory before entering sleep. This program should perform two dummy read accesses. Upon wake-up, the CPU will execute this program first and then jump to the ROM code to continue the normal boot process. The code is as follows:
REG32_WR(0x500ca000, 0x23);
CLEAR_PERI_REG_MASK(0x5008c03c, 0x80000000);
// Disable CPU error response handling
SET_PERI_REG_MASK(0x500e51a4, 0x00000007);
// Enable AXI interface
REG32_WR(0x500ca000, 0x23);
SET_PERI_REG_MASK(0x5008c03c, 0x00000001);
// Configure one MSPI MMU entry to map the AXI address to the flash address
REG32_WR(0x500ca000, 0x23);
SET_PERI_REG_MASK(0x5008c380, 0x0);
REG32_WR(0x500ca000, 0x23);
SET_PERI_REG_MASK(0x5008c37c, 0x1000);
//Perform the first and second AXI read accesses from flash MSPI
REG32_RD(0x80000000);
REG32_WR(0x500ca000, 0x23);
REG32_RD(0x80000040);
REG32_WR(0x500ca000, 0x23);
//Re-enable CPU error response handling
CLEAR_PERI_REG_MASK(0x500e51a4, 0x00000007);
SET_PERI_REG_MASK(0x50111014, 0x8000);
SET_PERI_REG_MASK(0x50111014, 0x2000);
PSRAM MSPI: During PSRAM MSPI initialization, inserting two dummy reads before the first actual AXI read access can effectively avoid the initial access anomaly.
Solution
Fixed in chip revision v3.1.
[MSPI-750] PSRAM Unaligned DMA Read Operations May Return Old Data When Accessing Overlapping Addresses
Description
When accessing PSRAM randomly through DMA or CACHE, if a write operation to a certain address range is followed by a read operation to the same range, data readout errors may occur. The triggering conditions are:
Any write request is executed.
The read operation is a DMA-initiated read request with a burst size of 1 byte or 2 bytes, and the access address is not 4-byte aligned.
The address range accessed by the read operation overlaps with the address range previously written.
Under these conditions, the read operation may fail to obtain the new data written by the prior write operation and instead return old data that existed in PSRAM before the write.
Root cause: The MSPI IP’s internal “address overlap detection” mechanism has an anomaly when processing the above unaligned read requests. The computed address range used for overlap detection may be 1 to 3 bytes shorter at the end than the actual address range the read request should access. This defect may cause the overlap detection to fail, resulting in incorrect data reads.
Workarounds
It is recommended that software applications enforce 4-byte alignment for all masters that may issue unaligned accesses (for example, burst sizes of 1 or 2 bytes), such as USB or SDMMC. This prevents the issue from occurring.
Solution
Fixed in chip revision v3.1.
[MSPI-751] Data Errors Caused by Asynchronous Timing Issues in the MSPI Address Overlap Detection Function When Read/Write Operations Overlap at Specific Frequencies
Description
When accessing PSRAM randomly through DMA or CACHE, if a write operation to a certain address range is followed by a read operation to the same range, data readout errors may occur under specific clock frequency configurations. The triggering conditions are:
During random PSRAM accesses through DMA or CACHE, a “write followed by read” sequence occurs on the same address range.
The frequency ratio between the AXI bus (freq_axi) and the MSPI core (freq_core) exceeds the safe range. The exact safe range depends on whether AXI concatenation is enabled and the actual timing characteristics of the chip.
Under these conditions, the read operation may fail to obtain the new data written by the prior write operation and instead return old data that existed in PSRAM before the write. This error breaks data consistency and may impact normal chip functionality.
Root cause: The MSPI IP’s internal “address overlap detection” function has an asynchronous timing issue. When the clock-frequency ratio is near a critical boundary, this timing issue may cause the detection logic to fail, preventing it from correctly identifying overlapping addresses and eventually leading to incorrect data reads.
Workaround
To ensure system stability, software configurations must satisfy the following frequency constraints, based on whether AXI concatenation is enabled and the timing conditions:
Timing Condition |
AXI Concatenation Status |
Frequency Constraint |
|---|---|---|
Assuming poor timing |
Enabled |
3 × freq_core ≥ freq_axi |
Disabled |
freq_core ≥ freq_axi |
|
Assuming normal timing |
Enabled |
4 × freq_core ≥ freq_axi |
Disabled |
2 × freq_core ≥ freq_axi |
Solution
Fixed in chip revision v3.1.
[ROM-764] Secure Boot Verification Failure Caused by Incorrect Buffer Address in ROM
Description
In the ROM, the start address of the secure-boot stage buffer is incorrectly configured. It points to the L2 cache data memory (0x4FF0_0000), which is part of the L2 cache and not writable by the CPU.
Because of this misconfiguration, data stored in the secure-boot buffer may be lost, potentially causing hash calculation failures or signature verification failures during the secure-boot process.
Workaround
Do not enable secure boot.
Solution
Fixed in chip revision v3.1.
[Analog-765] Output Regulators Cannot Generate a Reliable Supply When Peripheral Power Domain Is Off
Description
The output regulators can not generate a reliable supply when the peripheral power domain is turned off.
Workaround
If you intend to use output regulators as the supply source for external PCB components, do not turn off the peripheral power domain in Light-sleep mode.
Solution
Fixed in chip revision v3.1.
[DMA-767] DMA Channel 0 Transaction ID Overlap Causes Permission Management Issue
Description
When performing a memory-to-memory transfer using AHB DMA channel 0, the transfer is assigned transaction ID “a”, which is identical to the transaction ID used by the RMT peripheral DMA.
Because of this ID overlap, memory-to-memory transfers on channel 0 share the same permission settings as the RMT peripheral and cannot be controlled independently. This may lead to unintended or unauthorized accesses in systems requiring isolated permission management.
Workaround
Avoid using memory-to-memory transfer channel 0. Perform all memory-to-memory transfers using channel 1 or channel 2.
Solution
Fixed in chip revision v3.1.
[ROM-770] Secure Download Mode Flash Power-On Failure
Description
To support both 1.8 V and 3.3 V flash, ESP32-P4 introduces a power-control mechanism in which, in Joint Download Boot Mode, the PMU does not power on the flash by default. In the normal download flow, software determines the flash operating voltage, updates eFuse PXA0_TIEH_SEL_0, and configures the related registers (this sequence is integrated into the esptool download command) to power on the flash before programming.
However, the ROM includes a Secure Download feature. When this feature is enabled via the eFuse ENABLE_SECURITY_DOWNLOAD, the ROM rejects register read/write commands and only allows flash programming operations. As a result, software has no opportunity to configure the flash power-control registers, preventing the flash from being powered on and causing the download process to fail.
Workaround
Do not enable Secure Download Mode.
Alternatively, provide a board-level mechanism to switch between internal and external flash power to ensure the flash is powered during download. Note that continuous external flash power may affect some IDF features, for example, the flash may not be able to power down in sleep mode. Therefore, it is recommended to switch back to internal flash power before entering sleep mode.
Solution
Fixed in chip revision v3.2.
[ROM-816] Device Hang When Flash Power-On Sequence Runs Twice with rom_download_xpd_on eFuse
Description
To address the issue that, in Secure Download Mode on ESP32-P4 chip revision v3.1 and earlier versions, esptool cannot power on the flash, ESP32-P4 chip revision v3.2 introduces a new eFuse rom_download_xpd_on. When this eFuse bit is programmed, the ROM automatically runs the flash power-on sequence during the download flow.
This power-on sequence must not run twice within the same power-on reset (POR) window; otherwise the ROM flow may fail to exit and the chip can hang.
Situations that can lead to the sequence running twice include:
The
rom_download_xpd_oneFuse is already programmed, but the host still sends a flash power-on sequence to the chip. A fixed esptool checks this eFuse bit when not in Secure Download Mode and only sends the automatic flash power-on sequence if the bit is not programmed, so this case is normally avoided.In Secure Download Mode,
rom_download_xpd_onis programmed through the USB UART interface, followed by USB UART force download to flash firmware. Because a reset from USB UART is typically not a full POR, entering download again after reset can be equivalent to executing the flash power-on path twice within the same power-on context, which triggers the hang risk described above.
Workaround
Program the
rom_download_xpd_onbit only when Secure Download Mode is actually required.If you use the USB UART interface for firmware download, perform a full POR before entering download after programming this eFuse bit.
Solution
No fix scheduled.