TTGO T-Beam V1.0 & OLED & deep sleep needs proper power design

Here you can find more information concerning the different versions

2-3 mA is reported here:

and 600uA is reported there:

Tested:

With a T-BEAM v1.1 (with LORA chip HPD13 / SX1276), AXP192 in shutdown mode, LORA and GPS power cut off by AXP192, and a SSD1306 OLED connected to I2C pins and in sleep mode (because cutting off power of OLED would block i2c bus) i see

  • 1,2 mA battery current, if esp wakeup is set by GPIO
  • 0,9 mA battery current, if esp wakeup is set by timer
  • 40-50 ĀµA battery current, if esp is powered off by AXP192
1 Like

Thanks for your very clear feedback.
How do you wake-up once powered off by AXP192 ?

Wakeup can be triggered by ESP32 (using timer or GPIO button), or by AXP192 (using PEK button).

Unfortunately on TTTGO T-BEAM boards the I/O ports of the AXP192 chip are not connected to ESP32, thus a wakeup on GPIO triggered by AXP192 is not possible, what means that the sleep mode of AXP192 cannot be used.

Hi repherb,

I uploaded the sample script for the AXP192 chip from Github and bricked my TBEAM :frowning:
Luckily I noticed that if I held the PWR button down the red led would sometimes glow dimly. So I modified the code from Github and reflashed, setting the line 18 to ā€œ.DCDC3 = 3300ā€, which I think sets the power for the ESP32 to 3.3v instead of 0 in the default code.

Hope thats help someone. @roleohibachi pointed me in the right direction. That;ll teach me to blindly upload sample scripts :slight_smile:

ā€¦and never set it to values greater than 3300ā€¦

1 Like

Hello Neil,

I think i have the same problem. Starting the TBeam (v1.1) I get the red led for 1 second, and I think then the AXP chip goes into sleep again, losing all power. Oled goes dark, serial gets disconnected.

Do you have the code to reset this chep for the TBEAM?

Many thanks!!
Wouter

It does not need to be reset but it needs to be properly configured during startup of the node, which in your current sketch is not happening.

For a code example see LMIC-node file bsf_ttgo_t_beam_v1.h

I have a piece of code to initialize the AXP.

The problem I have is whenever I power the board. I only get 1 second off power (red light). It seems to remember it needs to go into deep sleep???

During this second I have serial over USB, but this is not long enough to upload my sketch. So I need to find another method to power or flash it.

Or maybe flash the sketch to another esp32 I have and interface with the axp?

Thanks!

Well, if the programmed sketch switches off power that will of course happen every time when you power up the board. Your issue appears related to the power management chip, not to deep sleep.

@neildotwilliams wrote:

Maybe the above helps.

When the ESP32 is put in programming mode the standard sketch programmed into the ESP32 will not run, instead it will wait for firmware upload.
If your board fails/drops power during upload then probably the upload has not yet started because once the upload has started it should not stop until the upload has completed.

You may try resetting your node just before uploading the firmware.
You may need to try several/many times.

Another option is to put the ESP32 manually into programming mode (connect GPIO0 to ground, press and release the reset button, then disconnect GPIO0 from ground again. The ESP32 is now in firmware upload mode.

From what Iā€™ve read in posts, the power management chip does not automatically store/restore its configuration (default values may be hard-coded but Iā€™m not sure).
If at power-up the power chip restores fixed configuration settings (coded into the chip?) then uploading any simple sketch (e.g. blink) should fix your problem.
If it does automatically store/restore itā€™s latest settings then you will need to upload a sketch that correctly configures the power management chip.

In both cases you can use/upload LMIC-node to fix the issue.

1 Like

I think I just got lucky by getting everything ready and timing things right holding the PWR button down while flashing. I remember it took a few attempts.

Flashing is not the problem, I can flash the ESP, but I only have 1 second until the AXP shuts power off.

Last upload went until 14% and then power loss. Now the ESP is corrupt, so I know it is not executing any commands. I can still flash it, but 1 second is to short and I cannot get past 14% in that short time.

So I need to have a way to wake the AXP again, or have another means to power the ESP so I can flash it fully.

Thanks for your help already.

Apparently flashing is a problem here.

As said, when the ESP32 is in programming mode it does not run the standard sketch so it will not execute any code that may alter configuration of (default) setting of the power chip.

Whether the power chip automatically stores/restores its latest used configuration settings I donā€™t know. You can check its data sheet for that.

You can also check the code that you previously uploaded (which caused the problems) to see what it does to the power management chip.

What IDE are you using Arduino IDE or PlatformIO?
What sketch are you trying to upload that fails?

Iā€™m using Arduino the make the sketch. Now I have a small sketch with only the AXP init code to turn everything on, to make it as small as possible.

I know it is corrupt because at first on boot i saw my oled start up and show the TTN logo. But after a second switch off. After my first tries to flash that got interrupted I lost the oled screen and donā€™t have output on the serial console.

When starting up I see a red light burning (IO4). this stops after 1 second and I loose the board.

To prove it is in flash mode, here is my output that Iā€™m able to get until it looses power.

C:\Users\Wouter Verstraeten\Documents\Arduino\Reset Axp\main>esptool.py --port COM6 write_flash 0x00000 main.ino.tbeam.bin
esptool.py v3.1
Serial port COM6
Connectingā€¦
Detecting chip typeā€¦ ESP32
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:0a:c4:f7:e6:84
Uploading stubā€¦
Running stubā€¦
Stub runningā€¦
Configuring flash sizeā€¦
Flash will be erased from 0x00000000 to 0x00035fffā€¦
Compressed 218992 bytes to 114259ā€¦
Writing at 0x00000000ā€¦ (14 %)
A fatal error occurred: Invalid head of packet (0x00).

At this fatal error, the red LED goes out and I loose the serial connection.

To start, I used this code: GitHub - kizniche/ttgo-tbeam-ttn-tracker: TTGO T-Beam Tracker for TTN Mapper and TTN Tracker using US (915 MHz) and EU (868 MHz) frequencies
Yesterday, all worked, left it on the charger but put the module in sleep mode by holding power for 8 seconds so it would not keep transmitting over night. In the morning I was not able to get it out sleep mode. Blue and red light were burning but no buttons were able to get is alive again. Removed battery and seated again and I had this problem. :frowning:

What do you mean by ā€˜holding powerā€™?
The T-Beam V1.0 has a sliding on/off switch, not a push button power switch like on the V1.1.

:man_facepalming: My mistake, only V0.x have sliding on/off switch (and no power management chip), V1.0 and V1.1 both have a push button power switch.

Have you checked the serial monitor for possible causes/error messages when starting up the device?
(First power up, connect serial monitor and then do some resets with the reset button to capture any output).

In worst case your hardware may have become defective.

I is a V1.1, is this a problem?

The output i get from serial is:
[14:27:52]rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[14:27:52]invalid header: 0x400d794c
[14:27:52]invalid header: 0x400d794c
[14:27:52]invalid header: 0x400d794c
[14:27:52]invalid header: 0x400d794c
[14:27:52]invalid header: 0x400d794c
[14:27:52]invalid header: 0x400d794c
[14:27:53]invalid header: 0x400d794c
[14:27:53]ets Jul 29 2019 12:21:46

Until after a second it loses the power.

@neildotwilliamsā€™ issue was related to uploading code that had a clear issue with incorrectly programming the power management chip.
Your problem started after switching the device off (or put in sleep) and then try to switch on again.
So apparently you do NOT have the same problem.

Indeed. At first I tought the program put the AXP in sleep mode.

But now I donā€™t think so anymore, because I donā€™t think anything is running anymore on the ESP.

Not that I know off. I use the same code to initialize the power chip for both V1.0 and V1.1.

Sorry, I missed your (v1.1) remark above.