I made a custom board using ESP32 WROOM 32U chip. I also have a bread board based test rig on which I've been flashing my test programs. The test rig runs fine with written code. However the custom board throws out the following output on serial monitor.
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
I'm using ESP32 download tools v3.8.5 for flashing both the custom board and the test rig. What am I doing wrong here?
N.B. I've already checked all the bin file and their addresses prerequisites and burned them on both on the test rig and custom board. Its only the custom board that's giving me this output
Make sure you are NOT using GPIO 6-11 for any purpose and leave these pins floating on your custom board. These pins are connected to the on-board flash and will result in the error you show if you are attempting to use them.
Additionally, make sure your 3v3 power supply is sufficient for the ESP32 since this can also result in failures of this nature.
@atanisoft Thank you for the quick reply. I've rechecked and yes GPIO6-11 have been left floating in my custom board and I've also made sure that the board is receiving the proper voltage values. I've rechecked this through a multimeter. Just to make sure that my CP2102 USB to TTL is working, I've programmed the test rig using this. To give you some context, the first error that I encountered was this
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
then after some tinkering and tremendous help from another thread viz.
https://github.com/espressif/arduino-esp32/issues/2230
I got the following output
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
I was able to resolve this by using the following thread:
https://github.com/espressif/arduino-esp32/issues/1638
Now the current status is
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
I've also made sure that the board is receiving the proper voltage values. I've rechecked this through a multimeter.
Voltage is only one half of the requirement for the ESP32, the other half is current. Make sure you are supplying at least 500mA of current at 3v3 to the esp32 (per datasheet page 35), though I'd highly recommend at least 750mA since the BLE and WiFi radios can each consume up to 240mA (page 37 in the datasheet).
I've checked the current flow too. Its 760mA ~ 775mA.
In that case, I'd suggest test your code with a DevKit-C or similar board and confirm it is not code related. If it works on a DevKit-C (or similar) board then I'd suggest a PCB review to ensure there are no pads shorting to GND or 3v3 that should not be (this includes GPIO 6-11 (pads 17-22 on ESP32-WROOM-32U page 3 and 4).
My test rig contains a DevKit-C V4, the code runs fine on it, with the intended output coming up on the serial monitor. I will check with the pads shorting issue though. Maybe there's some issue there.
Compile your app with lowest flash requirements (DIO/40MHz) while testing.
Yes, I understood that from one of your earlier threads, however, there has been no change in the output.
Only other thing I can think of would be holding gpio12 high at boot, but that really should prevent even the bootloader from starting. Do you have an SD attached there?
No there is no SD card attached. Can you explain why GPIO12 held on high at boot may or may not work? I've connected an LED through it in my custom board. Will that be a problem?
@chandanpalai there are a few bootstrap pins (listed in the datasheets linked above). Depending on the state of the pins as part of startup time they alter the behavior of the ESP32. GPIO 12 is one of the bootstrap pins and as @lbernstone is referencing if held HIGH it will switch the flash voltage IIRC.
Okay, in my circuit I've designated GPIO0 as my strapping pin.
Okay, in my circuit I've designated GPIO0 as my strapping pin.
That is only one of the five strapping pins on the ESP32. Refer to page 5 of the ESP32-WROOM-32U datasheet for the full set. MTDI = 12, MTDO = 15.
I did read up on the strapping pins before designing the custom board. However, I will take a thorough look again if I missed something with regards to the bootloader and strapping pins. Will update once I have something.
Another link: https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#early-flash-read-error
Okay, I will take a look at the particular link. Thank you
Have you ever solved this issue? (and do you remember how?). It's happening to me when I execute this line:
BLEDevice::init("");
The nodemcu keeps restarting itself:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
Hey folks, i found the problem with my code. I don't know if it will be useful to someone in the future. I had this:
class App {
public:
void setup() {
delay(3000); // power-up safety delay
}
void loop() { ... }
private:
BluetoothCommunicationHandler bluetooth{}; <-- initializing the service as a member variable
};
For some reason I don't know (I'm new to c++) that causes the reboot when I wanted to start BLE client.
Changed it to:
class App {
public:
void setup() {
delay(3000); // power-up safety delay
BluetoothCommunicationHandler bluetooth{}; <-- guess it should work in constructor too
}
void loop() { ... }
};
That's it. If anyone has a hint on why that was a problem, I'd like to understand. I initialize other services as member variables and that usually works fine. Is this something I should avoid in c++?
@libasoles If you are declaring that App class globally and you are doing something in the BluetoothCommunicationHandler constructor that requires BLE or other functionality to be usable the system will crash on startup due to the global constructor initialize phase runs prior to IDF/Arduino/etc starting up various peripherals/systems/etc.
You can work around this by declaring it as a pointer and initializing it from inside setup().
@libasoles I never found a workaround for the problem, nor could I rectify it. I've sent the hardware for redesign now. I will be posting progress with regards to my issue and how/if it gets resolved. Thank you for posting code based solution to the problem. I tried working with very simple codes could not resolve the problem.
Most helpful comment
@libasoles If you are declaring that App class globally and you are doing something in the
BluetoothCommunicationHandlerconstructor that requires BLE or other functionality to be usable the system will crash on startup due to the global constructor initialize phase runs prior to IDF/Arduino/etc starting up various peripherals/systems/etc.You can work around this by declaring it as a pointer and initializing it from inside setup().