ESP32 Forum

Hi All,

I spent last week connecting up an ESP32-WROOM-32D to my current STM32H7 project (that is already up and running). I received 3 of them from digikey, all came pre-loaded with ESP32-AT firmware 1.1.3.

I wired it up in the usual fashion (as reference in the datasheet and on numerous other sites, eval board schematics, etc)

1) VDD = tied to 3.3V
2) GND = all GND pins tied to GND
3) EN = pulled up via 10k resistor to 3.3V

4) IO0 = jumper to flip between being pulled up via 10k to 3.3v or pulled down via 10k to GND (for flashing)
5) IO2 = IO0 = pulled to GND via 10k resistor

bootup into normal mode or downloader mode was fine, using the simple jumper to pull IO0 hi or low.

Flashing proved to be quite difficult, and never fully completed, as I constantly got flash errors at all different times, packet header errors, even full erase started but didn't complete. This happened on every attempt at random places.

I noticed many users of other eval boards, other setups, etc were having to add large bulk caps to their EN pins in order to get flashing to work. This tells me the ESP32 needs to pull a decent amount of current into the EN pin, and it's not just a simple buffered I/O input?
(maybe espressif needs to revisit the core design of their esp32 chip and see how exactly this EN pin was layed down in the logic)


Anyhow, I also tied it to a GPIO pin of my STM32, and drove it high/low via the GPIO (leaving the 10k pull-up still in place), same flashing issues, it was crashing or timeouts most of the time. I then did a quick test and shorted the EN pin to Vdd (3.3v), and all worked perfect.

So, again going down that same path that EN is not a simple buffered I/O input, it needs to sink current, at least when doing downloading/flash things... but I would just assume it needs to pull current all the time, and just to be safe drive it from a current source, not a pull-up only.

I ended up doing a simple transistor driver, and it now works perfect, flashing was easy, and did it many times, full erase, etc, and it worked 100%, no issues.

See the below circuit for reference:

Interesting results but I don't know if I accept the fact that EN is actually sinking current. Have you measured the current into the pin? Have you scoped the vcc line during flashing? Who is adding bulk capacitance to their EN pins and are you sure it isn't to delay the rise time so that the other strapping pins are at the appropriate level?

Hi,

Yeah, I could very much be wrong, but from all the debugging and troubleshooting I did, it sure seemed to point to EN pin needing more than just a 10k pullup.

Anyhow, yes, I know many issues other dev boards are having is related to startup delays, and the state of the strapping pins. In my case that does not apply, since I set my pins to hard states before powering up (ie tied directly to GND or Vdd).

I just wanted to put this out there, in case others see similar issues...


I stumbled across various threads about adding caps, when I was trying to debug the packet header issues... I'd have to dig around again.

But this is one web page... now it may be more of a startup delay for their case?

https://randomnerdtutorials.com/solved- ... et-header/


bootup mode was never my issue, it always was entering downloader, I was just having non-stop packet header issues, timeouts, etc..


My board supply is good, my 3.3V supply can source up to 5A, and has tons of capacitance on board, so no issues there. I scoped it up, it is clean. I didn't put my meter on the EN pin to see actual current draw, I did think of doing it, but once I put in the trans. circuit and it cleared it all up, I moved on..

That's an interesting result you're seeing, I've not seen anyone reporting exactly this.

I believe the issues you've seen elsewhere where the fix is adding a capacitor to EN is (as you say) related directly to timing of serial signals in Windows or in VMs, and the automatic reset circuit on most dev boards. The capacitor value doesn't need to be large, but it slows the rising edge (as the cap charges via pullup resistor) and this fixes the relative timing of RTS & DTR. The cheap dev boards which haven't added this cap nearly always work in macOS and Linux anyway, but they fail on a lot of Windows installs without the cap.

I've seen scope traces that strongly indicate that difference is in the host OS timing and not anything else, a single pullup resistor is more than enough to drive the EN pin but the timing of the serial transitions may be off. (Original discussion of the timing bug is here).

When driving the EN pin directly from the STM GPIO, was there a series resistor inline? I'm wondering if maybe the value was ringing on the rising edge and this might have glitched the chip coming out of reset in some way. But this is a total guess, without a scope trace it's just speculation and I've never heard of a problem like this.

In any case I'm glad you found a solution that works for you. I'm going to remove "PLEASE READ" from the topic because I don't think this is a critical point for most people, at least without more data to confirm it.

If you end up figuring anything else about what is happening here then please share it, it would be very interesting.

Hi,

yeah, you can definitely modify the subject line and do whatever you want with it...

I had no series resistor off the GPIO, this was a direct connection...

but yeah, you are right, there are tons of ESP32 flavored boards out there that seem to be working..

I too found it very strange I kept getting flash/packet errors, from the start, with the basic config of just having EN pulled up via 10k. Once I got to the point of shorting it to Vdd, (and proved it then worked) I started to suspect something was odd there, if EN indeed needs micro currents, than a simple 10k pullup is all you need.

When I did first mess with the GPIO pin being tied to the EN (still pulled up to 10k), I configured the GPIO to be Push-Pull to ensure it was driving it high, and verified via DVM it was high, and packet errors. and of course also set GPIO as a test to OpenDrain to just allow the pull-up to pull it high, and of course expected errors theree..

Anyhow, I'll report back if I can diagnose any further... for now just using a transistor to drive EN works perfect, so all is good.

Just in case others experience anything similar...

mikes_md wrote: ↑

Tue Jul 23, 2019 12:03 pm

When I did first mess with the GPIO pin being tied to the EN (still pulled up to 10k), I configured the GPIO to be Push-Pull to ensure it was driving it high, and verified via DVM it was high, and packet errors. and of course also set GPIO as a test to OpenDrain to just allow the pull-up to pull it high, and of course expected errors theree..

I see. Using Open Drain and a pullup to VDD there won't be any ringing on the rising edge either. So adding a series resistor from the GPIO likely wouldn't have changed anything either.

mikes_md wrote: ↑

Tue Jul 23, 2019 12:03 pm

Anyhow, I'll report back if I can diagnose any further... for now just using a transistor to drive EN works perfect, so all is good.

Please do. If you are able to share a schematic and/or a photo of your board that would be interesting as well, but understand if this is not possible.

Hi,

no problem, my entire project is public and you can see it on hackaday... it's a controller for a reflow oven, using an STM32H7 processor. So there is quite a bit of other stuff in this schematic, but you can just ignore it, as all of that is already done and finalized.

https://cdn.hackaday.io/images/2119071563754466329.jpg

(https://hackaday.io/project/161716-t962 ... sing-stm32)

The ESP32 I just added into the schematic, which is on the far right of the image, I added in the circuit as it is working now.

** Note: ** The PCB linked in the project is NOT the one I am working from now, I am using a prior revision without the ESP32 added onto the board, as I just recently discovered the esp32 device! haha.. I guess I didn't look hard enough before I made this project, as I really wanted wifi from the beginning, but had no idea you all made such an awesome little module.

So I temporarily mounted the esp32 onto the board, and made the minimal connections to test it out, ie
1) Vdd
2) three GND connections
3) EN pulled up via 10k
4) UART0 for debug out and flashing
5) IO2 tied to GND
6) IO0 tied to GND

I started with this setup, EN was tied directly to 3.3V through a 10k resistor... so all 'config' pins were hard tied to proper state to go into downloader, which was always occuring, there was no intermittent activity there, it always booted every single time into downloader as I expected..

It was during the actual flash activites (ie erase attempt, write attempt, etc) that the random errors happened and it failed.

So that's what led me down the road of playing with adding the GPIO to enable/disable, etc, then eventually adding the transistor circuit to get it working right.

I'll be sending out for a PCB to be fab'd this week, so in the next week or two I'll build up the new board and test it all out... I can try to gather some debug info and 'current' info with the new board, as it will be easier to do testing with a PCB versus trying to mess with a temp/patch wired setup...

but like I said, the new board should work fine, as I put the EN/transistor setup in there, but I can at least repeat some of my tests from before, removing the EN circuit, and see if I can repeat the previous results...

mikes_md wrote: ↑

Wed Jul 24, 2019 12:23 pm

** Note: ** The PCB linked in the project is NOT the one I am working from now, I am using a prior revision without the ESP32 added onto the board

Ah... do you have a photo of how it's wired in and powered? There are quite a few bug reports where someone reveals they've bodged an ESP32 with wires instead of mounting on a PCB, and this often turns out to be root cause of stability problems. The WROOM modules are very much designed to be mounted on a PCB with nice low-ESR caps connected right near the power & ground pins, and voltage glitches (and/or ground bounce) can be very hard to catch on a scope in these kind of situations.

This might be the reason for the EN pin weirdness, especially as connecting the EN pin the way that you have is giving a second low impedance path for current to get into the chip (during a brownout glitch, if the voltage at EN goes high enough above VDD to activate the chip's protection circuit then it can parasitically power the chip via EN...)

I'll be sending out for a PCB to be fab'd this week, so in the next week or two I'll build up the new board and test it all out...

If you have space on the board, suggest adding a "DNP" (Do Not Place") footprint for a series resistor between the "EN" GPIO of the STM32 and the EN pin directly. You can try placing this resistor first and see if it works OK with the ESP32 sitting on the PCB instead of wired in. If it doesn't work, desolder that and go back to the more complex EN transistor circuit...


Very neat project, btw. If 4 megabytes of PSRAM is enough for framebuffer data then you could always try out ESP-IDF and drop down to a single MCU.

Ah... do you have a photo of how it's wired in and powered?
If you have space on the board, suggest adding a "DNP" (Do Not Place") footprint for a series resistor between the "EN" GPIO of the STM32 and the EN pin directly. You can try placing this resistor first and see if it works OK with the ESP32 sitting on the PCB instead of wired in. If it doesn't work, desolder that and go back to the more complex EN transistor circuit...

I don't currently have a pic, I"m trying not to disturb my test rig anymore as my modded board sits under my touch LCD that is also mounted to my test rig, so removing the board means disconnecting the TFT FPC cables, which are starting to get overstressed from all the prior work getting the main board, working, etc.. lol

So, it is wired up with short small guage (30AWG) to vdd/gnd sources right next to where I taped down the module to the board..and there is plenty of capacitance (electrolytic and ceramic) within 1/4" or so of the vdd pins I tapped into.

But yeah, like you said, things get funky when you have to rig up connections with test wire... so I'll get a much better feel when I populate the finished board.. I'll post back once I get all back and built..

Very neat project, btw. If 4 megabytes of PSRAM is enough for framebuffer data then you could always try out ESP-IDF and drop down to a single MCU.

LOL, well, it would be tight for sure, I'm using quite a bit of SRAM for the ewWin (graphics) and associated drawing operations, on top of the min. 2MB for a single frame buffer, but I hope to get double-buffering working nicely with emWin and some point and use two or three frame buffers.. hence the 64MB sdram on the board..

plus I have scratch buffers for decoded JPEG images, so another 2MB+, so prob. wouldn't be enough ram there..also, the STM32 has an LTDC display controller (parallel), which takes up a good amount of GPIO, and handles all the display controller interfacing. I'd prob. have to switch to an SDI or similar serial TFT in order to go to ESP..

I'm sure it could all be done, but at this point just too much re-work

BUT, I'm sure I will be playing needing to write my own code into the ESP at some point, once I decide how I'll be adding remote control/etc into the project, maybe host most of the web or remote code on the ESP, and the stm32 will just be source out the real time data.. something along those lines..

mikes_md wrote: ↑

Wed Jul 24, 2019 2:15 pm

So, it is wired up with short small guage (30AWG) to vdd/gnd sources right next to where I taped down the module to the board..and there is plenty of capacitance (electrolytic and ceramic) within 1/4" or so of the vdd pins I tapped into.

30AWG is something like 320milliohms/m resistance, so even a fairly short length of wire has significant resistance compared to a small ceramic cap's ESR (remember the effective length is doubled due to power/ground both being wired this way). I would bet money this is why the ESP32 is randomly failing during flash operations (which require small bursts of power consumption), and adding the transistor-driven input to EN inadvertently improves the power supply by connecting a second parasitic power wire via the EN pin.

mikes_md wrote: ↑

Wed Jul 24, 2019 2:15 pm

I'm sure it could all be done, but at this point just too much re-work

Fair enough, apologies for being cheeky.