Unable to access custom ESP32 over Serial/USB

[ESP_Sprite]

Suggest very much you disregard that document; it assumes a bunch of things about startup voltages that work for that specific board but aren't generally applicable. Instead, maybe take a look at the hardware design guidelines (but note you can skip 80% there as the module already incorporates it) or for a more terse minimal schematic, figure 5 in the datasheet for your module.

[ESP_Sprite]

Also, before we go in the woods debugging your otherwise quite artistic ESP32 setup, what is your actual purpose here? Wouldn't it be easy to grab e.g. one of those ESP32 programming boards like this? (Note: not endorsing these boards, just indicating they're out there.)

[sergiomarina]

Hello ESP_Sprite,
thank you. I think we are in synch since the setup I did respects requirements in fig 5 of the datasheet (even if is NRND)

The ESP32 WROOM 32E module are unstable (I tested two of the batch I've just received).
At the present I have a cyclic RTCWDT_RTC_RESET message.

I'm aimed to perform a "GO - NOGO" procedure so I can classify the ESP32 WROOM 32E components.

At the present I have a cyclic RTCWDT_RTC_RESET message for both the ESP32 WROOM 32E components under test.
Could you suggest me how-to stop the reset so to have the ESP32 operating in regular flash mode?

[ESP_Sprite]

Could be expected behaviour; the modules come without firmware and will bootloop when not flashed. What happens if you start with GPIO0 pulled down? Does the module go into download mode? Does that allow you to flash the module?

[sergiomarina]

Hello ESP_Sprite,
thank you for the support. I'm just now having a break to summarize in this POST.
Reached the "waiting for download" state with pull down resistors connected to EN, IO0 and IO12 pins.
Loaded a FW to measure analog input every second. Both ESP32 modules.
The FW does not use RF section to better check GO NOGO stability at lowest level possible.
The tests carried out on the first module only are not good. I needed to reduce the pull up resistors for both EN and IO0 down to 820 and 100 ohm respectively. These values are low to me but I needed to reduce since EN was too low and the module or reseted for POWERON or froze in an halt state. Same time I had to pull up the IO0 to avoid "waiting for download" state every reset button push. Starting with 10k and progressively down to 100ohm. Now the stability increased but still too limited.
Regarding to the datasheet ("https://www.espressif.com/sites/default ... eet_en.pdf") figure 5 reports "TBD" values for both resistor and capacitor. Does that means "to be defined"?

Furthermore I still consider necessary a document like
https://www.espressif.com/sites/default ... de__EN.pdf
I mean a document that describes a way to perform a simple GO NOGO test before having the ESP32 module mounted (or more complex procedures involved).
So far I had good result with the procedure described in this doc. If this doc is superseded I ask Espressif (I hope they are reading this post other way please forward to them) to issue an updated one so I (as well as other customers) can classify what received in the box.

So far I've always received module with a std FW preloaded (ESP initialized as a wifi station. I could see "CN" wifi country). This is the first time without FW onboard. This was part of my uncertainty.

Regarding to the component you pointed out
https://www.amazon.com/Programming-Burn ... cyCode=EUR
it is 100% ok to me as long as it is Espriff certified. I need a procedure (including ESP32 WROOM 32E rev3) fully sponsored and guaranteed by the supplier (I hope Espressif is reading).
Thank you for helping

[parthibanNC]

i am also facing the same issue with ESP wrover-B module with a custom circuit and whatever the option you tried same this I have done but no updates. But this same circuit done ESP32 dev kit-c based on that I designed ckt. Really staying back for application integration.

Now development happens only on dev-kit. Still waiting for someone's help.

[ESP_Sprite]

parthibanNC: I don't see a post from you talking about your problem... how can you expect help if you don't post your issue?

[ESP_Sprite]

The tests carried out on the first module only are not good. I needed to reduce the pull up resistors for both EN and IO0 down to 820 and 100 ohm respectively. These values are low to me but I needed to reduce since EN was too low and the module or reseted for POWERON or froze in an halt state. Same time I had to pull up the IO0 to avoid "waiting for download" state every reset button push. Starting with 10k and progressively down to 100ohm. Now the stability increased but still too limited.
Regarding to the datasheet ("https://www.espressif.com/sites/default ... eet_en.pdf") figure 5 reports "TBD" values for both resistor and capacitor. Does that means "to be defined"?

Those values sound low to me, but it depends on the capacitor. Wrt the TBD values: to quote the note right under the schematic: "To ensure the power supply to the ESP32 chip during power-up, it is advised to add an RC delay circuit at the EN pin. The recommended setting for the RC delay circuit is usually R = 10 kΩand C = 1μF. However, specific parameters should be adjusted based on the power-up timing of the module and the power-up and reset sequence timing of the chip. For ESP32’s power-up and reset sequence timing diagram, please refer to SectionPower Scheme in ESP32 Datasheet."

Furthermore I still consider necessary a document like
https://www.espressif.com/sites/default ... de__EN.pdf
I mean a document that describes a way to perform a simple GO NOGO test before having the ESP32 module mounted (or more complex procedures involved).
So far I had good result with the procedure described in this doc. If this doc is superseded I ask Espressif (I hope they are reading this post other way please forward to them) to issue an updated one so I (as well as other customers) can classify what received in the box.

Note that this doc is intended as an example on how to test ESP32 boards that are already mounted in a product (hence Production Testing Guide, and not Pre-Production Testing Guide); as we don't have an example of a customer board, the doc uses a module instead to illustrate the point. Normally, a customer board would already have all the infrastructure to allow an ESP32 to boot correctly. In other words: for your setup with a 'dangling' ESP32, it still is a bad example.

Regarding to the component you pointed out
https://www.amazon.com/Programming-Burn ... cyCode=EUR
it is 100% ok to me as long as it is Espriff certified. I need a procedure (including ESP32 WROOM 32E rev3) fully sponsored and guaranteed by the supplier (I hope Espressif is reading).

It is not guaranteed; as I said it's only an example of what is out there and what you can use. Espressifs stance is that the modules come pre-tested when you buy them for us and as such there is no need to test them separately. There is a need to test them on the final board, as the components on the board can affect RF and other performance, and that is what the doc you mentioned is about.

[sergiomarina]

Hello ESP_Sprite,
thank you for the support. I'm just now end the session.
The 1uF capacitor introduced unstability and I'm confused. In order to better define the values of pullup resistors i tested with potentiometers. With capacitor the EN pullup had to reduce to a short (that burned the potentiometer, maybe the capacitor discharge)
I could refine the IO0 pullup: with capacitors on EN the threshold was lower than without (3,5k vs 8k)
Anyway I've experienced a general instability that makes difficult the setup. Did Espressif release a document for this fine tuning task?

I think electronic components must be tested before mounting into a finished product.
If I take a resistor, I have the tester to measure and check. The expected result is the nominal value within a tolerance. Very easy.
What if the component is the ESP32?
Testing after mounting is ok if performance is 100% as expected, but what if there are problems?
I think it would be meaningful to have tested before mounting.

The test procedure I'm looking for should be not invasive/repeatable and straight forth so easy to exchange among parties in different locations.That's why "dangling" is ok to me within a context of pre-mounting phase and the doc scope "Production Testing Guide " seemed suitable for my purposes, I agree the production cycle includes a testing phase but the results are for internal use only, I guess. I think espressif should define and release a non invasive/repeatable and straight forth test suite to clarify the expected results.  

[ESP_Sprite]

There's normally nothing fine-tuning-wise needed on the EN pin: an 1uF and 10K are just two out of a wide ranges of values that work. Especially if your potmeter is 'burning up', I can't help but imagine something to be wrong with your setup. You haven't accidentally shorted EN to the 3.3V line next to it or something?

This is more philosophical, but I would strongly advise against testing the ESP32 as you are doing it right now, as it probably will lead to more failed products than if you did not. As I said, the ESP32 modules are tested out of the factory, so the expected failure rate when installed in a correct way is expected to be very low. (As an indicator: I have had a certain product with an ESP32 module in it produced by the thousands. The error rate where the ESP32 module turned out to have a fault is pretty much immeasurably small, but certainly below 0.1%. Most errors were due to pick-and-place/soldering issues on our own PCB, something which you can't find by testing the components pre-assembled.) On the other hand: you handling the ESP32 by hand can induce ESD damage and soldering wires on it by hand puts solder on the pads which may later lead to an excess of solder on the PCB which leads to shorts.

(Similar to resistors. If you get resistors straight off the reel, you don't test them first: you engineer your circuit so if the resistors are indeed within tolerances, the circuit works. Why? Because it's generally cheaper to have one or two products out of a thousands not make it through QA testing rather than spending lots of effort and money qualifying each single component.)