XIAO ESP32C3 high power consumption and weird LED behavior

@msfujino, @hobbya
This is interesting information which I didn’t find so far.
But this confuses me even more, as when calculating the current which the battery will be charged based on the ISET-resistor (2k7) we get lower values than reported from the thread linked above from @msfujino. So, we now even have contradictory information.

@PJ_Glasso
Interesting to know would now also be, if this Note 1 is really only applicable on the Charge Mode or should be used on the Standby Mode as well. Because under Charge Termination it is noted, that when the chip enters Standby Mode (which I guess happens when no battery is connected but ISET is still pulled to GND) the input current drops to 200 uA, which is well above the values in the table.
This then could actually be this vampire-current. I did check with a second XIAO, which behaves exactly the same.

And regarding the battery level read: they at least justify the lack of implementation. And I guess, an additional voltage divider would mean one more time some more current.

me2,

As shown in the link below, the battery is charged at a charging current of 1000/2.7k = 370mA, set at 2k7.
Charging characteristics of XIAO_nRF52840 and XIAO_ESP32C3

Since I can’t get the datasheet for the ETA4054, I thought about it while looking at the datasheet for the MCP73831, which seems to be almost equivalent.
In the SupplyCurrent(ChargeComplete, NoBattery) section, there is a description of Typ.53uA, Max.200uA.

@hobbya was able to locate the datasheet of the ETA at LCSC

But you are still right in the end, because I was refering to the different formula to calculate the charging current for the ETA, but just simply overlooked the square in the formula yesterday. Without the square it would be around 270 mA (incorrect) instead of now again ~360 mA.

In the datasheets of the XC6802 and the ETA4054 is not exactly specified what happens, when there is simply no battery connected without a proper shut-down. But I came to the same conclusion that it will probably behave as in Standby Mode.

It will then consume around the values you provided (60 to 100(max) uA, maybe even 200 uA regarding the above note).

This all would kind of confirm (except the blinking of the LED) my initial question and makes the XIAO only usefull for low(er) power applications when powered over the battery only.

Hi there,
Pretty sure the LED only blinks for a short period?
AFAIK.
HTH
GL :wink: PJ

Really sure the LED blinks only a short time, but not 100 % sure the exact duration of the pulse. The frequency is between 24-25 Hz (checked with oscilloscope during current measurements and optically with a 960 fps camera). The “blinking” is visible by eye and it can be observed, that the LED is on at max one of the frames of the camera (so pulse is shorter than 1 ms).
As mentioned above, the current measurement show, that the pulse duration is around 16-18 us, but due to the low bandwidth (300 kHz) of the uCurrent, the exact values of duration and especially amplithude are to be questioned.

If I find time soon, I will try to probe the LED directly with the oscilloscope, to get better values of duration (but will add no value to current obviously).

So, did some more measurements. The PPK2 did arrive in the meantime and shows some slightly different values.

  • Previous current measurement with uCurrent and DDM: ~218 uA
  • new with PPK2: ~245 uA

To estimate, which of the two might be “more correct”, I looked for some DDM with the ability to measure sub-mA ranges directly:

  • directly with current measuring functionality of 4.5 digit DDM at 2000 uA range: ~250 uA
  • directly with current measuring functionality of cheap 3.5 digit DDM at 2000 uA range: ~250 uA

So it seams that my uCurrent is a bit off, as the other measurements without the uCurrent show very similar values.

I did now as well probe the LED directly with the oscilloscope and got again ~24 Hz, but a clearly longer pulse duration of ~353 us, which was not visible in the current measurements with the uCurrent.

1 Like

If the voltage applied at ppk2 is reduced below 5 V, there is a voltage at which the frequency of the pulse current changes significantly.

I’m really sorry, but I do not fully understand, what exactly you mean with this. The voltage at the PPK2 was set to 5 V, as I was powering the XIAO at the USB port.
The way shorter pulse duration I was mentioning earlier was “measured” with the uCurrent and an oscilloscope. At that time, I didn’t have a PPK2 yet.

Or were you referring to a different response?

I am applying voltage from PPK2 to the 5V pin of XIAO and observing the current. when 5V is applied, the period of the pulsed current that appears during the sleep period is 20mS. when the voltage is reduced to near the lower limit of the ETA4054’s operating range, the pulsed current period is 1.1sec. It appears that the operating mode is changing, but I do not know what is happening.
This is just information; try it when you get PPK2.

Hi there,
So looking at the S3 spec’s on sleep I see this foot note?

  1. 8 MHz RC clock source used by digital peripherals: Currently, only LEDC uses this clock source during Light-sleep mode. When LEDC selects this clock source, this feature is automatically enabled.

GL :slight_smile: PJ

The waveforms also show that the average power consumption during deep-sleep mode is 26.85 μW, and the average power consumption during active mode is 78.32 mW .

I have just run into this issue when powering the C3 from the batteries of an external board.

It’s a pity that the XIAO boards don’t have a way to completely disable the charger when using the 5V pins.

I observe an average deep-sleep consumption of ~270uA (when using the 5v pin with 4 AAs in series totally 6 volts):

I believe the power consumption peaks come from the regulator and the led, which, as others have observed, blinks (permanently) with an odd frequency.

I wonder how much would we save by removing the charging LED (or the full charging circuit for that matter)

OK, I bit the bullet and desoldered the charging chip. Consumption goes down to ~150uA in deep-sleep. This, the charging chip + LED were consuming around 120uA. I still don’t understand why Seeed didn’t incorporate a way to disable them …

There are no spikes anymore

Here are some pics of the process. This was my first real experience with a hot air station. I protected the USB port and buttons with aluminum foil tape but I clearly should had added more layers of foil to the buttons since they melted anyways (which is fine for the most part since I don’t really use them for flashing):



Next, I think I will try to desolder the R9 pulldown resistor (if I manage to identify it), since AFAIU it’s not needed anymore. That should bring the deep-sleep power down to ~100uA.

Thanks to Seeed sharing the Schematic/PCB I have managed to identify R9 and removed it:

After that, the power consumption goes down to ~90uA :slight_smile:

It would be good to know where the extra 45 uA (compared to the spec’ed 44uA deep-sleep) are going to. Probably it’s just that I am using 6V to power the board and it’s being dissipated by the regulator.

If you put ppk2 in source meter mode and reduce the voltage applied to the 5V pin to about 3.8V, you will see the current decrease.

Good point @msfujino !

Interestingly, when using source meter mode and separating the XIAO from the main board, the power consumption is higher: ~100uA with 3.7v and ~120uA with 5v.

I can’t explain why it’s higher (the main board is supplying 6v) but something other than the charger and R9 is consuming ~50uA over the spec’ed 44uA deep-sleep consumption.

If there are no connections on any pins or pads other than the 5V and GND pins connected to ppk2, it is strange that the sleep current is over 100uA.
It could be leakage current from C10 and C39, but I don’t know if 50uA is a reasonable value.
For reference, the sleep current is less than 50uA when powered from the battery pad as shown in the link below.

Yep, that was measured without any other connections. Maybe there is a software issue. However, I am using a barebones esp-idf example which just goes to sleep …

I will see if removing C39 makes a difference. AFAIU I shouldn’t be removing C10 permanently.

I found the culprit. I had the USB port connected (using a cable with the power removed though, so I thought it wouldn’t make a difference). After detaching it the XIAO consumes just 40uA :slight_smile:

As a side note, I had also removed removed C39 but it didn’t make a difference

1 Like