Rom loader only works up to 2Mb?

[braddd]

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?

[ESP_Sprite]

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

[braddd]

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

[ESP_Angus]

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

[braddd]

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

[ESP_Angus]

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.

[braddd]

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

[ESP_Angus]

Thanks brad for explaining your use case.

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.

Code: Select all

$ dd if=/dev/urandom of=random.bin bs=1MB count=4
4+0 records in
4+0 records out
4000000 bytes (4.0 MB, 3.8 MiB) copied, 0.0876904 s, 45.6 MB/s
$ esptool.py --no-stub -p /dev/ttyUSB1 -b 921600 write_flash -fs 4MB 0x0 random.bin 
esptool.py v3.1-dev
Serial port /dev/ttyUSB1
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, VRef calibration in efuse, BLK3 partially reserved, Coding Scheme 3/4
Crystal is 40MHz
MAC: 30:ae:a4:5b:5a:28
Changing baud rate to 921600
Changed.
Enabling default SPI flash mode...
Configuring flash size...
Erasing flash...
Took 9.39s to erase flash block
Wrote 4000768 bytes at 0x00000000 in 125.0 seconds (256.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

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.

[WiFive]

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

You can't erase NOR flash by writing 0xFF