Relatively slow flashing of 64MB flash (ESP32-P4 rev 1.3) (ESPTOOL-1339)

[Daniel-Abdi]

Operating System

Ubuntu 22.04

Esptool Version

v5.3.0

Python Version

Python 3.10 .12

Chip Description

ESP32-P4 V1.3

Device Description

Hello,

I have a 64MB flash chip (W25Q512NWEIM) attached to a custom ESP32-P4-based board. I'm flashing via USB-JTAG, using esptool v5.3.0 (with the new flasher stub). My ~10MB firmware file takes around 75 seconds to fully flash. Is this a normal and expected flashing time for this size of chip and firmware binary? How can I speed this up, as it's quite slow when flashing at the factory. For reference, the traces from the P4 to the flash chip are approximately 13mm long. Any ideas would be greatly appreciated.

Hardware Configuration

USB JTAG to P4, and QSPI to the flash chip. There are UARTs and I2Cs connected on the board but nothing that would affect the flashing speed in my opinion.

How is Esptool Run

Terminal (Linux)

Full Esptool Command Line that Was Run

esptool --chip esp32p4 -p /dev/ttyACM0 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode qio --flash_freq 80m --flash_size detect 0x2000 bootloader/bootloader.bin 0xa0000 app.bin 0xe000 partition_table/partition-table.bin 0x9e000 ota_data_initial.bin

Esptool Output

More Information

No response

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[github-actions]

Hi @Daniel-Abdi! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

The knowledge sources don't contain specific benchmarks for flashing a 64MB chip or detailed USB-JTAG throughput figures, so I can't confirm whether 75 seconds for ~10MB is "normal" for your exact setup. However, I can offer some observations and suggestions based on the available documentation.

Observations on Your Current Command

Your command already uses good settings:

• --flash_mode qio — the fastest SPI flash mode [SPI Flash Modes]
• --flash_freq 80m — the maximum supported flash clock frequency [Flash Modes]

So from a flash mode/frequency perspective, you're already at the optimal settings.

Things to Check and Try

1. Verify QIO Mode Is Actually Active

QIO mode requires the WP and HOLD pins of the flash chip to be correctly wired to the ESP32-P4's GPIOs. If they are not connected properly, the chip may silently fall back to a slower mode. [SPI Flash Modes FAQ]

2. Use Differential (Fast) Reflashing During Development

If you're repeatedly flashing similar firmware (e.g., during factory bring-up iterations), the --diff-with option can dramatically reduce flashing time by only rewriting changed 4KB sectors:

esptool --chip esp32p4 -p /dev/ttyACM0 -b 460800 write-flash 0xa0000 new_app.bin --diff-with old_app.bin

[Fast Reflashing]

3. Skip Unchanged Content

If the binary hasn't changed, use --skip-flashed to skip flashing entirely if the content already matches:

esptool ... write-flash --skip-flashed ...

[write-flash]

4. Note on Baud Rate via USB-JTAG

You're using -b 460800, but when connecting via USB-JTAG (/dev/ttyACM0), the baud rate argument may not have the same effect as with a UART connection, since USB-JTAG uses a fixed USB transfer rate internally. The -b flag primarily affects UART-based connections.

5. Flash Chip Erase Times

For a 64MB (512Mbit) flash chip, the datasheet-level chip erase time alone can be significant. The ESP32-P4 datasheet lists typical chip erase times of up to 300 seconds for a 256Mb chip, though sector-by-sector erasing (as esptool does) is faster. [ESP32-P4 Datasheet] The W25Q512NWEIM is a large chip, and erasing/writing ~10MB of data across it will inherently take some time.

Summary

Your settings are already optimal for flash mode and frequency. The most impactful improvement for factory flashing would be to use differential flashing (--diff-with) if firmware updates are incremental, or --skip-flashed if the same binary is being written repeatedly. If the full erase+write time is the bottleneck, that is largely a function of the flash chip's hardware characteristics.

[radimkarnis]

Hello @Daniel-Abdi ,
apart from increasing the baud rate to 921600 I don't have more suggestions on how to improve the flashing speed.

We are currently experimenting with new improvements for production lines, e.g. skipping erasing flash blocks if the user confirms the flash chip is already empty (chips coming pre-erased from the factory), but that is not ready yet.

[Daniel-Abdi]

Maybe this is an issue for the flasher stub, but mine (and many other) flash chips offer larger sector erase commands, and page program functionality allowing a write of 256 bytes at once. Maybe there are some driver-level changes (or allowing for custom drivers to be used with esptool or the flasher stub?) that can be made? Any ideas or some insight into how the flasher stub actually works and handles this type of thing would be appreciated.

Thank you

[Dzarda7]

Hello @Daniel-Abdi, sorry for the late response. Improve flashing speed is our priority for now, we are investigating what contributes the most of the time now and gradually implementing things. we just got 3 new PRs into our esp-flasher-stub, these are basically things we planned to implement in the near future. We plan other things like CPU frequency increase (when there is still a margin) and I plan to look at these special commands for each flash too, issue is that these needs to be implemented per flash chip which is quite a maintenance burden and might possibly raise a lot of questions why here it is that fast and there that slow. Anyway we plan to look into it definitely, if you have some ideas, feel free to open an issue or PR. BTW I believe that we use 256 byte flash and sector erase when possible. If parallel flashing is something that would help you, you can also look into esp-serial-flasher which allows multiple instances at the same time and can be run basically on anything.

[Daniel-Abdi]

Hello,

Thank you for the reply! Regarding the special commands for each flash, maybe this could be implemented kind of as a plugin type of thing where flash-specific commands can be supplied by the user in some way? Just an idea I guess. Also, as an aside, are you able to explain why (while flashing), the first ~20-30% is very slow, but then speeds up significantly as time goes on?

[Dzarda7]

Thanks for the suggestion, maybe if it is simple as changing command, maybe we can consider maintain some struct of commands with supported flash IDs. But I checked your flash time and AFAIK we already use block erase when possible and page program. We do not use quad transfer but it does not have big impact on flashing speed, I measured recently. Erasing and writing takes time.

Regarding to slow beginning, I actually believe it is python interpreter, I measured the similar slowdown at the beginning. Depends on the size but that was conclusion I did (did not investigate deeply), C implementation did not have this behavior.