esp-serial-flasher: Erasing flash failed (ESF-108)

Is your feature request related to a problem?

I’m trying to record the ESP32 through Serial UART mode. I carried out a port to the NXP LPC54628 and the reading/writing of the serial is occurring correctly, however, when the NXP detects the size of the flash in order to load the Flash, an error problem occurs. I understand that this error occurs because the code tries to access the ESP32’s Flash via SPI, when in fact it should be via serial UART.

Below is my entire log for you to check the path that is taking place.

` TEST GRAV ESP32 BY NXP

Entered recording mode…

— WRITE — 0xc0 0x 0 0x 8 0x24 0x 0 0x 0 0x 0 0x 0 0x 0 0x 7 0x 7 0x12 0x20 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xc0 0xc0 0x 0 0x 8 0x24 0x 0 0x 0 0x 0 0x 0 0x 0 0x 7 0x 7 0x12 0x20 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xc0 0xc0 0x 0 0x 8 0x24 0x 0 0x 0 0x 0 0x 0 0x 0 0x 7 0x 7 0x12 0x20 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xc0 0xc0 0x 0 0x 8 0x24 0x 0 0x 0 0x 0 0x 0 0x 0 0x 7 0x 7 0x12 0x20 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xc0 — READ — 0xc0 0x 1 0x 8 0x 4 0x 0 0x 7 0x12 0x20 0x55 0x 0 0x 0 0x 7 0x12 0x20 0x55 0x 0 0x 0 0x 0 0x 0 0xc0 Connection initialized…

— WRITE — 0xc0 0x 0 0x a 0x 4 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x10 0x 0 0x40 0xc0 — READ — 0xc0 0x 1 0x a 0x 4 0x 0 0x83 0x1d 0xf0 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 Chip detected…

Target: 1

READ SPI MODE…

— WRITE — 0xc0 0x 0 0x a 0x 4 0x 0 0x 0 0x 0 0x 0 0x 0 0x14 0xa0 0xf5 0x3f 0xc0 — READ — 0xc0 0x 1 0x a 0x 4 0x 0 0x 0 0x 0 0x10 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 — WRITE — 0xc0 0x 0 0x a 0x 4 0x 0 0x 0 0x 0 0x 0 0x 0 0x c 0xa0 0xf5 0x3f 0xc0 — READ — 0xc0 0x 1 0x a 0x 4 0x 0 0x 0 0xa2 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 — WRITE — 0xc0 0x 0 0x d 0x 8 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 — READ — 0xc0 0x 1 0x d 0x 4 0x 0 0x 0 0xa2 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 Connected to target…

— WRITE — 0xc0 0x 0 0x f 0x 8 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x84 0x 3 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 — READ — 0xc0 0x 1 0x f 0x 4 0x 0 0x 0 0xa2 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0xc0 CHANGE BAUD RATE Transmission rate changed changed

GET BINARIES…

GO TO FLASH BOOTLOADER BINARY… Erasing flash (this may take a while)…

— WRITE — 0xc0 0x 0 0x a 0x 4 0x 0 0x 0 0x 0 0x 0 0x 0 0x1c 0x20 0xf4 0x3f 0xc0 DEBUG: Flash size detection failed, falling back to default 0xc0 0x 0 0x 2 0x10 0x 0 0x 0 0x 0 0x 0 0x 0 0x30 0x61 0x 0 0x 0 0x19 0x 0 0x 0 0x 0 0x 0 0x 4 0x 0 0x 0 0x 0 0x10 0x 0 0x 0 0xc0 Erasing flash failed with error 2.

GO TO FLASH PARTITION TABLE BINARY… Erasing flash (this may take a while)… 0xc0 0x 0 0x a 0x 4 0x 0 0x 0 0x 0 0x 0 0x 0 0x1c 0x20 0xf4 0x3f 0xc0 DEBUG: Flash size detection failed, falling back to default 0xc0 0x 0 0x 2 0x10 0x 0 0x 0 0x 0 0x 0 0x 0 0x 0 0x c 0x 0 0x 0 0x 3 0x 0 0x 0 0x 0 0x 0 0x 4 0x 0 0x 0 0x 0 0x80 0x 0 0x 0 0xc0 Erasing flash failed with error 2.
GO TO FLASH HELLO WORLD BINARY… Erasing flash (this may take a while)… 0xc0 0x 0 0x a 0x 4 0x 0 0x 0 0x 0 0x 0 0x 0 0x1c 0x20 0xf4 0x3f 0xc0 DEBUG: Flash size detection failed, falling back to default 0xc0 0x 0 0x 2 0x10 0x 0 0x 0 0x 0 0x 0 0x 0 0xf0 0x2b 0x 2 0x 0 0x8b 0x 0 0x 0 0x 0 0x 0 0x 4 0x 0 0x 0 0x 0 0x 0 0x 1 0x 0 0xc0 Erasing flash failed with error 2. `

Describe the solution you’d like

I believe that the recording of the ESP32’s FLASH should all be carried out by the UART, that’s why there is that define SERIAL_FLASHER_INTERFACE_UART or would it be for another purpose? Would it be possible to explain to me in more detail how this ESP32 UART serial recording works?

Describe alternatives you’ve considered

No response

Additional context

No response

About this issue

Original URL
State: closed
Created 6 months ago
Comments: 22

Most upvoted comments

Hello @caiubistaffoker , I could not reproduce your issue. Can you please post the output of esptool flash_id command with your module attached?

Additionally, please provide the info on the version of esp-serial-flasher you are using.

Regarding comparing the output of flashing with esptool flashing procedure, the two are not comparable for several reasons, namely:

It uses the GET_SECURITY_INFO command whereas we do not yet
It uploads the flasher stub to RAM, after which flashing is usually done with the binary being compressed while we do not support compressed binaries
The flasher stub has it’s own commands which the boot rom does not support
esptool handles SPI attach and parameter setting differently
Probably more things I didn’t think of

DNedic on Jan 6, 2024

In this case, are you saying that the SPI is an internal update to the ESP32-WROOM-32E module?

Yes, the module contains the ESP chip and the flash chip containing the second stage bootloader, partition table and the app (or perhaps more apps depending on the config). When we ‘flash’ the ESP chip we actually flash the flash chip connected to the ESP chip over SPI.

Here is the binary I am trying to burn to the esp32. This binary is the same one that you made available some time ago here on github for the Hello-world example.

Thank you, I will try reproducing the issue.

DNedic on Jan 4, 2024

The SPI communication is initiated between the target running the Boot ROM and the flash chip of the target, as we need to flash the target flash chip.

If you want to upload to RAM of the ESP chip instead you can use the mem functions instead and look at the esp32_load_ram_example folder in the examples section.

I could not see the response for the SPI_ATTACH commands in the log, only the outgoing command is being logged. Judging by the Error 2 (timeout) error, it is likely that because of the wrongly detected chip size the library is using the wrong timeout.

Can you upload your binary that you’re trying to flash, or at least share the size of it? Also, try using esptool to obtain flash information and post it here, so maybe I can try reproducing the issue.

DNedic on Jan 4, 2024

Hello @caiubistaffoker , there appear to be some missing command responses in your logs, for instance responses to SPI_ATTACH, can you get a logic analyzer trace or any other way to get those responses?

Also, we recently had a version bump fixing flash chip detection for some models which were missing support, are you using the latest release?

Regarding SERIAL_FLASHER_INTERFACE_UART and SERIAL_FLASHER_INTERFACE_SPI, these dictate the interface the host uses to talk to the target (device being flashed), and have nothing to do with the actual target to it’s flash chip communication. SPI commands for flashing are intended to tell the target the parameters and ask it to connect to it’s own SPI chip to be flashed.

DNedic on Jan 4, 2024