ESP32 Forum

I'm able to erase and flash a 4Mb ESP32 over UART from another mcu using the serial protocol found here https://github.com/espressif/esptool/wi ... l-Protocol. The problem is, anything written past 2Mb with command 0x03 isn't actually written. It responds that it's been written, but if you read the flash afterward, nothing past 0x200000 is actually changed. Also, if you use command 0x02 to erase the chip, it only succeeds up to a little above 0x200000. If you try to go much higher than that it'll reject it. Is there a way around this?

Do you use SPI_SET_PARAMS to set the flash size to 4MiB?

No, i wasn't really sure what values to send but I guess that would make sense, huh?

Hi Brad,

You may find the esptool source useful to study here (apart from the size field, I think all of the arguments to this command are passed as constants).

We also publish an MCU serial flasher library, that may be useful for reference and/or to directly use: https://github.com/espressif/esp-serial-flasher

Well if I configure spi, it does accept the command but no other commands work after that. I used the values in the serial-flasher source code. It appears they have the ID set to 0. I've tried that as well as the actual chip ID and get the same results. Nothing works after it takes that command but that command responds like nothing is wrong. I've tried attaching the spi before and after configuring but I get the same result

Hi brad,

Without seeing your code it's not really possible to help you debug. If you're able to share it, that's great.

Otherwise, you might try looking at the output from a command like "esptool.py --no-stub --trace -p PORT flash_id" - this will dump all the on-the-wire data sent and received by esptool. Then compare with what your code is doing.

If it is suitable for your use case, then please consider porting the usb-serial-flasher library to your MCU as an alternative - this project was created exactly for this use case and it's designed to be easily ported to new host targets.

Using serial-flasher wasn't really an option aa I don't like using libraries and it would have made integrating all the other things the code does much more difficult than if I just wrote the serial protocol from scratch. Plus I had already made it so far there was no way I was going to lose all that time trying to understand somebody else's code. It runs flawlessly now though thanks to configuring SPI. The configuration only needs to be done once because it saves the settings. That's why you can't enter any more commands after configuring. You don't really need to. I can now flash the whole chip but it appears the ROM loader just can't erase past 200000. But you can write the remainder as 0xFF so it's no big deal. I really appreciate all the help

Thanks brad for explaining your use case.

braddd wrote: ↑

Wed Feb 10, 2021 6:05 pm

I can now flash the whole chip but it appears the ROM loader just can't erase past 200000. But you can write the remainder as 0xFF so it's no big deal.

I was curious about this, but I can't reproduce it. I can generate 4MB of random data and flash it with esptool via the ROM loader, no problems.
However, I can reproduce your results if I don't pass the "-fs 4MB" argument to esptool, which causes it to skip sending the command to configure the SPI flash parameters (this is something we should fix in esptool). The ROM default flash chip size (if no parameters are sent) is 2MB, so any attempt to erase past 2MB fails in exactly the way you describe (the command 0x02 "flash begin" command returns an error result with error code 6 if it thinks the erase goes outside the bounds of the flash chip).

The configuration only needs to be done once because it saves the settings. That's why you can't enter any more commands after configuring. You don't really need to

That's not quite right, "settings" aren't saved anywhere persistent by the ROM loader itself (the "spi parameters" command updates a structure in RAM.) In the case of esptool, this command is sent when it prints "Configuring flash size..." which sets the paramters before it issues all of the flashing commands. There must be something not quite right about the format of this command (either the structure on the wire, or the contents of the fields) which causes the ROM loader to go into a bad state.

braddd wrote: ↑

Wed Feb 10, 2021 6:05 pm

But you can write the remainder as 0xFF so it's no big deal.

You can't erase NOR flash by writing 0xFF