How to know if ESP wroom 32 is broken?
Posted: Sat Apr 18, 2020 9:00 pm
Hi!
I wonder how i can easily recognize, whether a ESP 32 is broken or not.
Here's my current situation.
I've been playing around with several ESP 32 development boards in the past few months and prototyped an application on breadboards using either the esp doit devkit v1 or the az-delivery dev boards.
recently, after i decided it would be a good idea to get these prototypes manufactured (lego is expensive
) I designed my own custom "dev board" based on the esp32 devkitc v4, plus my peripherals, that i used in my prototypes.
(here the schematic of the devkit: https://dl.espressif.com/dl/schematics/ ... v4-sch.pdf)
i was super excited when they finally arrived by mail, but that excitement quickly gave way to despair. the reason: when i connected the first board into my laptop, the uart was detected and a com port was assigned, but when i wanted to upload the first sketch (blink) it only resulted in the well known error: "A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header"
it confused me a little since the devkit c has the auto bootloader functionality so i started a long and still ongoing debugging marathon. before i go into the details i want to mention that i quickly realized that i made a mistake myself. my schematic was faulty, because i accidentally connected the IO0 pin to the collector of the transistor Q2 (see linked schematic), not to the emitter
of course this could've been the problem, why i wasn't able to flash my ESP, but after i desoldered the transistor Q2 and resoldered in with the correct pin connection, the primary problem hasn't changed.
what i've been done so far / my findings:
again, how can i tell whether the esp module isn't damaged
and also what else could be wrong? I was thinking of rebuilding the entire circuit on a breadboard and step by step debugging it with single parts. I hope to find the error before i can order a new set of PCBs with all necessary corrections and additions that i found useful during debugging.
i'd be glad if someone could give some kind of direction or a hint on how to solve that problem.
until then, thank you a lot for your help.
cheers!
Traceback (most recent call last):
File "C:\Users\lieve\OneDrive\Desktop\esp-idf\tools/idf_monitor.py", line 852, in <module>
main()
File "C:\Users\lieve\OneDrive\Desktop\esp-idf\tools/idf_monitor.py", line 764, in main
monitor.main_loop()
File "C:\Users\lieve\OneDrive\Desktop\esp-idf\tools/idf_monitor.py", line 372, in main_loop
(event_tag, data) = self.event_queue.get()
File "C:\Users\lieve\.platformio\python37\lib\queue.py", line 170, in get
self.not_empty.wait()
File "C:\Users\lieve\.platformio\python37\lib\threading.py", line 296, in wait
waiter.acquire()
KeyboardInterrupt
Aborted!
I wonder how i can easily recognize, whether a ESP 32 is broken or not.
Here's my current situation.
I've been playing around with several ESP 32 development boards in the past few months and prototyped an application on breadboards using either the esp doit devkit v1 or the az-delivery dev boards.
recently, after i decided it would be a good idea to get these prototypes manufactured (lego is expensive
) I designed my own custom "dev board" based on the esp32 devkitc v4, plus my peripherals, that i used in my prototypes. (here the schematic of the devkit: https://dl.espressif.com/dl/schematics/ ... v4-sch.pdf)
i was super excited when they finally arrived by mail, but that excitement quickly gave way to despair. the reason: when i connected the first board into my laptop, the uart was detected and a com port was assigned, but when i wanted to upload the first sketch (blink) it only resulted in the well known error: "A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header"
it confused me a little since the devkit c has the auto bootloader functionality so i started a long and still ongoing debugging marathon. before i go into the details i want to mention that i quickly realized that i made a mistake myself. my schematic was faulty, because i accidentally connected the IO0 pin to the collector of the transistor Q2 (see linked schematic), not to the emitter
of course this could've been the problem, why i wasn't able to flash my ESP, but after i desoldered the transistor Q2 and resoldered in with the correct pin connection, the primary problem hasn't changed.
what i've been done so far / my findings:
- The setup (board, including peripherals) functioned using the devboards.
- I am aware that i might have damaged something during the soldering action, that's why i am asking how i can figure out if the wroom module is broken.
- In total i have 5 boards, 2 of them i altered with soldering. the first one i flipped the transistor Q2 as described, that the connection is correct, the second one i removed BOTH transistors Q1 and Q2 in order to disable the automatic bootloader functionality
- I checked the connections of my alternations (before and after) as well as various other connections with a multimeter (continuity as well as voltage) and it all checks out as expected
- I compared the corrected board (flipped transistor) with one of my devboards (az delivery) during the connection sequence (where the terminal is writing Connecting........_____....._____....._____....._____....._____....._____.....____) and the GPIO pin and EN pin are alternating between high and low (apparently trying to go into download mode). since i only have a multimeter i cannot guarantee that the sequence and timing is correct, but the circuit seems to work as intended (as far as i can tell)
- I used the second board with the removed transistors to try the manual bootloader method (manually shorting GPIO to GND). i read several posts with sometimes different descriptions of how to start the bootloader. I tried all of those i found. (like here or here but i wouldn't mind to try it again if someone posts the correct sequence.
- As a test i also manually brought an ESP8266 into bootloader mode, which worked. i tried it the same way with my boards which didn't work.
- Here's my biggest concern though: i could never see any response of the wroom. when i go into serial monitor on one of the devboards using idf.py and enter CTRL-T CTRL-P i will get into download mode (Pause app (enter bootloader mode), press Ctrl-T Ctrl-R to restart rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) waiting for download)). when i do the same with my own board, it doesn't give any response except for the Pause app message by the serial monitor programm and a Stacktrace because of a KeyboardInterrupt (see below)
- when i try CTRL-T CTRL-R to "Reset target board via RTS line" nothing happens.
- I've tried communicating with the boards using the Arduino IDE, the IDF tools (idf.py) as well as platformio
again, how can i tell whether the esp module isn't damaged
and also what else could be wrong? I was thinking of rebuilding the entire circuit on a breadboard and step by step debugging it with single parts. I hope to find the error before i can order a new set of PCBs with all necessary corrections and additions that i found useful during debugging.
i'd be glad if someone could give some kind of direction or a hint on how to solve that problem.
until then, thank you a lot for your help.
cheers!
Traceback (most recent call last):
File "C:\Users\lieve\OneDrive\Desktop\esp-idf\tools/idf_monitor.py", line 852, in <module>
main()
File "C:\Users\lieve\OneDrive\Desktop\esp-idf\tools/idf_monitor.py", line 764, in main
monitor.main_loop()
File "C:\Users\lieve\OneDrive\Desktop\esp-idf\tools/idf_monitor.py", line 372, in main_loop
(event_tag, data) = self.event_queue.get()
File "C:\Users\lieve\.platformio\python37\lib\queue.py", line 170, in get
self.not_empty.wait()
File "C:\Users\lieve\.platformio\python37\lib\threading.py", line 296, in wait
waiter.acquire()
KeyboardInterrupt
Aborted!