Hi,

I would like to test how my device, using PowerFeather, reacts when powered with a LiPo battery.

For this I have plugged a DC power supply to the BATN/BATP pins, it works fine (with 3.7V to 4.2V), however:

  • what capacity should I provide to the ::Init method parameter? Is there any risk to damage something by using a power supply rather than a battery?
  • When I go to deep sleep, this unfortunately resets the board (similarly to what I had in that post, with the USB supply: https://forum.powerfeather.dev/d/14-random-resets-after-deep-sleep/11). I now do call the Board::Init method, but it does not help. There should be something wrong in my app or sdkconfig, because the sample PowerFeather app works when I add deep sleep mode to it, so I have to investigate further. But if this issue rings a bell for something that could cause the issue, please let me know.

Many thanks!

what capacity should I provide to the ::Init method parameter? Is there any risk to damage something by using a power supply rather than a battery?

The fuel gauging will totally be invalid. Also, be careful to not enable charging, especially if your power supply doesn't tolerate 'back' current. As for the capacity, it really doesn't matter much in this case.

When I go to deep sleep, this unfortunately resets the board (similarly to what I had in that post, with the USB supply: https://forum.powerfeather.dev/d/14-random-resets-after-deep-sleep/11). I now do call the Board::Init method, but it does not help. There should be something wrong in my app or sdkconfig, because the sample PowerFeather app works when I add deep sleep mode to it, so I have to investigate further. But if this issue rings a bell for something that could cause the issue, please let me know.

Is it still just the board, or have you connected some other thing to it?

Thank you! For now I did not have the time to test much, and it was indeed with my other things, not the board alone. Will revert with more details afterwards - it was just in case you would have an immediate suggestion that would save me hours of software and hardware investigation 🙂 thank you again

Hi, I have done more tests:

  • the power-on reset happens from within the wake stub, about after 30ms of work. What I do in the stub is setting some GPIO digital outputs (in order to power 2 small stepper motors via ULN2003A circuits). They are powered via a 3.3V-5V boost, itself powered from the 3V3 PowerFeather output, and enabled via the 3V3_EN pin.
  • when the board is connected to nothing, it works well
  • when the board is connected to my devices, AND EN_3V3 is LOW, it works well
  • but when the board is connected to my devices, and EN_3V3 is HIGH (so that I can power surrounding loads), then it no longer works. These loads are less than 200mA max. I set the digital GPIOs from the wakestub. As the C++ API does not work during the wake stub, I use the following code instead, to set PIN to VAL:
  if(VAL) { 
    REG_WRITE(RTC_GPIO_OUT_W1TS_REG, BIT(RTC_GPIO_OUT_DATA_W1TS_S + PIN)); 
  } 
  else { 
    REG_WRITE(RTC_GPIO_OUT_W1TC_REG, BIT(RTC_GPIO_OUT_DATA_W1TC_S + PIN));
  } 
  CLEAR_PERI_REG_MASK(RTC_CNTL_PAD_HOLD_REG, BIT(PIN)); 
  SET_PERI_REG_MASK(RTC_CNTL_PAD_HOLD_REG, BIT(PIN));  

I power BATP and BATN via a 4.2V power supply which can deliver up to 3A, and (of course) I don't observe any voltage drop - I prefer to make it clear though.

Again, everything works fine when powered via USB, but the problem occurs while powering from battery.
I suspect some issues related to current consumption, but we are far below the 1A limit stated in the documentation.

Is there anything I should do differently?
Is there any counter-indication to use EN_3V3 and the 3V3 output, especially during the wake stub?

Many thanks!

One more observation: if, after plugging the USB power (with the power supply plugged to BATP/BATN), I click the reset button, and then unplug the USB power, then everything works fine with the BATP/BATN power only!

So it looks like something happens during the Board.init method, which behaves differently whether the USB powers is present or not??

Please also find the output of the PowerFeather init function (which returns OK in both cases).

With USB plugged:

I (1514) main_task: Calling app_main()
D (1519) PowerFeather::Utils::Mutex: Mutex 0x3fca4514 created.
D (1525) PowerFeather::Utils::Mutex: Mutex 0x3fca4514 take succeeded.
D (1531) PowerFeather::Mainboard: Battery capacity and type set to 1800 mAh, 0.
I (1539) PowerFeather::Mainboard: Termination current set to 180 mA.
D (1546) PowerFeather::Mainboard: Initialized RTC pin 14 with mode 2.
D (1552) PowerFeather::Mainboard: Check if first boot: 1.
D (1558) PowerFeather::Mainboard: Set RTC pin 14 to 1.
D (1563) PowerFeather::Mainboard: VSQT detected as 1 during initialization
D (1570) PowerFeather::Utils::MasterI2C: Start with port: 1, sda: 47, scl: 48, freq: 100000.
D (1578) intr_alloc: Connected src 43 to int 17 (cpu 0)
D (1584) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit1 on 1-byte register 16, value = 0001.
D (1593) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 16, value = 00a1.
D (1602) PowerFeather::Mainboard::BQ2562x: Write bit5 to bit5 on 1-byte register 16, value = 0081.
D (1611) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit15 on 2-byte register 06, value = 0a00.
D (1620) PowerFeather::Mainboard::BQ2562x: Write bit4 to bit11 on 2-byte register 06, value = 0640.
D (1629) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1a, value = 003d.
D (1638) PowerFeather::Mainboard::BQ2562x: Write bit7 to bit7 on 1-byte register 1a, value = 00bd.
D (1647) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 27, value = 0004.
D (1656) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit2 on 1-byte register 27, value = 0004.
D (1665) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit15 on 2-byte register 02, value = 0100.
D (1674) PowerFeather::Mainboard::BQ2562x: Write bit5 to bit10 on 2-byte register 02, value = 0020.
D (1683) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 18, value = 0004.
D (1692) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit2 on 1-byte register 18, value = 0000.
D (1701) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 18, value = 0000.
D (1710) PowerFeather::Mainboard::BQ2562x: Write bit3 to bit3 on 1-byte register 18, value = 0008.
D (1719) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 14, value = 0006.
D (1728) PowerFeather::Mainboard::BQ2562x: Write bit3 to bit4 on 1-byte register 14, value = 000e.
D (1737) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 19, value = 00c4.
D (1746) PowerFeather::Mainboard::BQ2562x: Write bit6 to bit7 on 1-byte register 19, value = 0044.
D (1755) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1b, value = 0025.
D (1764) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit4 on 1-byte register 1b, value = 0031.
D (1773) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1c, value = 003f.
D (1782) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit1 on 1-byte register 1c, value = 003e.
D (1791) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1c, value = 003e.
D (1800) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit3 on 1-byte register 1c, value = 003a.
D (1809) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1a, value = 00bd.
D (1818) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit1 on 1-byte register 1a, value = 00bd.
D (1827) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1a, value = 00bd.
D (1836) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit3 on 1-byte register 1a, value = 00b5.
D (1845) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 23, value = 0000.
D (1854) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit7 on 1-byte register 23, value = 00ff.
D (1863) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 24, value = 0000.
D (1872) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit7 on 1-byte register 24, value = 00ff.
D (1881) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 25, value = 0000.
D (1890) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit7 on 1-byte register 25, value = 00ff.
D (1899) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit15 on 2-byte register 12, value = 0010.
D (1908) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit7 on 2-byte register 12, value = 0090.
D (1917) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 16, value = 0081.
D (1926) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit1 on 1-byte register 16, value = 0080.
D (1934) PowerFeather::Mainboard: Charger IC initialized.
D (1940) PowerFeather::Mainboard::LC709204F: Read register 19 failed.
D (1946) PowerFeather::Mainboard: Unexpected result 0 on _initFuelGauge:107.
D (1954) PowerFeather::Mainboard: Initialized RTC pin 13 with mode 5.
D (1960) PowerFeather::Mainboard: Check if first boot: 1.
D (1965) PowerFeather::Mainboard: Set RTC pin 13 to 1.
D (1971) PowerFeather::Mainboard: EN detected as 1 during initialization
D (1977) PowerFeather::Mainboard: Initialized RTC pin 4 with mode 2.
D (1984) PowerFeather::Mainboard: Check if first boot: 1.
D (1989) PowerFeather::Mainboard: Set RTC pin 4 to 1.
D (1994) PowerFeather::Mainboard: 3V3 detected as 1 during initialization.
I (2001) gpio: GPIO[38]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
D (2011) PowerFeather::Mainboard: Initialized digital pin 38 with mode 1.
D (2018) PowerFeather::Mainboard: Initialization done.
D (2023) PowerFeather::Utils::Mutex: Mutex 0x3fca4514 released.

with Battery and no USB:

D (1519) PowerFeather::Utils::Mutex: Mutex 0x3fca4514 created.
D (1525) PowerFeather::Utils::Mutex: Mutex 0x3fca4514 take succeeded.
D (1531) PowerFeather::Mainboard: Battery capacity and type set to 1800 mAh, 0.
I (1539) PowerFeather::Mainboard: Termination current set to 180 mA.
D (1546) PowerFeather::Mainboard: Initialized RTC pin 14 with mode 2.
D (1552) PowerFeather::Mainboard: Check if first boot: 1.
D (1558) PowerFeather::Mainboard: Set RTC pin 14 to 1.
D (1563) PowerFeather::Mainboard: VSQT detected as 1 during initialization
D (1570) PowerFeather::Utils::MasterI2C: Start with port: 1, sda: 47, scl: 48, freq: 100000.
D (1578) intr_alloc: Connected src 43 to int 17 (cpu 0)
D (1584) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit1 on 1-byte register 16, value = 0001.
D (1593) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 16, value = 00a1.
D (1602) PowerFeather::Mainboard::BQ2562x: Write bit5 to bit5 on 1-byte register 16, value = 0081.
D (1611) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit15 on 2-byte register 06, value = 0a00.
D (1620) PowerFeather::Mainboard::BQ2562x: Write bit4 to bit11 on 2-byte register 06, value = 0640.
D (1629) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1a, value = 003d.
D (1638) PowerFeather::Mainboard::BQ2562x: Write bit7 to bit7 on 1-byte register 1a, value = 00bd.
D (1647) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 27, value = 0004.
D (1656) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit2 on 1-byte register 27, value = 0004.
D (1665) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit15 on 2-byte register 02, value = 0100.
D (1674) PowerFeather::Mainboard::BQ2562x: Write bit5 to bit10 on 2-byte register 02, value = 0020.
D (1683) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 18, value = 0004.
D (1692) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit2 on 1-byte register 18, value = 0000.
D (1701) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 18, value = 0000.
D (1710) PowerFeather::Mainboard::BQ2562x: Write bit3 to bit3 on 1-byte register 18, value = 0008.
D (1719) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 14, value = 0006.
D (1728) PowerFeather::Mainboard::BQ2562x: Write bit3 to bit4 on 1-byte register 14, value = 000e.
D (1737) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 19, value = 00c4.
D (1746) PowerFeather::Mainboard::BQ2562x: Write bit6 to bit7 on 1-byte register 19, value = 0044.
D (1755) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1b, value = 0025.
D (1764) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit4 on 1-byte register 1b, value = 0031.
D (1773) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1c, value = 003f.
D (1782) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit1 on 1-byte register 1c, value = 003e.
D (1791) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1c, value = 003e.
D (1800) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit3 on 1-byte register 1c, value = 003a.
D (1809) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1a, value = 00bd.
D (1818) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit1 on 1-byte register 1a, value = 00bd.
D (1827) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 1a, value = 00bd.
D (1836) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit3 on 1-byte register 1a, value = 00b5.
D (1845) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 23, value = 0000.
D (1854) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit7 on 1-byte register 23, value = 00ff.
D (1863) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 24, value = 0000.
D (1872) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit7 on 1-byte register 24, value = 00ff.
D (1881) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 25, value = 0000.
D (1890) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit7 on 1-byte register 25, value = 00ff.
D (1899) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit15 on 2-byte register 12, value = 0010.
D (1908) PowerFeather::Mainboard::BQ2562x: Write bit2 to bit7 on 2-byte register 12, value = 0090.
D (1917) PowerFeather::Mainboard::BQ2562x: Read bit0 to bit7 on 1-byte register 16, value = 0081.
D (1926) PowerFeather::Mainboard::BQ2562x: Write bit0 to bit1 on 1-byte register 16, value = 0080.
D (1934) PowerFeather::Mainboard: Charger IC initialized.
D (1941) PowerFeather::Mainboard::LC709204F: Read register 19 succeeded, crc: e1  value: 00c0
D (1948) PowerFeather::Mainboard::LC709204F: Write register 0b, crc: e8  value: 3737
D (1957) PowerFeather::Mainboard::LC709204F: Write register 12, crc: 67  value: 0000
D (1965) PowerFeather::Mainboard::LC709204F: Write register 1c, crc: c9  value: 000a
D (1973) PowerFeather::Mainboard::LC709204F: Write register 16, crc: cc  value: 0000
D (1980) PowerFeather::Mainboard::LC709204F: Write register 15, crc: 64  value: 0001
D (1989) PowerFeather::Mainboard::LC709204F: Read register 19 succeeded, crc: e1  value: 00c0
D (1996) PowerFeather::Mainboard::LC709204F: Write register 19, crc: d0  value: 0040
D (2005) PowerFeather::Mainboard: Fuel gauge initialized.
D (2009) PowerFeather::Mainboard: Initialized RTC pin 13 with mode 5.
D (2016) PowerFeather::Mainboard: Check if first boot: 1.
D (2021) PowerFeather::Mainboard: Set RTC pin 13 to 1.
D (2026) PowerFeather::Mainboard: EN detected as 1 during initialization
D (2033) PowerFeather::Mainboard: Initialized RTC pin 4 with mode 2.
D (2040) PowerFeather::Mainboard: Check if first boot: 1.
D (2045) PowerFeather::Mainboard: Set RTC pin 4 to 1.
D (2050) PowerFeather::Mainboard: 3V3 detected as 1 during initialization.
I (2057) gpio: GPIO[38]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
D (2067) PowerFeather::Mainboard: Initialized digital pin 38 with mode 1.
D (2073) PowerFeather::Mainboard: Initialization done.
D (2079) PowerFeather::Utils::Mutex: Mutex 0x3fca4514 released.

Hi @bfredo123 , is the 200 mA measured at the boost output (5V) or input (3.3V)? Because if it's in the boost output, the current drawn from the 3.3V regulator would be higher than 200 mA. Some napkin math:

3.3 V * x * 0.85 = 5 * 200 mA (assuming 0.85 boost regulator efficiency)
x = 356 mA drawn from 3.3 V regulator to output 5 V @ 200 mA

Couple that with the current spike from ESP32 startup and this might be the reason you might temporarily exceed 1 A rating of the regulator (I'm not sure though if you are waking the ESP32). Also, inductive loads like motors are a little bit tricky. From what I know they might require some significant startup current as well?

Is it possible to get the boost the supply from VBAT instead? In this case, you would have to add external circuitry to turn the loads on/off, though.

One more observation: if, after plugging the USB power (with the power supply plugged to BATP/BATN), I click the reset button, and then unplug the USB power

My impression is that it might be related to some transient spike in power consumption where the 3.3 V regulator is overloaded.

I have just tried: indeed, if I plug the boost Vin to BATP instead of the 3V3 pin, then it works. Only the "Enable" pin of the boost is plugged to the 3V3 pin.
I now have to check that there is not too much current leak in the boost.
Thank you!

Sorry, my answer right ahead is wrong: unfortunately, plugging the boost directly to BATP does NOT change anything! (it only changes if I plug it AFTER the startup, similarly to what I mentioned ahead, when unplugging the USB after startup, and then it works again).

It really looks like the issue happens at the 1st startup, when Board.init is called. It looks like some initializations are done differently whether the power comes from USB or Battery.

to provide more accurate information on power consumption: I have measured the overall current on BATP with a scope plugged on a resistor connected in series between the power supply and the PowerFeather. There are peaks, but the current never exceeds 300mA.

And anyway, if current peaks would be the cause for resets, it would also happen when the board is powered with USB, right?

Don't you think there is something in the init function related to the issue? I believe so because:

  • the only difference in code execution, is in this method, based on the battery management I2C devices (from what I read in the code of that method)
  • the problem seems to be linked to what happens at the startup, but not after (e.g., as mentioned above, if I unplug the USB after startup, things work fine, but if I unplug it during startup, then problems occur).

Many thanks again in advance for any insights/thoughts/recommendations!

One more thing: while going on measuring, I have put a 1.2 ohm resistor between the 3V3 pin and the loads, and guess what: that FIXES the problem!

I really don't understand what happens there, so if you can again share any comment, that would be great.

Actually, I have strange "pro cpu reset by JTAG" messages randomly, but it does not seem to impact my app. However I don't have any JTAG stuff connected. The USB is unplugged, I have a USB/UART decoder plugged to TX0, but that's all (and if I unplug it, then of course I will not be able to see whether that message still prints!).

    bfredo123

    1.2 ohm resistor between the 3V3 pin and the loads,

    This further reinforces my impression that it might be related to high spike in current consumption when the loads are turned on.

    You're right that if the 3.3 V regulator can't keep up with this spike, the reset should happen on both 5 V supply and "battery" (I put air quotes as you mentioned you are using a power supply in place of a battery, if I'm not mistaken).

    However, what if the source supplies itself are the difference - i.e. the 5 V can handle it but the 4.2 V "battery" can't? Are you able to test maybe another 4.2 V "battery" supply just to confirm?

    Looking at the code again, the only difference between battery-only and usb(or vdc)-only startup is the fuel gauge initialization, which is illustrated in the logs you posted:

    which shouldn't affect things much given it just basically just reads voltage level of the battery.


    Also, I forgot to mention this, but I recommend users not to configure so called "SDK" managed pins:
    https://docs.powerfeather.dev/#sdk-managed-fixed-io, and use the dedicated Board.enable3V3 functions (but as you mentioned, this is not available in the wake stub).

    I would recommend using the VBAT pin to power the loads, and choosing another RTC-capable pin to enable/disable the boost converter and/or the ULN2003A IC.

    Thank you very much for this.
    I thought the 3V3 power output pin was exactly intended to power loads in a controllable way.

    The thing is that:

    • what if I use VBAT and the device is only powered with USB, and has no battery (I would like it also work in this mode)? (it seems that VBAT does not consider USB)
    • I need 2x4 outputs to control 2 steppers, 2x1 inputs for digital sensors, and 1 touch pin. All have to be RTC because I used them in the wake stub. For some reason I can't manage to use GPIO17, so there are "only" 11 RTC pins left, and I do need 11. Thus, I would like to avoid using another pin to enable/disable the boost.

    I get your recommendation, but is there an issue if I set the 3V3 output by myself? (from what I understand the PowerFeather code does not do anything in the background, unless we explicitly call it, mostly from the app_main for init). I need to set it from the stub as you have pointed it.

    Back to the strange resets, I will make a test with a real battery, in addition to the DC power supply (I confirm you understood correctly: I am using a DC power supply in lieu of a real battery. It's a UNI-T UDP3305S-E capable of 3A on the 4.2V output I am using)

    Thank you again!

      I have just made 2 extra tests:

      • plugging a real LiPo battery (instead of a DC power supply) leads to the same results: without the 1.2 ohm resistor, the board resets in wake stub. (just to confirm/remind: the boost Vin and Enable pins are connected to the 3V3 power output of the PowerFeather). And with the resistor, it works fine (like with the DC power supply).

      • plugging the boost Vin on VBAT does not help: the board goes on rebooting as well. BTW I have also measured the VBAT voltage when there is no battery, but USB: it is about 4V.

      Sorry to say, but I still think this has to do with something happening during the init 🙂 I don't know what, and I agree it's strange by looking at the code, but again, if I change the wiring after the init, it works well (and with no resistor). OK, the resistor fixing the problem goes against this thinking, but I don't undersatnd either how a 1.2ohm resistor can fix the issue. Looks like black magic to me 🙂

      Still interested in any suggestion!! And thank you again!

      I thought the 3V3 power output pin was exactly intended to power loads in a controllable way.

      Yes, however, access to this should ideally be done through the Board.enable3V3 functions - hence the "sdk-managed pins" label. The sdk manages the state persistence of this pin through deep sleep. Though if you know what this entails - this should be alright.

      what if I use VBAT and the device is only powered with USB, and has no battery (I would like it also work in this mode)? (it seems that VBAT does not consider USB)

      Let me just repeat that BATP/BATN and VBAT are different. VBAT is powered from either VDC/USB/battery. If there is no battery present, it should output 3.7 V (down-regulated from either USB or VDC).

      I need 2x4 outputs to control 2 steppers, 2x1 inputs for digital sensors, and 1 touch pin. All have to be RTC because I used them in the wake stub. For some reason I can't manage to use GPIO17, so there are "only" 11 RTC pins left, and I do need 11. Thus, I would like to avoid using another pin to enable/disable the boost.

      What happens with IO17? Might it be some kind of thing with uint16_t? How are you accessing it?
      Even without IO17, based on the docs, there should be 12 other RTC pins (11 for your use case + 1 enable/disable)?

      bfredo123 g in the background, unless we explicitly call it, mostly from the app_main for init). I need to set it from the stub as you have pointed it.

      It's a UNI-T UDP3305S-E capable of 3A

      Hm, seems like a capable power supply, though. But the evidence so far screams to me a spike in current. Though, I don't think it would hurt to try.

      Thank you again! Please see above: I have made 2 further tests (I think our messages have crossed).

      Thanks for the explanation on VBAT (I ensure that I had just read the doc again before asking, but now I have just seen what you say in the "miscellaneous questions" which I overlooked).

      Re IO17: I don't remember, it was quite a while ago, but I will give it another ttry. However as you may read in my latest tests, using VBAT unfortunately does not help 🙁

      What I didn't mention is that I also plan to use GPIO15 and 16 for the 32kHz crystal.
      I was not able to use GPIO17 as RTC because it's not a TOUCHPAD GPIO, and thus I could not find which registers could control it (from the wake stub). But I have finally found a way thanks to the array below declared in esp/v5.1.4/esp-idf/components/soc/esp32s3/rtc_io_periph.c (I share it below in case it would save hours of research to others).

      [ But still, I am interested in finding a proper way to power the outputs without having this reset in the wake stub - as VBAT does not help unfortunately. ]

      //Reg,Mux,Fun,IE,Up,Down,Rtc_number
      const rtc_io_desc_t rtc_io_desc[SOC_RTCIO_PIN_COUNT] = {
          /*REG                    MUX select                    function select               Input enable                 Pullup                    Pulldown                  Sleep select                   Sleep input enable           Sleep output enable           PAD hold   Pad force hold              Mask of drive capability  Offset                    gpio number */
          {RTC_IO_TOUCH_PAD0_REG,  RTC_IO_TOUCH_PAD0_MUX_SEL_M,  RTC_IO_TOUCH_PAD0_FUN_SEL_S,  RTC_IO_TOUCH_PAD0_FUN_IE_M,  RTC_IO_TOUCH_PAD0_RUE_M,  RTC_IO_TOUCH_PAD0_RDE_M,  RTC_IO_TOUCH_PAD0_SLP_SEL_M,   RTC_IO_TOUCH_PAD0_SLP_IE_M,  RTC_IO_TOUCH_PAD0_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD0_HOLD_M,  RTC_IO_TOUCH_PAD0_DRV_V,  RTC_IO_TOUCH_PAD0_DRV_S,  RTCIO_CHANNEL_0_GPIO_NUM}, //0
          {RTC_IO_TOUCH_PAD1_REG,  RTC_IO_TOUCH_PAD1_MUX_SEL_M,  RTC_IO_TOUCH_PAD1_FUN_SEL_S,  RTC_IO_TOUCH_PAD1_FUN_IE_M,  RTC_IO_TOUCH_PAD1_RUE_M,  RTC_IO_TOUCH_PAD1_RDE_M,  RTC_IO_TOUCH_PAD1_SLP_SEL_M,   RTC_IO_TOUCH_PAD1_SLP_IE_M,  RTC_IO_TOUCH_PAD1_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD1_HOLD_M,  RTC_IO_TOUCH_PAD1_DRV_V,  RTC_IO_TOUCH_PAD1_DRV_S,  RTCIO_CHANNEL_1_GPIO_NUM}, //1
          {RTC_IO_TOUCH_PAD2_REG,  RTC_IO_TOUCH_PAD2_MUX_SEL_M,  RTC_IO_TOUCH_PAD2_FUN_SEL_S,  RTC_IO_TOUCH_PAD2_FUN_IE_M,  RTC_IO_TOUCH_PAD2_RUE_M,  RTC_IO_TOUCH_PAD2_RDE_M,  RTC_IO_TOUCH_PAD2_SLP_SEL_M,   RTC_IO_TOUCH_PAD2_SLP_IE_M,  RTC_IO_TOUCH_PAD2_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD2_HOLD_M,  RTC_IO_TOUCH_PAD2_DRV_V,  RTC_IO_TOUCH_PAD2_DRV_S,  RTCIO_CHANNEL_2_GPIO_NUM}, //2
          {RTC_IO_TOUCH_PAD3_REG,  RTC_IO_TOUCH_PAD3_MUX_SEL_M,  RTC_IO_TOUCH_PAD3_FUN_SEL_S,  RTC_IO_TOUCH_PAD3_FUN_IE_M,  RTC_IO_TOUCH_PAD3_RUE_M,  RTC_IO_TOUCH_PAD3_RDE_M,  RTC_IO_TOUCH_PAD3_SLP_SEL_M,   RTC_IO_TOUCH_PAD3_SLP_IE_M,  RTC_IO_TOUCH_PAD3_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD3_HOLD_M,  RTC_IO_TOUCH_PAD3_DRV_V,  RTC_IO_TOUCH_PAD3_DRV_S,  RTCIO_CHANNEL_3_GPIO_NUM}, //3
          {RTC_IO_TOUCH_PAD4_REG,  RTC_IO_TOUCH_PAD4_MUX_SEL_M,  RTC_IO_TOUCH_PAD4_FUN_SEL_S,  RTC_IO_TOUCH_PAD4_FUN_IE_M,  RTC_IO_TOUCH_PAD4_RUE_M,  RTC_IO_TOUCH_PAD4_RDE_M,  RTC_IO_TOUCH_PAD4_SLP_SEL_M,   RTC_IO_TOUCH_PAD4_SLP_IE_M,  RTC_IO_TOUCH_PAD4_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD4_HOLD_M,  RTC_IO_TOUCH_PAD4_DRV_V,  RTC_IO_TOUCH_PAD4_DRV_S,  RTCIO_CHANNEL_4_GPIO_NUM}, //4
          {RTC_IO_TOUCH_PAD5_REG,  RTC_IO_TOUCH_PAD5_MUX_SEL_M,  RTC_IO_TOUCH_PAD5_FUN_SEL_S,  RTC_IO_TOUCH_PAD5_FUN_IE_M,  RTC_IO_TOUCH_PAD5_RUE_M,  RTC_IO_TOUCH_PAD5_RDE_M,  RTC_IO_TOUCH_PAD5_SLP_SEL_M,   RTC_IO_TOUCH_PAD5_SLP_IE_M,  RTC_IO_TOUCH_PAD5_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD5_HOLD_M,  RTC_IO_TOUCH_PAD5_DRV_V,  RTC_IO_TOUCH_PAD5_DRV_S,  RTCIO_CHANNEL_5_GPIO_NUM}, //5
          {RTC_IO_TOUCH_PAD6_REG,  RTC_IO_TOUCH_PAD6_MUX_SEL_M,  RTC_IO_TOUCH_PAD6_FUN_SEL_S,  RTC_IO_TOUCH_PAD6_FUN_IE_M,  RTC_IO_TOUCH_PAD6_RUE_M,  RTC_IO_TOUCH_PAD6_RDE_M,  RTC_IO_TOUCH_PAD6_SLP_SEL_M,   RTC_IO_TOUCH_PAD6_SLP_IE_M,  RTC_IO_TOUCH_PAD6_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD6_HOLD_M,  RTC_IO_TOUCH_PAD6_DRV_V,  RTC_IO_TOUCH_PAD6_DRV_S,  RTCIO_CHANNEL_6_GPIO_NUM}, //6
          {RTC_IO_TOUCH_PAD7_REG,  RTC_IO_TOUCH_PAD7_MUX_SEL_M,  RTC_IO_TOUCH_PAD7_FUN_SEL_S,  RTC_IO_TOUCH_PAD7_FUN_IE_M,  RTC_IO_TOUCH_PAD7_RUE_M,  RTC_IO_TOUCH_PAD7_RDE_M,  RTC_IO_TOUCH_PAD7_SLP_SEL_M,   RTC_IO_TOUCH_PAD7_SLP_IE_M,  RTC_IO_TOUCH_PAD7_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD7_HOLD_M,  RTC_IO_TOUCH_PAD7_DRV_V,  RTC_IO_TOUCH_PAD7_DRV_S,  RTCIO_CHANNEL_7_GPIO_NUM}, //7
          {RTC_IO_TOUCH_PAD8_REG,  RTC_IO_TOUCH_PAD8_MUX_SEL_M,  RTC_IO_TOUCH_PAD8_FUN_SEL_S,  RTC_IO_TOUCH_PAD8_FUN_IE_M,  RTC_IO_TOUCH_PAD8_RUE_M,  RTC_IO_TOUCH_PAD8_RDE_M,  RTC_IO_TOUCH_PAD8_SLP_SEL_M,   RTC_IO_TOUCH_PAD8_SLP_IE_M,  RTC_IO_TOUCH_PAD8_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD8_HOLD_M,  RTC_IO_TOUCH_PAD8_DRV_V,  RTC_IO_TOUCH_PAD8_DRV_S,  RTCIO_CHANNEL_8_GPIO_NUM}, //8
          {RTC_IO_TOUCH_PAD9_REG,  RTC_IO_TOUCH_PAD9_MUX_SEL_M,  RTC_IO_TOUCH_PAD9_FUN_SEL_S,  RTC_IO_TOUCH_PAD9_FUN_IE_M,  RTC_IO_TOUCH_PAD9_RUE_M,  RTC_IO_TOUCH_PAD9_RDE_M,  RTC_IO_TOUCH_PAD9_SLP_SEL_M,   RTC_IO_TOUCH_PAD9_SLP_IE_M,  RTC_IO_TOUCH_PAD9_SLP_OE_M,   0,         RTC_CNTL_TOUCH_PAD9_HOLD_M,  RTC_IO_TOUCH_PAD9_DRV_V,  RTC_IO_TOUCH_PAD9_DRV_S,  RTCIO_CHANNEL_9_GPIO_NUM}, //9
          {RTC_IO_TOUCH_PAD10_REG, RTC_IO_TOUCH_PAD10_MUX_SEL_M, RTC_IO_TOUCH_PAD10_FUN_SEL_S, RTC_IO_TOUCH_PAD10_FUN_IE_M, RTC_IO_TOUCH_PAD10_RUE_M, RTC_IO_TOUCH_PAD10_RDE_M, RTC_IO_TOUCH_PAD10_SLP_SEL_M,  RTC_IO_TOUCH_PAD10_SLP_IE_M, RTC_IO_TOUCH_PAD10_SLP_OE_M,  0,         RTC_CNTL_TOUCH_PAD10_HOLD_M, RTC_IO_TOUCH_PAD10_DRV_V, RTC_IO_TOUCH_PAD10_DRV_S, RTCIO_CHANNEL_10_GPIO_NUM}, //10
          {RTC_IO_TOUCH_PAD11_REG, RTC_IO_TOUCH_PAD11_MUX_SEL_M, RTC_IO_TOUCH_PAD11_FUN_SEL_S, RTC_IO_TOUCH_PAD11_FUN_IE_M, RTC_IO_TOUCH_PAD11_RUE_M, RTC_IO_TOUCH_PAD11_RDE_M, RTC_IO_TOUCH_PAD11_SLP_SEL_M,  RTC_IO_TOUCH_PAD11_SLP_IE_M, RTC_IO_TOUCH_PAD11_SLP_OE_M,  0,         RTC_CNTL_TOUCH_PAD11_HOLD_M, RTC_IO_TOUCH_PAD11_DRV_V, RTC_IO_TOUCH_PAD11_DRV_S, RTCIO_CHANNEL_11_GPIO_NUM}, //11
          {RTC_IO_TOUCH_PAD12_REG, RTC_IO_TOUCH_PAD12_MUX_SEL_M, RTC_IO_TOUCH_PAD12_FUN_SEL_S, RTC_IO_TOUCH_PAD12_FUN_IE_M, RTC_IO_TOUCH_PAD12_RUE_M, RTC_IO_TOUCH_PAD12_RDE_M, RTC_IO_TOUCH_PAD12_SLP_SEL_M,  RTC_IO_TOUCH_PAD12_SLP_IE_M, RTC_IO_TOUCH_PAD12_SLP_OE_M,  0,         RTC_CNTL_TOUCH_PAD12_HOLD_M, RTC_IO_TOUCH_PAD12_DRV_V, RTC_IO_TOUCH_PAD12_DRV_S, RTCIO_CHANNEL_12_GPIO_NUM}, //12
          {RTC_IO_TOUCH_PAD13_REG, RTC_IO_TOUCH_PAD13_MUX_SEL_M, RTC_IO_TOUCH_PAD13_FUN_SEL_S, RTC_IO_TOUCH_PAD13_FUN_IE_M, RTC_IO_TOUCH_PAD13_RUE_M, RTC_IO_TOUCH_PAD13_RDE_M, RTC_IO_TOUCH_PAD13_SLP_SEL_M,  RTC_IO_TOUCH_PAD13_SLP_IE_M, RTC_IO_TOUCH_PAD13_SLP_OE_M,  0,         RTC_CNTL_TOUCH_PAD13_HOLD_M, RTC_IO_TOUCH_PAD13_DRV_V, RTC_IO_TOUCH_PAD13_DRV_S, RTCIO_CHANNEL_13_GPIO_NUM}, //13
          {RTC_IO_TOUCH_PAD14_REG, RTC_IO_TOUCH_PAD14_MUX_SEL_M, RTC_IO_TOUCH_PAD14_FUN_SEL_S, RTC_IO_TOUCH_PAD14_FUN_IE_M, RTC_IO_TOUCH_PAD14_RUE_M, RTC_IO_TOUCH_PAD14_RDE_M, RTC_IO_TOUCH_PAD14_SLP_SEL_M,  RTC_IO_TOUCH_PAD14_SLP_IE_M, RTC_IO_TOUCH_PAD14_SLP_OE_M,  0,         RTC_CNTL_TOUCH_PAD14_HOLD_M, RTC_IO_TOUCH_PAD14_DRV_V, RTC_IO_TOUCH_PAD14_DRV_S, RTCIO_CHANNEL_14_GPIO_NUM}, //14
          {RTC_IO_XTAL_32P_PAD_REG, RTC_IO_X32P_MUX_SEL_M,        RTC_IO_X32P_FUN_SEL_S,        RTC_IO_X32P_FUN_IE_M,        RTC_IO_X32P_RUE_M,        RTC_IO_X32P_RDE_M,        RTC_IO_X32P_SLP_SEL_M,         RTC_IO_X32P_SLP_IE_M,        RTC_IO_X32P_SLP_OE_M,         0,         RTC_CNTL_X32P_HOLD_M,        RTC_IO_X32P_DRV_V,        RTC_IO_X32P_DRV_S,        RTCIO_CHANNEL_15_GPIO_NUM}, //15
          {RTC_IO_XTAL_32N_PAD_REG, RTC_IO_X32N_MUX_SEL_M,        RTC_IO_X32N_FUN_SEL_S,        RTC_IO_X32N_FUN_IE_M,        RTC_IO_X32N_RUE_M,        RTC_IO_X32N_RDE_M,        RTC_IO_X32N_SLP_SEL_M,         RTC_IO_X32N_SLP_IE_M,        RTC_IO_X32N_SLP_OE_M,         0,         RTC_CNTL_X32N_HOLD_M,        RTC_IO_X32N_DRV_V,        RTC_IO_X32N_DRV_S,        RTCIO_CHANNEL_16_GPIO_NUM}, //16
          {RTC_IO_PAD_DAC1_REG,    RTC_IO_PDAC1_MUX_SEL_M,       RTC_IO_PDAC1_FUN_SEL_S,       RTC_IO_PDAC1_FUN_IE_M,       RTC_IO_PDAC1_RUE_M,       RTC_IO_PDAC1_RDE_M,       RTC_IO_PDAC1_SLP_SEL_M,        RTC_IO_PDAC1_SLP_IE_M,       RTC_IO_PDAC1_SLP_OE_M,        0,         RTC_CNTL_PDAC1_HOLD_M,       RTC_IO_PDAC1_DRV_V,       RTC_IO_PDAC1_DRV_S,       RTCIO_CHANNEL_17_GPIO_NUM}, //17
          {RTC_IO_PAD_DAC2_REG,    RTC_IO_PDAC2_MUX_SEL_M,       RTC_IO_PDAC2_FUN_SEL_S,       RTC_IO_PDAC2_FUN_IE_M,       RTC_IO_PDAC2_RUE_M,       RTC_IO_PDAC2_RDE_M,       RTC_IO_PDAC2_SLP_SEL_M,        RTC_IO_PDAC2_SLP_IE_M,       RTC_IO_PDAC2_SLP_OE_M,        0,         RTC_CNTL_PDAC2_HOLD_M,       RTC_IO_PDAC2_DRV_V,       RTC_IO_PDAC2_DRV_S,       RTCIO_CHANNEL_18_GPIO_NUM}, //18
          {RTC_IO_RTC_PAD19_REG,   RTC_IO_PAD19_MUX_SEL_M,       RTC_IO_PAD19_FUN_SEL_S,       RTC_IO_PAD19_FUN_IE_M,       RTC_IO_PAD19_RUE_M,       RTC_IO_PAD19_RDE_M,       RTC_IO_PAD19_SLP_SEL_M,        RTC_IO_PAD19_SLP_IE_M,       RTC_IO_PAD19_SLP_OE_M,        0,         RTC_CNTL_PAD19_HOLD_M,       RTC_IO_PAD19_DRV_V,       RTC_IO_PAD19_DRV_S,       RTCIO_CHANNEL_19_GPIO_NUM}, //19
          {RTC_IO_RTC_PAD20_REG,   RTC_IO_PAD20_MUX_SEL_M,       RTC_IO_PAD20_FUN_SEL_S,       RTC_IO_PAD20_FUN_IE_M,       RTC_IO_PAD20_RUE_M,       RTC_IO_PAD20_RDE_M,       RTC_IO_PAD20_SLP_SEL_M,        RTC_IO_PAD20_SLP_IE_M,       RTC_IO_PAD20_SLP_OE_M,        0,         RTC_CNTL_PAD20_HOLD_M,       RTC_IO_PAD20_DRV_V,       RTC_IO_PAD20_DRV_S,       RTCIO_CHANNEL_20_GPIO_NUM}, //20
          {RTC_IO_RTC_PAD21_REG,   RTC_IO_PAD21_MUX_SEL_M,       RTC_IO_PAD21_FUN_SEL_S,       RTC_IO_PAD21_FUN_IE_M,       RTC_IO_PAD21_RUE_M,       RTC_IO_PAD21_RDE_M,       RTC_IO_PAD21_SLP_SEL_M,        RTC_IO_PAD21_SLP_IE_M,       RTC_IO_PAD21_SLP_OE_M,        0,         RTC_CNTL_PAD21_HOLD_M,       RTC_IO_PAD21_DRV_V,       RTC_IO_PAD21_DRV_S,       RTCIO_CHANNEL_21_GPIO_NUM}, //21
      };

      This table is unfortunately not in RTC RAM, so I have created a clone in RTC RAM so that we can use it from the wake stub:

      RTC_DATA_ATTR const rtc_io_desc_t my_rtc_io_desc[22] = {
      ...

      Then, to set a pin "PIN" as RTC Output::

        REG_WRITE(my_rtc_io_desc[PIN].reg, my_rtc_io_desc[PIN].mux); 
        SET_PERI_REG_MASK(SENS_SAR_PERI_CLK_GATE_CONF_REG, SENS_IOMUX_CLK_EN_M); 
        REG_WRITE(RTC_GPIO_ENABLE_W1TS_REG, BIT(RTC_GPIO_ENABLE_W1TS_S + PIN)); 

      And to set PIN to value VAL:

        if(VAL) { 
          REG_WRITE(RTC_GPIO_OUT_W1TS_REG, BIT(RTC_GPIO_OUT_DATA_W1TS_S + PIN)); 
        } 
        else { 
          REG_WRITE(RTC_GPIO_OUT_W1TC_REG, BIT(RTC_GPIO_OUT_DATA_W1TC_S + PIN)); 
        } 
        CLEAR_PERI_REG_MASK(RTC_CNTL_PAD_HOLD_REG, BIT(PIN)); 
        SET_PERI_REG_MASK(RTC_CNTL_PAD_HOLD_REG, BIT(PIN));  

      A few notes to share the latest news:

      • The overall consumption finally is 20-22uA
      • with the touchpad added (to wake up the system when touched), it currently adds about 60uA, thus 82-84uA. I took the code from an ESP-IDF example. Maybe there are ways to improve this.
      • by adding a 32kHz cristal, it drops to 65-69uA

      Stopping using GPIO7/EN for my own needs seems to have helped reducing significantly the power consumption and the overall stability, as after reboot, the board init seems likely in a weird state (which makes sense if we change that pin status in its back).

      I am overall quite happy of this PowerFeather device, thank you again!!
      Still an unexplained mistery that there are reboots from wake stub 🙂 I am currently using a breadboard for the prototype, I hope the 1.2 ohm resistor will keep on fixing the problem on the final board!

      6 days later

      Hi,

      I still had some brownout resets. By switching WiFi off, and only keeping BLE improved significantly. But I still had strange re-inits (the RTC counter was not reset, but likely the app was reset. Hard to say as I have no ways of getting logs when everything is disconnected and embedded in the physical box.

      However I have tried to plug the 3.3V/5V Boost Vin pin to VBAT instead of 3V3 as you suggested, and it seems to work much better. To be confirmed over the time, but thanks!

      And I think there are a few bugs in the KiCad schematics of the PowerFeather board: VBAT is described as a power input, while it should be an output. And I also found another issue a few days ago, but don't remember which pin it was. Maybe 3V3. I had to manually edit the symbol in my schematics, but you might want to modify your KiCad file on GitHub (thanks btw for having made this available btw, invaluably helpful!!!)