ESP resets when USB disconnects while battery installed and charged

[FransOv]

The T-A7608 (https://www.lilygo.cc/products/t-a7608e-h)is powered via usb and the installed battery is charged. When the battery voltage reaches 4V I switch off the usb power to protect the battery from overcharging. When the usb power is disconnected the brownout detector is triggered and the ESP resets. Sometimes, not always, there then occurs a second reset and the ESP enters download mode although nothing is connected to GPIO0.

Brownout detector was triggered

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
ets Jul 29 2019 12:21:46

rst:0x10 (RTCWDT_RTC_RESET),boot:0x2 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_FEO_V2))
waiting for download

[Rikests]

This might be related to the other Brownout issue, where ESP32 brownouts when IO12 is pulled high to connect battery power to the modem. You can try adding a 220uA or bigger cap on ESP32 power pins and see if that helps.

[FransOv]

I tried with 1000 μF and with 2200 μF capacitor on the 3V3 rail, but the ESP32 still resets. Soldered an external pull-up resistor to GPIO0 to prevent resetting into download firmware mode. Now I have only the problem of a reset about every 20 to 24 hours. I suppose I can accept that.

[lewisxhe]

It seems to be caused by unstable power supply. Excessive capacitance may cause the DC power-on current to be very large and may be destroyed. 220uF may be a better choice.

If GPIO0 is not used, there is no need for an external pull-up resistor, because GPIO0 defaults to an internal pull-up.

[FransOv]

Same result with 220 μF capacitor. ESP still resets when usb power is disconnected. GPIO0 is not used in my setup. I know that GPIO0 has an internal pull-up resistor and in normal situations it will restart normally, but after the reset caused by disconnecting usb power it will 9 out of 10 times end up "Waiting for download". With the external pull-up it will always restart normally.

[github-actions[bot]]

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

[pacmac]

I have the same problem, every time the modem is powered on it gets a brownout. I have fully charged 18650 3200mah battery and alternatively supplying power via VBAT pin and a good quality power supply ever time the modem is powered on, from a powered off state, I get a brownout.

I added a 100uf cap and that made no difference, I see the comments above about 200uf, but this is obviously a design issue and right now the board is useless to me unless it can sleep and wake and power on and off the modem reliably.

Just to reiterate, this happens every time the modem is powered on, not just once every 24 hours.

[pacmac]

Yes this is a problem.

The power Pin must be set high at boot time, if you set it after boot you will get immediate brownout.

And this means that the modem must always be powered on when waking from deep sleep, this is a show stopper for me, that is just not viable.

I want to control when the modem comes on, it cannot come on every time after wakeup, that is totally impractical.

[pacmac]

Is there a solution to this ?

Whenever Power Pin is set high (GPIO12) the device brownouts no matter whether connected to battery or USB. Adding capacitors across the supply makes no difference at all.

At the moment I have 2 new boards and because of this they are unusable ??

Thanks

[lewisxhe]

@pacmac Hi, Do you mean that if you set GPIO12 after startup, the power will be cut off immediately? Are you using the T-A7670 ESP32 version?

[lewisxhe]

There is no problem with my test here

[pacmac]

I am using the T-A7608, it was delivered a week ago.

Yes, as soon as you enable GPIO12 high, it will force a brownout and device reset.

This happens every time the modem is enabled by setting GPIO12 high.

I have 2 boards, it happens the same to both of them, it is impossible to power on the modem without the ESP32 brownout and rebooting itself.

#define POW_PIN  (12)
pinMode(POW_PIN, OUTPUT);
digitalWrite(POW_PIN,HIGH);

Brownout detector was triggered

ets Jul 29 2019 12:21:46

rst:0x8 (TG1WDT_SYS_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0

[pacmac]

  #define BOARD                               "ESP32 Wrover Module"
  #define MON                                 Serial
  #define SIM                                 Serial1

  #define PWRKEY_PIN                          (4)
  #define MODEM_RESET_PIN                     (5)
  #define POW_PIN                             (12)
  #define MODEM_DTR_PIN                       (25)
  #define MODEM_TX_PIN                        (26)
  #define MODEM_RX_PIN                        (27)
  #define MODEM_RING_PIN                      (33)
  #define VBAT_PIN                            (35)

const int SER_BAUD =                          115200;

void setup() {

  // Serial Setup
  MON.begin(SER_BAUD);
  while(!MON){delay(100);} 
  MON.println("Serial Started");

  // SIM Serial
  SIM.begin(SER_BAUD, SERIAL_8N1, MODEM_RX_PIN, MODEM_TX_PIN);
  while(!SIM){delay(100);}

  delay(1000);
  pinMode(POW_PIN, OUTPUT);
  digitalWrite(POW_PIN,LOW);

}

void loop() {
  delay(2000);
  MON.println("Looping");
  digitalWrite(POW_PIN,HIGH);
}

Looping
Looping
Looping
Looping
Looping
Looping
xxxx�x�x�x���x��x�x��������x�x�x�xx�x���xLooping

Brownout detector was triggered

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964

[lewisxhe]

A7608 consumes more power than A7670. According to the log, it triggers esp32 low voltage reset.

Try the example I just uploaded and see if it has the same effect.

[pacmac]

what example ?

[lewisxhe]

https://github.com/Xinyuan-LilyGO/LilyGO-T-A76XX/commit/38c88d4b0315e36ea0f2fd6dc8c92bcd43723498

[pacmac]

FYI I am not using TinyGSM, I find it much too bloated.

But when I define the board before the include it errors:

#define LILYGO_T_A7608X
#include "utilities.h"
#include <TinyGsmClient.h>
#include "Arduino.h"

In file included from /Users/pac/Documents/Arduino/PAC/Sketches/Lily_tests/T1.ino:22:
/Users/pac/Documents/Arduino/libraries/TinyGSM/src/TinyGsmClient.h:118:2: error: #error "Please define GSM modem model"
 #error "Please define GSM modem model"

[lewisxhe]

Define it here . https://github.com/Xinyuan-LilyGO/LilyGO-T-A76XX/blob/c22ed0ed1210a83b7ecea7d3f726b03e5bf0a812/examples/ModemPowerOff/utilities.h#L30

[pacmac]

same error:

[pacmac]

why not just use a simple sketch like mine ?

[lewisxhe]

You are not using the fork version of TinyGSM, so the prompt is that the modem is not defined. The test method you used is correct. I will try it here too. Thank you for your cooperation

[lewisxhe]

This has nothing to do with the software. Did you connect the SIM card during the test?

[lewisxhe]

Is the SIM card normal? Can I access the network normally?

[lewisxhe]

If the network signal is poor, the A7608 will increase the power to search for the network, which may cause the board to lose power. Have you tested it by connecting the battery and USB at the same time?

[pacmac]

Sim Card is installed, everything works, I can publish MQTT messages no problem, but every time I power on the modem I get a brownout.

I have tried with fully charged 18650 as well as 5A Good Quality Bench supply, I am confident that this is not an issue with my setup.

[pacmac]

I also have SIM7600 and have no problems with that, using same SIM card and power supply, this appears to be an issue with the board ?

[lewisxhe]

Please take a video and send it to the salesperson for after-sales processing. This problem cannot be solved from the software side

[pacmac]

so you cannot replicate this issue using my sketch ?

[lewisxhe]

Yes, I use the same sketch and there will be no power outage here.

[pacmac]

have you tried connecting using VBAT and use a USB Serial adapter on TX/RX instead of using the USB-C connector ?

That is how I am testing as when the unit is deployed it will be battery powered and not powered via USB

[pacmac]

This happens the first time that the GPIO12 is pulled high after power was reconnected or a new sketch uploaded.

The loop in my sketch crashes the device the first time it is called, after the brownout and device reboots itself, but after reboot the device continues to loop when setting GPIO12 low and high:

void loop() {
  delay(2000);
  MON.println("Looping");
  digitalWrite(POW_PIN,HIGH);
  delay(2000);
  digitalWrite(POW_PIN,LOW);
}

Brownout ded ets Jul 29 2019 12:21:46

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3e (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid head�ets Jul 29 2019 12:21:46

rst:0x10 (RTCWDT_RTC_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Serial Started
Looping
Looping
Looping
Looping
Looping
Looping
Looping

[pacmac]

Just to confirm, this problem does not happen when powered by USB.

But if powered using fully charged 3200mah 18650 @4.2v, or by supplying power via the VBAT pin using a 5A Bench Power Supply, then the brownouts happen.

Can you please test using the same power method rather than using USB-C to test

Thanks

[lewisxhe]

I will run the test tomorrow and let you know the result tomorrow

[pacmac]

Thanks, I just connected a super cap across VBAT and Ground and it makes no difference, every time it bownouts;

This is my revised loop:

void loop() {
  delay(20000);
  MON.println("Power On");
  digitalWrite(POW_PIN,HIGH);
  delay(20000);
  MON.println("Power Off");
  digitalWrite(POW_PIN,LOW);
}

Brownout detector was triggered

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Serial Started
Power On

Brownout detector was triggered

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Serial Started
Power On

[lewisxhe]

Yes, I have the same problem here. The only way to solve it is to remove the MOS tube in the picture below and short-circuit the two points of the connection.

[pacmac]

well at least yiu can now see the problem I have been trying to troubleshoot for the last 4 days !

What if I leave the mosfet there and just short out the pins instead so it is easy to reverse if necessary ?

[pacmac]

is that mod going to increase deep sleep standby current ?

[pacmac]

That appears to have solved the problem, but will it affect power consumption ?

[lewisxhe]

Deep sleep power consumption is approximately 240uA

[pacmac]

OK, deep sleep current increases from 160ua to 440ua when I remove the mosfet and add this link.

That's just way too much, so another solution is needed.

Edit

Hmm, just disconnected and reconnected everything again and now its back to 160ua. I will continue to monitor.

Thanks

[pacmac]

That fix wont work as now the modem always powers on after Deep Sleep.

[lewisxhe]

Yes, I can confirm that after waking up from deep sleep, the modem starts automatically, I will give feedback to the designer who designed this PCB

[pacmac]

This is unworkable for anybody who requires long life on battery and who only enables the modem once in a while and not on every wakeup.

This is clearly a design defect and needs to be fixed with a hardware revision, I am not sure it can be fixed with a hack.

What is the process to get replacement boards when the issue is fixed with new hardware ?

Thanks for helping.

[lewisxhe]

I have found the problem. Please use this example to test, but the premise is that the two points of the MOS tube mentioned above must be short-circuited.

#include <Arduino.h>

#define uS_TO_S_FACTOR      1000000ULL  /* Conversion factor for micro seconds to seconds */
#define TIME_TO_SLEEP       30          /* Time ESP32 will go to sleep (in seconds) */

#define BOARD                               "ESP32 Wrover Module"
#define MON                                 Serial
#define SIM                                 Serial1

#define PWRKEY_PIN                          (4)
#define MODEM_RESET_PIN                     (5)
#define POW_PIN                             (12)
#define MODEM_DTR_PIN                       (25)
#define MODEM_TX_PIN                        (26)
#define MODEM_RX_PIN                        (27)
#define MODEM_RING_PIN                      (33)
#define VBAT_PIN                            (35)
#define MODEM_RESET_LEVEL                   HIGH

const int SER_BAUD =                          115200;

void setup()
{
    // Serial Setup
    MON.begin(SER_BAUD);
    while (!MON) {
        delay(100);
    }
    MON.println("Serial Started");

    // SIM Serial
    SIM.begin(SER_BAUD, SERIAL_8N1, MODEM_RX_PIN, MODEM_TX_PIN);
    while (!SIM) {
        delay(100);
    }

    if (esp_sleep_get_wakeup_cause() == ESP_SLEEP_WAKEUP_TIMER) {
        Serial.println("Wakeup timer");
        int i = 30;
        while (i > 0) {
            Serial.printf("Modem will start in %d seconds\n", i);
            Serial.flush();
            delay(1000);
            i--;
        }
        Serial.println("TurnON Modem!");
    }

    // Release reset GPIO hold
    gpio_hold_dis((gpio_num_t)MODEM_RESET_PIN);

    // Set modem reset pin ,reset modem
    // The module will also be started during reset.
    Serial.println("Set Reset Pin.");
    pinMode(MODEM_RESET_PIN, OUTPUT);
    digitalWrite(MODEM_RESET_PIN, !MODEM_RESET_LEVEL); delay(100);
    digitalWrite(MODEM_RESET_PIN, MODEM_RESET_LEVEL); delay(2600);
    digitalWrite(MODEM_RESET_PIN, !MODEM_RESET_LEVEL);

    Serial.println("Power on the modem");
    pinMode(PWRKEY_PIN, OUTPUT);
    digitalWrite(PWRKEY_PIN, LOW);
    delay(100);
    digitalWrite(PWRKEY_PIN, HIGH);
    //Ton >= 100 <= 500
    delay(300);
    digitalWrite(PWRKEY_PIN, LOW);

    delay(20000);

    // Power off modem
    Serial.println("Power off the modem");
    digitalWrite(PWRKEY_PIN, HIGH);
    delay(2000);
    digitalWrite(PWRKEY_PIN, LOW);

    delay(5000);

    Serial.println("Set Rset Pin hold low");
    // Keep it low during the sleep period. If the module uses GPIO5 as reset,
    // there will be a pulse when waking up from sleep that will cause the module to start directly.
    // https://github.com/Xinyuan-LilyGO/LilyGO-T-A76XX/issues/85
    digitalWrite(MODEM_RESET_PIN, !MODEM_RESET_LEVEL);
    gpio_hold_en((gpio_num_t)MODEM_RESET_PIN);
    gpio_deep_sleep_hold_en();

    Serial.println("Enter esp32 goto deepsleep!");
    esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);
    delay(200);
    esp_deep_sleep_start();
    Serial.println("This will never be printed");
}

void loop()
{
}

[pacmac]

I will try later, but if you short out the 2 pins then you cannot power off the modem, GPIO12 will always be HIGH.

Also, you have to sleep for 5 minutes, as it appears that the modem has capacitors that hold charge and if you sleep for such a short time you will not always see the problem.

[lewisxhe]

The current version cannot turn off the MODEM power supply, and can only be shut down through PWRKEY. If you want to keep the MOS tube, the problem will still occur.

[lewisxhe]

Sleep time does not affect it because it can be easily tested

[pacmac]

so your solution is to hold the MODEM reset pin high during sleep & release it on wakeup.

Wouldn't that also work on the POW_PIN ?

void simHoldReset(){
  digitalWrite(MODEM_RESET_PIN, LOW);           // Inverted High
  gpio_hold_en((gpio_num_t)MODEM_RESET_PIN);
  gpio_deep_sleep_hold_en();
}

void simReleaseReset(){
  gpio_hold_dis((gpio_num_t)MODEM_RESET_PIN);
}

[lewisxhe]

Yes, the same applies. But if you don’t remove the MOS, the power consumption may increase. You can try this. At present, I think the reliable solution is to maintain DC power supply and switch the power on and off through PWRKEY.

[pacmac]

The SIMCOM hardware manual says that the reset sequence is only required if the modem becomes unresponsive to the PWK KEY and it is not necessary to run that sequence every time to power on.

[github-actions[bot]]

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