Hi Guys,
I got a really annoying issue with my ESP32 wroom32D devboard. I really like it, but almost all the time i can't really write to the flash chip (reading always works). I flashed circuitpython, and connected some hardware (a matrix, an oled screen, a battery and 2 rotary encoders) and now i can't save to the board. i thought it might be a circuitpython issue, but it isn't. I tried to read some data from the chip using esptool and even esptool told me that it is an issue of my device.
This is the command i was using:
esptool --port COM8 --chip esp32 chip_id
And this is the error i got:
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Warning: ESP32 has no Chip ID. Reading MAC instead
i connected wires to all ground pins, to the 3v pin, to the 5v pin
These are the IO pins I'm using
2, 4, 12, 14, 15, 18, 21, 22, 23, 32, 33
I really would like some help. disconnecting every single IO pin is not really an option for me because i change the code several times and also need to see if the communication with the hardware actually works.
Failed to communicate with the flash chip
Re: Failed to communicate with the flash chip
Check 2 and 12. Both should be low. You can try removing everything connected to these pins externally to allow the internal pulldowns to do this automatically.
Re: Failed to communicate with the flash chip
Thank you!
Removing the connection to pin 12 actually fixed it
I still have something connected on 2. Do i need to disconnect it, or what would happen if i don't?
Removing the connection to pin 12 actually fixed it
I still have something connected on 2. Do i need to disconnect it, or what would happen if i don't?
Re: Failed to communicate with the flash chip
12 determines the voltage of the VDD_SPI domain (ie. the voltage supplied to the flash chip, 1V8 or 3V3). You can set this voltage in efuses instead, and the pin level will then be ignored so you can connect whatever you like.
2 (along with 0) determines the boot mode (ie. run the application normally, or get ready to receive new firmware over UART). For a normal boot (pin 0 high), 2 doesn't matter, but with 0 low 2 must also be low else the boot mode is undefined and I've seen very similar behaviour to the error you quoted.
There's no reason you can't use strapping pins as long as you're careful to ensure they will always be at the correct level upon startup. Avoid connections that may be driven externally (eg. MOSI is fine, but MISO is risky) and use an external pullup/down if necessary.
2 (along with 0) determines the boot mode (ie. run the application normally, or get ready to receive new firmware over UART). For a normal boot (pin 0 high), 2 doesn't matter, but with 0 low 2 must also be low else the boot mode is undefined and I've seen very similar behaviour to the error you quoted.
There's no reason you can't use strapping pins as long as you're careful to ensure they will always be at the correct level upon startup. Avoid connections that may be driven externally (eg. MOSI is fine, but MISO is risky) and use an external pullup/down if necessary.
Who is online
Users browsing this forum: jesper and 153 guests