Adafruit Feather HUZZAH ESP8266 Power Consume

[adafruit_support_mike]

That's another way to handle external power control, yes. Glad to hear it's working for you!

[tve]

Whoa! This is sooo BANNED! I purchased an Adafruit product because I wanted to experiment with deep-sleep and the new automatic light-sleep and I wanted to be sure to get a quality product that was properly designed for LiPo operation. After measuring, like others, that deep-sleep consumes 6.5mA I land here to discover that the Huzzah32 has exactly the type of cr@p design I was trying to avoid! So long for spending $20, I now get to go back and order a cheap Chinese board that actually works at low power and costs about 1/3rd as much. Very, very BANNED!

[matthijskooijman]

Did anyone figure out where all this 6.5mA of current is going? I've been measuring around the board, but I couldn't really find it (or actually, while writing this post, I may have found it. Read on below).

I've tested both with CH_PD tied to GND (which should drop the power usage of the ESP into the uA range), as well as with EN tied to GND (which should disable the 3.3V rail completely). In both cases, the board draws around 6.5ma when fed through VBAT. When feeding through VBUS, I see 8.5mA with EN high and 6.5mA with EN low. I mostly focused testing on the case with 3.3V enabled, since disabling VCC might cause chips to start passing current through unexpected pins.

Some possible power sinks:

• The CP2104 USB-to-serial. The suspend current is specified as max 200uA. With 3.3V enabled I checked the suspend output pin which indeed shows this chip is suspended. With 3.3V disabled, this chip might behave weirdly, but the only pin that is powered is VBUS. It seems to pass some voltage (perhaps also current) from VBUS into its signal pins.
• The MCP73831/2 battery charger. This has a max current of 1500uA (when charging), the idle current is in the single-digit uA range. Since VBAT is connected to VBUS (which is the charger's input), VBUS has a voltage even when just the battery is connected, but this is 150mV below VBAT. According to the charger datasheet, in this case the max supply current should be 5uA.
• The AP2112 re (wouldn't help for sleep, though). gulator (type confirmed by marking code, since the eagle files have a different model number) should draw up to 80uA when on and up to 1 uA when disabled.
• Pullups. With 3.3V enabled, only R1 (CH_PD) drops a voltage (3.3V / 10k = 0.3mA). There might be some internal pullups, though I do not think any of these is asserted other than CH_PD.
• Transistors. With 3.3V enabled, R4 and R5 drop 2-3mV of voltage, so they leak 0.3uA. For both transistors, the collector is 100mV or more below the emitter and the base a few mV below the emitter, so they should be solidly turned off.

With 3.3V disabled, I am even more confused. In this case, only VBAT and (through D4) VBUS should have a voltage (3.3V is indeed 0V) but I also note power on the ESP (3.0V on GPIO0, 3.4V on RXD and 3.3V on TXD, 1.8V on RESET) and on the CP2104 (various pins have 3.4V). It seems likely that current passes from VBAT, through VBUS, through the CP2104 into the ESP (in fact, I can see no other route). This is commonly through a TX pin (which are idle HIGH), e.g. the CP2104's TX that connects to the ESP's RX), except that this has R11 in series (which drops only 2mV over 1k, so that could only account for 2uA). Perhaps the CP2104 when powered down somehow also passes current through its RX pin (into the ESP's TX pin). Or perhaps the transistors pass more current than I think, perhaps they work differently when the collector is below the emitter?

Looking more closely at the board, I noticed that the schematics do not actually match my board (my board has a circled E on the bottom and is presumably revE, while the schematics are revC). If any Adafruit staff is reading along, it would be nice if more recent revisions were published at github and the website. Update: RevE schematics have been published on my request. Yay!

The schematics have the CP2104 self-powered (VDD, VDDIO and REGIN connected to 3.3V, and only VBUS connects to USB), whereas the board has it bus-powered (VBUS connected to REGIN, VDD and VDDIO connected together but not to 3.3V). This would at least explain that the CP2104 is powered on and keeping some of its pins high. It should still not use so much current, but there could leak some current into the ESP like this).

I wonder if there should also be a diode from VBUS to the regulator input, to prevent VBUS (and thus the CP2104) from being powered by VBAT. I tested this theory partly by cutting a trace on the bottom of the board between the USB plug and the CP2104 on one hand, and the charger and regulator on the other hand. This prevents VBAT from powering the CP2104, and indeed drops the powerdown current to around 400uA. It also prevents powering the board from USB, or charging the battery, so that's a downside left to fix (with a diode, and/or by cutting in a different place so the charger stays on the USB side rather than on the regulator side, but I couldn't really see that trace).

A first test shows that uploading and blinking still works, haven't done any other testing.

Some additional thoughts are that the older RevC design might have been better, since then at least you would power down the CP2104 when disabling 3.3V. Probably wouldn't help for deep sleep, though. The new RevE design seems to intend to have the CP2104 bus-powered, so powered-down when USB is disconnected (but lacking a diode, it fails to attain that goal). However, if it would have succeeded, that might actually have problems of its own, as there might be additional leakage current while the ESP is running (or sleeping with its TX pin high) and dumping current into the powered-down CP2104 through its serial and handshaking lines (e.g. the reverse of the problem with the ESP powered down). I guess the *real* solution to this kind of stuff is to make sure that signal lines are disconnected by FETs when either side of the connection is sleeping, but that's not supertrivial to add, of course...

Bedtime now, to be continued later.

[tve]

The best I've come up with is to put a 47k resistor between the USB D- and gnd: https://blog.voneicken.com/2018/lp-wifi ... t-huzzah32

[matthijskooijman]

@tve, yeah , I read about that D- hack. Any idea *why* it works? And how did you choose the resistor value? I see you use the esp32 version, so perhaps there is a different problem on that board.

[matthijskooijman]

I did a few more measurements, all with the USB trace cut and the USB2serial chip powered down.

When running with the regulator disabled, or with the ESP in powerdown, I get around 390uA. Given that both have a 1k pullup to either 3.3V or 3.9V (VBAT), most of that current is current through the pulldown. Indeed, if I remove the 1k pullup on the enable line and add 10k pulldown to it (keeping the regulator disabled without any current through the pulldown), current drops to a whopping 6uA (which is probably the standby current of the charger, which is still fed through VBAT).

Keeping the regulator enabled, but putting the ESP in deepsleep (so no pullups that are drawing current), I get a power usage of around 90uA. This is probably the regulator and the ESP combined?

Next tests are to cut the trace between the regulator and the charger (and restore the other trace I cut) and insert a diode. Another test would be to restore the old traces, and figure out where the current is flowing *exactly* by cutting a serial trace and perhaps lifting some transistors (but I'm not sure if that's really needed).

[hadim]

According to this https://openhomeautomation.net/esp8266-battery, the ESP8266 from Sparkfun can last years on a battery. Any idea how to adapt this to the Adafruit Feather ESP8266 and/or the Adafruit ESP8266 alone?

The key seems to be turn off a LED: "For newest versions of the SparkFun thing, you can simply unsolder the “PWR” jumper at the back of the board. For older versions like the one I have, you can simply cut the trace between the PWR LED and the nearby resistor.".

But I am not sure this LED is present and on on the Adafruit version of it.

Can someone confirm?

[adafruit_support_mike]

Recent versions of the Feather HUZZAH make it possible to shut down the CP2104 USB-to-Serial converter when the ESP8266 core is in a deep sleep mode.

Most Feathers drop to about 80uA of current when you pull their EN pin low, shutting off the voltage regulator. That sounds more drastic than putting the microcontroller into a sleep mode, but given the challenges of bringing a sleeping chip back up to full operation, it can be a lot less arcane. IIRC, there were some bugs with synchronization issues in things like making the Wifi and I2C start up again.

Cutting power also gives you the option to drop the current consumption by a few orders of magnitude. The TPL5110 is a low-power timer that draws less than 100nA while it's counting.. about 1/1000th of the 77uA mentioned in the article linked above, or the 80uA of pulling the EN pin low:

https://www.adafruit.com/product/3435

In my own testing of the TPL5110, I powered the chip from a 10uF capacitor and tracked the voltage as it fell. It took a couple of days to drop from 5V to 2V. I calculated about 1 year of operation per milliamp-hour of battery.

The TPL5110 breakout has a power-on LED, and as discussed in the linked article, that consumes most of the board's curret. Even when the power is off, reverse leakage through the LED is about 25uA. You can cut a jumper to the LED to take the current consumption down to the 100nA range.

[hadim]

Thank you @adafruit_support_mike.

How can the CP2104 be shut down? I don't really understand what you mean by "when you pull their EN pin low". How does it play with sleeping mode? Does it make the board less safe since a regulator is off?

A power consumption of 80 uA would be awesome. If it still does not work, I'll try the TPL5110 board.

Thanks.

[adafruit_support_mike]

Every Feather has an EN pin that controls the 3.3 voltage regulator. When you connect the EN pin to GND, the voltage regulator shuts off, cutting power to the rest of the board.

That's equivalent to disconnecting power, and different from putting the microcontroller into a low-power mode. When you turn on the voltage regulator by connecting the EN pin to positive voltage, the microcontroller goes through a standard cold-start boot process.

The CP2104 USB-to-Serial converter used to take its power from the USB cable's 5V line, and would continue to operate even if the rest of the board was shut down. That was the 6mA-ish load mentioned in threads above. We've changed the connections so the CP2104 gets its power from the 3.3V regulator, and shuts down along with the microcontroller when you pull the EN pin low.

[matthijskooijman]

The CP2104 USB-to-Serial converter used to take its power from the USB cable's 5V line, and would continue to operate even if the rest of the board was shut down. That was the 6mA-ish load mentioned in threads above. We've changed the connections so the CP2104 gets its power from the 3.3V regulator, and shuts down along with the microcontroller when you pull the EN pin low.

Can you clarify which revision you are talking about? I've seen schematics for revB and revC, which indeed have the CP2104 powered by the regulator, whereas the newer revE has the CP2104 powered by USB (and, as pointed out in my earlier post, also from battery due to the lack of a diode). Is there a more recent revision now?

Here's how it looks on revE:

Selection_036.png (5.53 KiB) Viewed 1716 times

Recent versions of the Feather HUZZAH make it possible to shut down the CP2104 USB-to-Serial converter when the ESP8266 core is in a deep sleep mode.

This actually seems to contradict what you said later: In deep sleep, you can't power the regulator down, so if the CP2104 is on the regulator, you can't power it down from deep sleep (you *can* power the entire board down, but that's not deep sleep).

[adafruit2]

yeah we moved the CP2104 off of the AP2112 because of a very slight power-timing issue that would cause the CP2104 to pop because it would get 3.3V power before 5V (or something like that, we cant remember exactly). however now if you have the CP2104 plugged into USB it will always draw current and the USB line is back-powered by the battery - we have a revision schematic drawn out for rev F which will block that from happening, but no ETA on when that will get into production. at least Huzzahs' aren't popping anymore :D

[AKstudios]

I'm assuming this same CP2104 timing issue also applies to the ESP32 Huzzah boards since they seem to have identical layout, i.e., CP2104 powered by regulator instead of directly by USB line. And there have been no revisions to that board since RevB.

Just putting this here since it's related.

[matthijskooijman]

Ah, nice. Could you give a preview of the (relevant part of) the new schematic? Perhaps (in a branch on) github? I'm curious how you solved this, and might perhaps see if I can modify my revE huzzah in a similar way :-)

[adafruit2]

nope, the ESP32 does not have the same issue because it was designed much later and has the blocking transistor in place - see Q3 here https://learn.adafruit.com/adafruit-huz ... /downloads