Hello, i recently started working with the Nano-esp32 boards, all went well until i got a purple solid rgb and i could not upload any sketch anymore. I remember i must have pushed the reset button a couple of times during some power management issues i was working on. Now i did read related threads to this topic, and lately applied the exact procedure to upload the firmware to the Nano-esp32 through the Arduino ide with no avail.
Problem description:
Hardware: i am using am Macbook Pro from 2021, macOs 15.3.2, latest Arduino ide as of today, an Arduino Nano-esp32
When i request the board info in the arduino ide i get this: BN: Adafruit QT Py ESP32-C3 in addation to the VID,PID and SN numbers. Now it seems i have somehow uploaded a wrong firmware to my nano-esp32. I should mention that my other nano-esp32 boards work perfectly well and there is no issue with the boards nor the communication with my macbook pro.
Any help is appreciated, i have no more idea what to do at this point.
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x4bc
load:0x403c9700,len:0xbd8
load:0x403cc700,len:0x2a0c
entry 0x403c98d0
E (84) cpu_start: External RAM could not be added to heap!
abort() was called at PC 0x42009b98 on core 0
Backtrace: 0x403771da:0x3fceb230 0x40379e99:0x3fceb250 0x4037f9b5:0x3fceb270 0x42009b98:0x3fceb2f0 0x40376b4b:0x3fceb320 0x403cd86b:0x3fceb350 0x403cdb2a:0x3fceb380 0x403c9925:0x3fceb4b0 0x40045c01:0x3fceb570 0x40043ab6:0x3fceb6f0 0x40034c45:0x3fceb710
I jut stumbled across two threads apparently discussing the same problem (nano-esp32 falsely recognized as Adafruit QT Py ESP-C3) but i can not find the solution to the problem:
@karimsteel this may not be the same problem your having but it's a good place to start. This is the way I would reset a Nano ESP32 , step by step instructions.
Nano ESP32 Bricked? - #3 by sumguy.._gaODk0MTEwNTY0LjE3NDUzNDM2OTg._ga_NEXN8H46L5MTc0NTM0MzY5Ny4xLjAuMTc0NTM0MzY5Ny4wLjAuMTgzNjQ3NDk4Mg..
H sumguy, yes i did this procedure already, but i did it again just to be sure, all with no avail. In the terminal i can see that it uploaded successfully but after the process, rgb is still solid purple and the board is falsely recognized as an Adafruit QT Py ESP32-C3 ?
The purple LED and the board being mis-identified can be due to either firmware download mode or a wrong firmware. Performing the steps in the guide you linked will ensure firmware download mode is entered and definitely recover a Nano ESP32 to an usable state.
Please double and triple check you do every step exactly as described, starting from the first every time if you suspect something was not done properly. Also, if you still experience issues, please post the console logs while you perform each step.
ok, so i went to the entire process a couple of times, again with no success. Its strange because it does all the things but is still recognized as the wrong board, but this time its another wrong board then previous. i document now the console reports, i get during the flashing.
After burn bootloader:
esptool.py v4.5.1
Serial port /dev/cu.usbmodem101
Connecting...
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 48:27:e2:fc:d7:b8
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 2.0s
Hard resetting via RTS pin...
After Upload using programmer:
Der Sketch verwendet 286061 Bytes (9%) des Programmspeicherplatzes. Das Maximum sind 3145728 Bytes.
Globale Variablen verwenden 30552 Bytes (9%) des dynamischen Speichers, 297128 Bytes für lokale Variablen verbleiben. Das Maximum sind 327680 Bytes.
esptool.py v4.5.1
Serial port /dev/cu.usbmodem101
Connecting...
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 48:27:e2:fc:d7:b8
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00f70000 to 0x00fb6fff...
Flash will be erased from 0x00010000 to 0x00055fff...
Compressed 15104 bytes to 10429...
Writing at 0x00000000... (100 %)
Wrote 15104 bytes (10429 compressed) at 0x00000000 in 0.2 seconds (effective 782.1 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 158...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (158 compressed) at 0x00008000 in 0.0 seconds (effective 1031.4 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 1370.4 kbit/s)...
Hash of data verified.
Compressed 287120 bytes to 164326...
Writing at 0x00f70000... (9 %)
Writing at 0x00f7c2f4... (18 %)
Writing at 0x00f84885... (27 %)
Writing at 0x00f89e4e... (36 %)
Writing at 0x00f8f28b... (45 %)
Writing at 0x00f945bd... (54 %)
Writing at 0x00f99d60... (63 %)
Writing at 0x00fa2f1b... (72 %)
Writing at 0x00faa749... (81 %)
Writing at 0x00faff8d... (90 %)
Writing at 0x00fb5f10... (100 %)
Wrote 287120 bytes (164326 compressed) at 0x00f70000 in 1.7 seconds (effective 1326.0 kbit/s)...
Hash of data verified.
Compressed 286432 bytes to 164283...
Writing at 0x00010000... (9 %)
Writing at 0x0001c241... (18 %)
Writing at 0x00024666... (27 %)
Writing at 0x00029c0a... (36 %)
Writing at 0x0002f050... (45 %)
Writing at 0x00034355... (54 %)
Writing at 0x000399e0... (63 %)
Writing at 0x00042ce9... (72 %)
Writing at 0x0004a4bc... (81 %)
Writing at 0x0004fd43... (90 %)
Writing at 0x00055c9d... (100 %)
Wrote 286432 bytes (164283 compressed) at 0x00010000 in 1.7 seconds (effective 1316.5 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
Thank you for the additional information. It does indeed look like everything has been done properly, so I am a bit confused by the fact it still doesn't work after the final replug.
The fact that it complains about DFU is "expected": the purple light means the Arduino bootloader is somehow still not running, so no DFU is possible in that situation. Also, as Per said in the other thread you linked, almost all the ESP32 boards share the same USB information so the IDE picks one at random among all of them.
I have 2 more followup questions for you to help me troubleshoot:
What happens if you follow the procedure up to Tools>Burn bootloader, then unplug/replug, then load a Blink sketch via Tools/Upload using programmer? NOTE: make sure "Esptool" is selected in Tools/Programmer or the IDE will attempt to use DFU.
There are two core options: an 'esp32' core from Espressif and an 'Arduino ESP32 Boards' by Arduino. Which one are you using? Does changing to the other and performing the update procedure again solve the issue?
Yes, so i assume you meant "then load a Blink sketch via Sketch/Upload using programmer" not Tools/...? (I am just trying to be 100% accurate with your instructions). I have done the process up to Tools/Burn bootloader, direct after i have uploaded a simple "blinking" sketch via sketch/Upload using programmer. this is the terminal i get:
Der Sketch verwendet 286189 Bytes (9%) des Programmspeicherplatzes. Das Maximum sind 3145728 Bytes.
Globale Variablen verwenden 30552 Bytes (9%) des dynamischen Speichers, 297128 Bytes für lokale Variablen verbleiben. Das Maximum sind 327680 Bytes.
esptool.py v4.5.1
Serial port /dev/cu.usbmodem101
Connecting...
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 48:27:e2:fc:d7:b8
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00f70000 to 0x00fb6fff...
Flash will be erased from 0x00010000 to 0x00055fff...
Compressed 15104 bytes to 10429...
Writing at 0x00000000... (100 %)
Wrote 15104 bytes (10429 compressed) at 0x00000000 in 0.2 seconds (effective 782.5 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 158...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (158 compressed) at 0x00008000 in 0.0 seconds (effective 1026.5 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 1366.8 kbit/s)...
Hash of data verified.
Compressed 287120 bytes to 164326...
Writing at 0x00f70000... (9 %)
Writing at 0x00f7c2f4... (18 %)
Writing at 0x00f84885... (27 %)
Writing at 0x00f89e4e... (36 %)
Writing at 0x00f8f28b... (45 %)
Writing at 0x00f945bd... (54 %)
Writing at 0x00f99d60... (63 %)
Writing at 0x00fa2f1b... (72 %)
Writing at 0x00faa749... (81 %)
Writing at 0x00faff8d... (90 %)
Writing at 0x00fb5f10... (100 %)
Wrote 287120 bytes (164326 compressed) at 0x00f70000 in 1.7 seconds (effective 1325.9 kbit/s)...
Hash of data verified.
Compressed 286560 bytes to 164342...
Writing at 0x00010000... (9 %)
Writing at 0x0001c258... (18 %)
Writing at 0x00024697... (27 %)
Writing at 0x00029c44... (36 %)
Writing at 0x0002f08c... (45 %)
Writing at 0x00034395... (54 %)
Writing at 0x00039a25... (63 %)
Writing at 0x00042c4c... (72 %)
Writing at 0x0004a4f2... (81 %)
Writing at 0x0004fd2f... (90 %)
Writing at 0x00055cb8... (100 %)
Wrote 286560 bytes (164342 compressed) at 0x00010000 in 1.7 seconds (effective 1313.3 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
this is a screen shot since i am not sure where i can see if i am using "esp32" core from Espressif or "Arduino ESP32 Boards" i guess the later one is the case see:
Sorry for the delay and thanks for getting back to me.
Yes I meant 'Sketch'... letting fingers write while brain sleeps = bad
Also, yes you are using the version of the ESP32 core by Arduino. Might have been easier to say "there's only one board in the menu" believe me the other has hundreds and fills your screen.
I am still unclear on the situation on your board, so I can't give definitive advice, but I have another thing to test. Can you try this variation on the recovery procedure and let us know if that does actually update the Flash?
believe me the other has hundreds and fills your screen.
?