espemu: eFuses, flash encryption, esp32c5, and a working hard reset (CII-251)

[Harshal5]

Description

The qemu service can give a test an eFuse image, burn eFuses into it and boot an encrypted image. The esp-emu service could do none of that, and it had no dut.serial at all, so ESP-IDF tests that operate on device state had nothing to run against.

eFuses

--espemu-efuse-path gives the emulator an eFuse image, creating a blank QEMU-compatible one when the file does not exist.

execute_efuse_command() runs espefuse against a second emulator instance started in download mode with its UART on a socket. A second instance is needed because the first one is booted into the firmware, and pyserial's socket:// handler ignores modem control lines, so esptool cannot reset it into download mode.

Flash encryption

--encrypt and --keyfile encrypt the merged image the way the qemu service does, with one difference: the command is espsecure encrypt-flash-data --aes-xts. Every target the emulator supports encrypts flash with XTS-AES

esp32c5

esp-emu has accepted --chip esp32c5 for a while, but the service rejected the target before launching it, so every esp32c5 app was unrunnable under --embedded-services idf,espemu. Nothing else in the service is target specific — the flash image comes from the app's own flash arguments — so the target list was the only gap.

dut.serial.hard_reset()

ESP-IDF tests reach the chip through two channels: the console stream (dut.expect) and a control channel (dut.serial) that resets it, erases flash and burns eFuses. esp-emu now serves a control channel, so hard_reset() sends reset over it. The emulator process keeps running, so the dut's output stream, its expect history and its log all continue across the reset; relaunching the process would break all three.

The service checks esp-emu --help for --control-tcp before passing the flag, because an older binary exits on an unknown one. The operations that still need download mode raise NotImplementedError naming the operation that was wanted.

Validation

Run against ESP-IDF master with --embedded-services idf,espemu:

• An encrypted image boots on an emulated target with the eFuses burned.
• esp32c5 collects and passes the same esp_system and esp_hw_support cases as the other targets.
• esp_driver_uart's test_uart_single_dev, which used to fail at setup on dut.serial, now resets the chip six times and runs through to its test content.

Dependency

hard_reset() needs an esp-emu build with --control-tcp, which no release carries yet. Without it the service behaves as it does today and dut.serial.hard_reset() raises with an explanation, so this can merge ahead of the emulator change.

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[github-actions]

Title	Coverage	Tests	Skipped	Failures	Errors	Time
Qemu		7	0 💤	0 ❌	0 🔥	24.763s ⏱️
3.14 X64		123	20 💤	0 ❌	0 🔥	15m 27s ⏱️
Espemu		4	0 💤	0 ❌	0 🔥	4.838s ⏱️