Issues writing external flash chip with esptool. (ESPTOOL-962) #1034
Comments
github-actions
bot
changed the title
|
Update: Have also tried it with --no-compress with the same results: $ esptool --port COM10 --baud 9600 write_flash 0x0000 write.bin --no-compress --spi-connection 5,4,6,26,7 --flash_mode dout --flash_freq 12m A fatal error occurred: MD5 of file does not match data in flash! |
|
With a little more testing it looks like maybe flash_mode and flash_freq are not taking affect. The amount of time and the kbits/s with and without the options are too close. I would expect the run with --flash_mode dout --flash_freq 12m to take much more time, but both are taking around 4.3 seconds. Here are the results: Without flash_mode and flash_freq: A fatal error occurred: MD5 of file does not match data in flash!` With flash_mode and flash_freq: A fatal error occurred: MD5 of file does not match data in flash!` |
|
Hi @jackgassett interesting usecase you have here. We will take a look at it but I am not really sure if this will be possible. I took a quick look and noticed that you are right, Warning: Image file at 0x0 doesn't look like an image file, so not changing any flash settings.Here is the line that checks if the image is correct. There are some other checks that image file needs to pass to be able to change these parameters. You can try to install esptool in editable mode ( |
|
I commented out those checks and it says it is passing the flash parameters, but I'm not seeing a slowdown, it's still taking around 4 seconds at ~1200 kbits/s.. It also looks like if I write to address 0x2000 it skips the image check. Here is with the checks commented out: $ esptool/esptool.py --port COM10 --baud 9600 write_flash 0x0000 bitfile.bin --no-compress --spi-connection 10,11,9,26,8 --flash_mode dout --flash_freq 20m A fatal error occurred: MD5 of file does not match data in flash! Here is a comparison of what the bitfile looks like compared to what is read back. It is close, seems like it just needs to be slowed down... |
|
As you can see from the documentation, the parameters are taken into an account only when address is set to bootloader address (it is 0x0 in case of ESP32S3). You can also try enable |
|
Yes, that makes sense, it looks like I need to generate a valid header with the flash_mode and flash_freq in the image header. Writing to locations other than 0x00 and 0x1000 bypass the image header and so probably never set flash_mode and flash_freq. In the esptool.py code I see where it is updating the flash_mode and flash_freq in the header for the image. But I never see a command sent over the serial port to the bootloader to set flash_mode and flash_freq. With the SPI pins there is the spi_attach (if I remember the name right) function that sends a command and the pins to the bootloader. There is another function that sets flash parameters but it does not include flash_mode and flash_freq. So I'm guessing that flash_mode and flash_freq get put into the image header, sent over the serial line to the bootloader on the esp32s3 with the image, and then the bootloader unpacks the headers and applies those settings. I'm trying to find the code where those parameters are set in the bootloader, I've looked through the stub code but don't see it there. So I'm guessing it must be in the bootloader code that runs out of the ROM. Is that code published anywhere or is it closed? Or am I missing it in the stub somewhere? Any push in the right direction is appreciated. Thanks! |
|
You are right. When I proposed commenting out the checks it did apply the settings to the chip probably, because of the missing header (for which the checks are in esptool). The code that takes care of the header is not in stub, it is present in ROM code, which is not public and even I do not have access to it now unfortunately. But esptool is great source of these information. As I said, with esp32s3, you need to flash at 0x00 address. Then I would try to add the header. It is specified here. Flash mode and flash frequency can be either put into the header or rewritten using esptool. One thing I noticed unfortunately for you is that I think that the header is also written into the flash. |
Operating System
Windows 10
Esptool Version
esptool.py v4.8.1
Python Version
Python 3.12.6
Chip Description
ESP32S3
Device Description
Esp32S3 Supermini attached to a Tang Primer 20K dev board with the SPI Flash pins routed to external pins, via verilog, which are connected to gpio pins on esp32s3 board.
Hardware Configuration
Only ground and the 4 spi pins MOSI, MISO, SCLK, and CS are connected from the FPGA to the Esp32S3.
How is Esptool Run
VSCODE IDE
Full Esptool Command Line that Was Run
esptool --port COM10 --baud 9600 write_flash 0x0000 write.bin --spi-connection 5,4,6,26,7 --flash_mode dout --flash_freq 12m
Esptool Output
More Information
We are currently exploring the option of using an esp32s3 to replace the traditional FT2232 devices used with FPGAs to program a bitstream to the SPI Flash of the FPGA.
We noticed the option in esptool to change the SPI pins to external SPI pins. This seems like a very elegant way to be able to program both the ESP32 and the FPGA using the same tool.
We have routed the SPI Flash pins of the FPGA to GPIO pins which are connected to the GPIO pins of the ESP32. We are getting reliable reads and erases with this configuration, but unfortunately writes are not working. Every attempt to write gets the first couple of bytes correct but then there will be sections of incorrect data with sections of correct data...
We have tried to lower the frequency and use both dio and dout modes. I'm beginning to suspect that maybe the flash mode is not actually changing to dio or dout when gpio pins are specified with --spi-connection 5,4,6,26,7.
We have also tried multiple different pin locations with the same results.
Any ideas or help is greatly appreciated.
Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: