Enabling BAT(IO12) causing brown out

[scsPEp]

Hello, I am currently using the T-A7670E V1.2 and I am facing the problem that the supply voltage takes a big dip when I enable the signal BAT(IO12), which causes the ESP to brown out. After the brown out reset enabling the signal will work, as the capacitors are already charged then. At least that is my guess. Is this a known problem?

The problems stays the same when using a 5A power supply instead of a battery.

This is annoying to me, as my device is most of the time in deep sleep to save energy, and should enable the modem only on some wake ups. I am using the RTC memory to keep some information between wake ups, but everytime I want to turn on the modem a brown out happens at least once and I lose the RTC memory.

[HDC67]

I don't seem to have this issue when powered by just the USB using the example modem application.

Do you have a minimum code example the demonstrates the problem?

[scsPEp]

If you power the device via USB the BAT signal will always be active, this can be seen on page 3 of the schematic, in the bottom right corner. VBUS is used parallel to IO12. So I do think there should also be a dip on the voltage, but only once when you plug in the device. As long as the BAT signal is switched on this problem should not happen again. But using a battery and keeping IO12 on during deep sleep will drastically increase battery consumption from what I have seen. The following measuring was taken while switch on the BAT signal. The blue signal is IO12 used to switch on BAT, the yellow signal is VDD3V3. Red signal is IO4 to switch PWRKEY and the green signal is IO5 to control modem RESET. As you can see, as soon as IO12 goes to high there is a dip, This measurement did work without a brown out, but usually the voltage will dip enough to cause a brown out.

[HDC67]

Right you are. That's pretty bad then though if it's enough to brown out the ESP32. It basically means it's difficult to power up the modem on battery.

I haven't really had much chance to play with mine but I think I also did have it running on an 18650 and then going to deep sleep including turning off IO12 then waking up and turning the modem on. I didn't measure the ESP32 supply when doing that so it may have been dipping like yours but not enough to cause a brown out.

[scsPEp]

I do think it can also be easily missable if you are not using something like the RTC memory or connect a terminal to the UART and enable debug output, as it will start up after 1 or more brown out cycles. I started to wonder when I was receiving 0 on values stored in RTC memory which should not be 0 after the deep sleep, as they should be set to something else from the previous wake cycle. Right now I changed my implementation to use NVS instead of RTC memory to keep those values, but this problem still is annoying, as needing multiple boots after wake up also consumes more battery.

[neuralprocessing]

Hi - I am using the same T-A7670E V1.2. The RTC Memory on my side is not being deleted (boot count is incremented properly), so the deep sleep and wake do not seem to burn out the esp32. I was using a slightly modified version of this: https://randomnerdtutorials.com/esp32-external-wake-up-deep-sleep/

[scsPEp]

Hi, are you using the modem in your examples? On my device using the deep sleep and wake up on it's own is also working fine. When I enable the modem supply via IO12 my device goes into brown out. Most likely because of the capacities connected to the modem on the supply pin. Is this also working for you without a problem?

[neuralprocessing]

Yes - I am using the modem. I send myself back the boot number and the reason for wake up. BAT_EN 12 pulled to HIGH on startup.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[Rikests]

I have 14 T-A7670E boards. There are a few that do not brown out when I pull IO12 high, some brown out often, and some that brown out every time. I tried disabling brownout detection, but that often caused the ESP32 to hang and become unresponsive until battery dies. Now I turn on the IO12 at the start of the setup{} and soldered a cap on ESP32 power pin. This seems to work better, but some of the boards still brown out sometimes. I will do more testing to see how to improve this situation, but I really hoped LilyGO would not have such basic issues as power delivery. Update: I added another cap 440uF parallel to the battery and a bit of code to load the modem power caps somewhat gradually without causing esp brownouts.

//MODEM startup sequence on BAT power
delay(300); //Wait for other system capacitors to load
int ModemOnTime[5] = {2, 5, 10, 20, 20}; //Power pulse time that charge modem caps
printf("\nModem init:");
for (int i = 0; i < 5; i++) {
  initModemPower();
  delayMicroseconds(ModemOnTime[i]);
  disableModemPower();
  printf(" %d(%dus)", i, ModemOnTime[i]);
  delay(60);
}
initModemPower();

Have not had any brownouts since I added these 2caps and this code.