ESP8266 WiFi Shield instability

Hello,

I am using the ESP8266 WiFi shield (WRL-13287) with the Redboard turbo (DEV-14812). Initially I had difficulty with the sparkfun library not supporting the serial ports of the SAMD21 based board, but I was eventually able to modify the library and establish a connection to the ESP8266.

However, the ESP8266 power does not seem to be stable.

On most power ups the ESP8266 IC gets very hot. Measuring the 5V rail during this condition gives about 4.8V. The ESP8266 is unresponsive in this state.

Occasionally the blue stat LED will blink on power up, this appears to be a “good” power up, the 5V rail measures 5.0V, and the ESP8266 runs cool.

On two occasions I have been able to get the system to a solid blue LED and a confirmed connection to my network, using the ESP8266_Shield_Demo sketch. However, the board usually transitions back to the bad state before I can do anything useful.

From reading reviews of this product, it seems other customers have experienced the hot and unresponsive ESP8266. In my case, none of the pins appear to be shorted. All I can do is repeatedly power cycle the system and occasionally get a temporarily good power up. I have noticed that holding the redboard in reset appears to increase my chances of a good power up, opening the serial monitor almost always pushes the board into the bad state.

I have tried multiple USB power supplies and cables, with no change in results.

Unfortunately I do not have a scope to look at the power with.

What is going on here?

After poking around online further, the issue documented here seems to match what I am experiencing:

https://www.ondrovo.com/a/20170205-esp-self-destruct/

I can’t explain why other users of this board don’t have the same issue.

OK I worked on this all day and did make some progress. I figured since the chip was getting stuck in a bad state, I should try to reset it somehow.

The reset pin on the ESP8266 (32) doesn’t seem to do anything when pulled low. Maybe it resets program execution on the ESP8266, but not if it’s already latched up.

The enable pin on the ESP8266 (7) though is definitely resetting the IC. So I jumpered this to digital pin 2 on the shield and let the redboard drive it to reset the ESP8266. The ESP8266 seems to be super finnicky about how this pin is driven. It doesn’t enable if the pin is set as an input and pulled up (idk why). But just using digital write high does enable the ESP8266. However, I have to wait until the redboard isn’t doing anything else, like using SerialUSB, or the ESP8266 will just lock up and get hot instead of initializing correctly.

So holding the ESP8266 disabled until after the supplies are fully up and there are no serial transactions in progress actually allows it startup reliably. I don’t have much to go on, but I assume the blue stat LED blinking is normal startup behavior. This allows me to navigate through the ESP8266_Shield_Demo sketch all the way to the serverDemo() function.

Any attempt to connect to the server demo fails almost immediately. The program makes it to the “Client Connected!” print, then immediately disconnects. I’ve tried this a few hundred times, and gotten maybe 3-4 connections, but they only last long enough to get a few characters through. During a connection, the serial connection between the ESP8266 and the redboard gets garbled.

It appears that the ESP8266 is super sensitive to power quality, and the power quality on the ESP8266 shield is VERY marginal. My best guess is that letting the +3.3V rail come up before enabling helps the +3.3V supply just barely survive startup. Any attempt to transmit seems to temporarily upset the ESP8266, breaking the connection and scrambling serial to the redboard, but occasionally a tiny bit of data gets out.

My next step would be to add a giant decoupling cap on the 3.3V rail, but I don’t have any spare parts for this project. Previous users of the ESP8266 have recommended anything between 10uF and 1000uF. I don’t know why the onboard AP2112k is inadequate, it’s current rating should be sufficient, but maybe its transient response is inadequate.

Looking at the schematic, the ESP8266 has four power inputs, even though they are all 3.3V. This is an RF part, why aren’t these decoupled independently? All four inputs are sharing a single 0.1uF and 10uF. Further, these power pins are fed from a single longish trace under the part, this may allow the inputs to disrupt one another. I wonder if there may be some requirement for staging these rails too, perhaps the PA needs to power up last to avoid latching up?

I expected this product to work. As is, it can’t even power itself up properly, let alone do anything.

It also appears that the 3.3V trace is cutting the ground plane between the ESP8266 and it’s antenna. This is probably diverting RF current through a larger loop, and messing up the impedance. Maybe this is causing some interference on the board?

Hi Jeffrey.

The points you bring up are very possibly what causes issues for this board for some people. Some folks have no issues at all and others have a really hard time. My guess is that small manufacturing differences between ESP8266 chips might be contributing to the issue as well.

I’ve recorded your findings for our engineers to have a look at. Hopefully we can get this revised at some point to eliminate the issue. Thank you for your feedback! It helps us make better products.

Sure thing Chris, glad it’s helpful. This board is almost the simplest way to get an arduino online, it just doesn’t quite work haha.

I do get the impression that the ESP8266 is not very consistent. That seems to match what other people are reporting.

https://www.espressif.com/sites/default … nes_en.pdf

This document has decent guidelines for the ESP8266 hardware, and covers grounding, decoupling, and layout recommendations as well as typical layout problems and solutions. The doc describes reflection due to impedance mismatch as one of the causes for reduced power quality and peculiar PA behavior. It also recommends placing an inductor at pins 3 and 4, which I assume are the PA power inputs. It’s not clear if this is meant to be a filter or some sort of RF biasing.

So what should I do with my Wifi Shield? As it is, it’s non-functional, and has some rework on it. I’d like to keep debugging, but it seems my unit is particularly sensitive, so I can’t really tell what “good” behavior looks like. Could you refund the cost of the first unit so I can get a spare to compare with and keep making progress? I could RMA it too, but I don’t think we’re likely to learn much from that. Order number is #1290300.

Hi Jeff. I’ll PM you on this shortly.

Chris

Got the replacement kit today.

Soldered on headers, plugged it into the redboard turbo to test. ESP8266 doesn’t boot (no blinking blue LED), and get’s very hot, just like the previous part.

Performed the enable rework described above. Now chip boots and acts just like the first shield. As soon as I try to connect to it it stops working. if I try enough times I can get one character through.

Don’t know what else to try.