Erasing flash failed (ESF-108)

[caiubistaffoker]

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...

1. 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.

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.

3. 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

[caiubistaffoker]

Its possible, someone could help me please?

[DNedic]

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.

[caiubistaffoker]

Hello @DNedic!
Thank you for replying me.
I could try to put an oscilloscope on the transmission line, but I don't have an analyzer here.
I'm not able to understand this missing SPI_ATTACH commands.
Shouldn't this ESP_SERIAL_FLASHER library be a write through serial communication through UART?
So why does the code initiate SPI communication?
Just to summarize my project, I need to make the NXP record the ESP32 through UART (RX0 and TX0). At first, I am placing the binary within the NXP code. Then I will have to adapt my code to search for the binary on an SD Card. And then NXP records the ESP32 with each FW update. That's why I came after this ESP_SERIAL_FLASHER library.

[DNedic]

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.

[caiubistaffoker]

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.

In this case, are you saying that the SPI is an internal update to the ESP32-WROOM-32E module?
I mean, the NXP doesn't necessarily need to be connected via SPI to the ESP32.

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.

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.

binaries.zip

[DNedic]

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.

[caiubistaffoker]

@DNedic,

1. Did you get any results with the binary I sent you?

2. I made a comparison of the data sent by the Arduino IDE (through esptool) and it seems that the Arduino platform sends different data for each command. Is this true?
   Below is the log of the data that the Arduino sent to the ESP32.

log_docklight_rxPC_txESP_hex.txt

[DNedic]

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:

1. It uses the GET_SECURITY_INFO command whereas we do not yet
2. 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
3. The flasher stub has it's own commands which the boot rom does not support
4. esptool handles SPI attach and parameter setting differently
5. Probably more things I didn't think of

[caiubistaffoker]

Hello @DNedic!

Can you please post the output of esptool flash_id command with your module attached?

Sorry, but I didn't understand what you meant by the esptool command output. Would it be possible for you to explain better? Or do you have an example?

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

I'm using the latest version of the serial flasher.

Regarding these differences between esptool and esp serial flasher commands, I thought I could find some relationship in the commands and find out where my esp serial flasher was failing.

[DNedic]

Sorry, but I didn't understand what you meant by the esptool command output. Would it be possible for you to explain better? Or do you have an example?

Sorry if I didn't explain it very well, esptool is our python tool for flashing Espressif SoC's from a PC, it's also integrated in our ESP-IDF SDK but you can get it standalone as well.

Connect the module you're trying to flash to the PC, install esptool and run the flash_id command. That will give us more information about the SPI flash chip integrated into the module.

Also, please try to also provide missing log parts I already mentioned, or a logic analyzer trace.

[caiubistaffoker]

I'm sorry, but before I really didn't understand it very well. Now I did the Flash_ID process that you mentioned.
Please check if this was the data you were expecting.

[DNedic]

Thanks for this info, it is possible this is related to #92, due to flash size being 16MB, however the 'Flash size detection failed' error is concerning.

Can you try flashing the same binary you wanted to flash with esp-serial-flasher using esptool, but also pass the --no-stub argument.

[caiubistaffoker]

Hello, @DNedic.

Can you try flashing the same binary you wanted to flash with esp-serial-flasher using esptool, but also pass the --no-stub argument.
I managed to record the ESP32 using ESPTOOL. Following the command below:

esptool -p COM11 -b 115200 --before default_reset --after hard_reset --no-stub --chip esp32 write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 bootloader.bin 0x8000 partition-table.bin 0x10000 hello_world.bin

I even included the trace to check the messages, but I couldn't capture it via CMD because it was too much information. The last message says that the recording was successful and below is the photo of this message.

So, with this new information, do you think is possible to discover where is the problem with my esp-serial-flasher?

[DNedic]

Try piping the output with tracing to a text file using > and upload it if you can. That might help us even further.

[caiubistaffoker]

Try piping the output with tracing to a text file using > and upload it if you can. That might help us even further.

Below is all the trace from ESPTOOL.
Is this trace possible to compare with trace from ESP SERIAL FLASHER?

log_esptool_rxESP_hex.txt

A new question has now arisen for me: Does NXP's MCU not necessarily need to use Zephyr OS? Because I'm not using that tool.

[caiubistaffoker]

Hello @DNedic,
Would it be possible to analyze the last trace that I sent here earlier?

Thank you very much.

[DNedic]

Hello @caiubistaffoker , I have taken a look at the logs again, and while they are only logging one or other side of the transaction, it strikes me as very weird that the last response from the ESP when you're flashig it with your port is C0 01 12 02 00 00 00 00 00 00 00 C0, which is FLASH_DEFL_END.

Can you provide a log for flashing with your port that covers both TX and RX sides? Additionally maybe you can provide the high-level code you are using for flashing.

[caiubistaffoker]

Hello @DNedic!

This last answer that you checked, I believe it refers to the recording trace that the Arduino performs on the ESP32.
And I remember that this trace is not valid to compare with the application of ESP_SERIAL_FLASHER because the Arduino uses the flash stub and other divergent procedures, correct?

I generated another trace from ESPTOOL, but I can't see how this can help me correctly apply the ESP_SERIAL_FLASHER library.

Sorry, but I don't understand what high-level code you would like me to provide you.

[DNedic]

This last answer that you checked, I believe it refers to the recording trace that the Arduino performs on the ESP32. And I remember that this trace is not valid to compare with the application of ESP_SERIAL_FLASHER because the Arduino uses the flash stub and other divergent procedures, correct?

In that case please provide the esp-serial-flasher log with both RX and TX. In the initial log, the responses are missing just before DEBUG info is printed.

Sorry, but I don't understand what high-level code you would like me to provide you.

I am reffering to the code that is actually using the esp-serial-flasher API.

[caiubistaffoker]

@DNedic
Please, would it be possible for you to provide a personal/professional email so that I can share this part of the code with you?

[DNedic]

Of course, you can always contact me at [email protected].

[caiubistaffoker]

Thank you very much, @DNedic . I sent you an email, please check your email box.