Major Issue with Lilygo-T-A7670 on Battery: Everytime "Brownout detector was triggered" once connected on battery and devices get hanged and need manual reset

[farhanahmad-ese]

Dear Lilygo Team and Developers,

There is major issues in this board. Whenever tries to connect it with battery Li-Ion or Lipo every time it output "Brownout detector was triggered". I have disable brownout detection but our devices get failed/hanged on this stage. There are lot of devices we have procured and whole project has been messed up. When we have connected FTDI adapter to save log, this is the state when device get hangs anytime and we have to go for manual reset. There is lot of unreliability with this product. This log is just got by programming your own example MQTTClient without doing any change just connecting the module on battery.

rst:0x1 (POWERON_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:2
load:0x3fff0030,len:1184
load:0x40078000,len:13232
load:0x40080400,len:3028
entry 0x400805e4

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:2
load:0x3fff0030,len:1184
load:0x40078000,len:13232
load:0x40080400,len:3028
entry 0x400805e4
Start modem...
[6837] Initializing modem...
[6837] ### TinyGSM Version: 1.0.0
[6837] ### TinyGSM Compiled Module: TinyGsmClientA7670
[6897] ### Modem: A7670E-FASE
[6897] ### Modem: A7670E-FASE

[lewisxhe]

Is the battery reliable? Batteries with too small discharge current or poor quality cannot meet the needs of this board. According to the log you provided, the A7670 did not seem to start up during the first startup. Only the ESP was working at this time. The maximum instantaneous current of the ESP is about 700mA. Have you tried to replace the battery or test it directly with USB-C power supply?

[lewisxhe]

There is another problem, POWER ON (GPIO12) must be turned on when power is on, otherwise there is a chance of triggering a power-off reset.

[farhanahmad-ese]

Yes. The batteries are reliable. Yes, I have tried to power the board using USB-C connected through lipo battery charging circuit and the same battery was being used and there was no problem on brownout detection.

The problem occurs when you GPIO 12 is turned ON.

// Turn on DC boost to power on the modem

#ifdef BOARD_POWERON_PIN
  pinMode(BOARD_POWERON_PIN, OUTPUT);
  digitalWrite(BOARD_POWERON_PIN, HIGH);
#endif

This is the part of the code where the Brownout Detector Triggers.

[lewisxhe]

Did you enable GPIO12 at the very beginning of the setup function?

If you enable it after setup, it may cause power failure!

[farhanahmad-ese]

The Serial Log I have shared is from your examples "MQTT Client".

And facing issues. There is an issue with hardware. I am not sure if that could be resolve by using a capacitor to stabilized the voltage.

The hardware designer should not use GPIO 12 as this is strapping pin. He could have used any other GPIO.

[farhanahmad-ese]

Here is the battery voltage waveform captured using oscilloscope. The battery voltage is 4.0 and when modem tried to power up then it drop below 3.0 V

[lewisxhe]

This problem is a known issue and can only be solved by calling GOIO12 to set the high level at the beginning of setup. This problem has been discussed in another post.

#85

[farhanahmad-ese]

This problem is not solved. We have lot of devices now in field and they are getting hanged. It's fault of hardware designer who created mess for everyone who bought this module. We cannot afford high current consumption as devices are battery operated and remotely deployed.
It was your code where GPIO 12 was set high at beginning of setup but still exists.

[lewisxhe]

If that's the case, then there might really be something wrong with the board you have. How many boards have this problem?

[farhanahmad-ese]

Dear Lewisxhe,

We have 55 Lilygo T-7670A devices as pilot project. Just for information of Lilygo team, that we have Lilygo T3 S3 LoRaWAN based device that is under testing and we have to deploy 500 nodes as pilot. Later on, we have to install 1100 nodes at second stage.
Currently, we are losing trust on Lilygo devices and if Lilygo is not serious to solve the issue then there will be other options.

[lewisxhe]

55 boards all called GPIO12 SET HIGH during startup, which triggered ESP undervoltage reset? ?

[farhanahmad-ese]

I cannot check all board because most of them has been deployed in field. I have called GPIO12 HIGH during startup as the code snippet is given below:

void setup()
{
    // Turn on DC boost to power on the modem
#ifdef BOARD_POWERON_PIN
    pinMode(BOARD_POWERON_PIN, OUTPUT);
    digitalWrite(BOARD_POWERON_PIN, HIGH);
#endif
    // WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);
    Serial.begin(115200); // Start Serial communication for debugging
    while (!Serial)
    {
    } // Wait for Serial to be ready
    LOG_MESSAGE(millis(), "Serial Started at 115200kbps", "✔");

Furthermore, I have disabled brownout detection which ultimately resulted in ESP_RST_INT_WDT reset reason. Thus, nothing has worked.
I have 08 board with me in lab and they are problematic.
We have Lilygo T A7670E V1.2 2022-7-18. I have seen issue # 85 where you have suggested to remove a MOS. Now we want to try on our board. I am sharing picture of our board, please suggest which MOS to remove and which pins to short.

Furthermore, we have installed a ATTiny85 microcontroller with Lilygo module which resets Lilygo after specified interval as we do not have any other options to manually reset the devices in field.

[lewisxhe]

Please see the picture

Can you test this code by placing it in setup and then executing it later to keep the modem turned on immediately when booting?

[farhanahmad-ese]

Yes. I have removed the mentioned MOS and kept GPIO12 HIGH at start of void setup(). However, the current consumption reaches 600uA.

For now, Brownout detection is not triggering. However, we need to test if it gets hanged after long operation such as for days and weeks. Like like mentioned in Issue # 105

[lewisxhe]

OK. Waiting for your test results