Repository navigation
Test flashing speed improvements - #1060
Conversation
98b012e to
83cf68e
Compare
|
Thanks for refreshing the stubs. The C6 A C6-only delta against this PR's head ( Why it matters to me: with the v1.3.0 C6 stub, espflash flashes an ESP32-C6 through USB-over-IP passthrough (VirtualHere, SEH UTN) together with the SYNC fix in #1084. With the stub currently on |
|
It's worth waiting the new release? @Dzarda7 added the raise of the CPU freq in the stub-lib espressif/esp-stub-lib#90 (comment) |
463b8ea to
dee9f2c
Compare
|
|
|
Something like |
|
/hil full |
|
Triggered full HIL for PR #1060. Revision: Chips: Run: https://github.com/esp-rs/espflash/actions/runs/37914440184 Status: ❌ HIL run failed (failure). |
67b3dbc to
633c488
Compare
|
/hil full |
|
Triggered full HIL for PR #1060. Revision: Chips: Run: https://github.com/esp-rs/espflash/actions/runs/37919481307 Status: ❌ HIL run failed on re-run (attempt 2) (failure). |
|
/hil full |
|
Triggered full HIL for PR #1060. Revision: Chips: Run: https://github.com/esp-rs/espflash/actions/runs/37921912191 Status: ❌ HIL run failed (failure). |
|
Hi guys, I think we can fix the stub not being able to upload with higher baudrate if you need it, just let me know/open issue. I already considered such feature for our tools too. |
|
Hi @Dzarda7 it matters to me because I use a custom tool based on this Rust library to flash devices in our factory, and reducing the flashing time would be very useful. If you need any help with testing or coding, I'd be happy to contribute! |
|
HIL failures are now unrelated.
That would be nice, @Massimiliano-solutiontech do you mind opening the issue? |
c056bd2 to
9c7f901
Compare
|
/hil full |
|
Triggered full HIL for PR #1060. Revision: Chips: Run: https://github.com/esp-rs/espflash/actions/runs/39747387928 Status: ❌ HIL run failed on re-run (attempt 2) (failure). |
esp-flasher-stub boosts the clock on UART for ESP32, ESP32-S2, ESP32-S3, ESP32-P4, ESP32-S31, ESP32-H4 and ESP32-C6, then reprograms the UART divider to the baud recorded at ROM init. The ROM's CHANGE_BAUDRATE does not update that value, so changing baud before uploading the stub leaves the host at the requested baud while the stub answers at 115,200. Change baud after the stub is running on all of these chips, not only ESP32, ESP32-S2 and ESP32-C6.
The GET_SECURITY_INFO payload ends with the status bytes: 4 from the ROM loader and 2 from the stub. Only the ROM status was stripped, so the ESP32-S2's 12-byte security info from esp-flasher-stub arrived as 14 bytes and was rejected as a truncated 20-byte response.
v1.4.1 updates esp-stub-lib for ESP32-C61 ECO5, ESP32-P4 ECO8 and the ESP32-C5 160 MHz PLL. Only the ESP32-C5, ESP32-C61 and ESP32-P4 stubs change.
9c7f901 to
a033fed
Compare
Raising the ROM loader's baud before uploading the stub corrupts long MEM_DATA packets on USB-to-UART bridges. On an ESP32-C3 behind a CP2102N at 921,600 baud, the 5,880-byte stub text block fails with an invalid CRC; blocks up to 0x800 bytes pass and 0x1000 bytes fail. Upload the stub at the initial baud and change baud once the stub is running, as esptool does.
Failed commands built the error from the status byte, which is always 1 on failure, so every error showed as "Other (0x1)". Use the error byte, as sync() already does.
|
/hil full |
|
Triggered full HIL for PR #1060. Revision: Chips: Run: https://github.com/esp-rs/espflash/actions/runs/39755464341 Status: ❌ HIL run failed on re-run (attempt 2) (failure). |
The ESP32-P4 ran a reduced suite because the old esptool flasher stub read erased flash back as 0x00 in some ranges and reported wrong MD5 checksums (esp-rs#1037). esp-rs#1060 replaced it with esp-flasher-stub v1.4.1, so run the same suite as the other chips and drop the tolerance for those erased reads.
* test: run the full HIL suite on ESP32-P4 The ESP32-P4 ran a reduced suite because the old esptool flasher stub read erased flash back as 0x00 in some ranges and reported wrong MD5 checksums (esp-rs#1037). esp-rs#1060 replaced it with esp-flasher-stub v1.4.1, so run the same suite as the other chips and drop the tolerance for those erased reads. * test: flash the ESP32-P4 with a 4 MB image size With the detected 16 MB in the image, the ESP32-P4 test app drops off USB right after `cpu_start: Multicore app`, so `flash --monitor` fails with a broken pipe. The same app boots with espflash's 4 MB default, which the save-image and write-bin steps already use (esp-rs#1101). Pass it to every `flash --monitor` step of the flash test, including the QIO one.
esp-flasher-stubv1.4.1GET_SECURITY_INFOpayload, so the ESP32-S2 security info is no longer rejected as truncatedOther (0x1)FLASH_ENDandFLASH_DEFL_ENDpayloads required by current stubsThe stub is still uploaded at 115,200 baud, and the requested baud is applied once the stub is running, as esptool does. Raising the ROM loader's baud before the upload corrupts long
MEM_DATApackets on USB-to-UART bridges: on an ESP32-C3 behind a CP2102N at 921,600 baud, the 5,880-byte stub text block fails with an invalid CRC (blocks up to 0x800 bytes pass, 0x1000 bytes fail).Benchmarks
Benchmarked on an ESP32-C6 connected through a CP2102N USB-to-UART adapter, flashing the approximately 1.16 MiB
espflash/tests/data/esp_idf_firmware_c6.elfimage with--no-skip. Times are median wall-clock flash-command durations, alternating runs betweenmainand this PR; lower is better.mainAt 115,200 baud the newer stub is larger, so most of the improvement is visible at higher baud rates. 921,600 baud is recommended when supported by the adapter and target.
ESP32-S3 and ESP32-C61 (USB-Serial-JTAG)
Benchmarked on an ESP32-S3-DevKitC-1 (v0.2, 8 MB flash) and an ESP32-C61-DevKitC-1 (v1.0, 8 MB flash), both connected through the chip's native USB-Serial-JTAG port, so the requested baud rate (921,600) does not limit throughput. Before every timed run, an untimed step either filled the target region with zeros or erased it. This ensured each run performed a real erase and program instead of rewriting identical data. Times are median wall-clock durations over 5 runs, alternating between
mainand this PR; lower is better.flash --no-skipof the bundledespflash/tests/data/esp32s3(72 KiB) andesp32c61(128 KiB) images, including bootloader and partition tablewrite-bin 0x10000of the same ESP-IDF image used above (saved withsave-image)mainThe ESP32-S3 gains the most. On the ESP32-C61, writes to dirty flash are on par with
main, but writes to pre-erased flash are 14% slower. Pre-erased writes with this PR are also slower than dirty writes, which points at the C61 stub's blank-sector handling. Run-to-run spread was below 0.3 s in every scenario.The ESP32-C61 rows were re-measured with the v1.4.1 stub, which replaced the C61 stub, against
mainat d6f2551. These runs used release builds with--skip-update-check, so compare their change relative tomainrather than their absolute times with the ESP32-S3 rows. Run-to-run spread was below 0.06 s. The v1.4.0 stub gave the same picture (3.8% and 2.6% slower for the app, 0.5% faster on dirty flash, 14.0% slower on pre-erased flash).