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

…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.

Maybe another path? Could the battery be defective and is the AXP shutting down that way?

Should is be able to run on only USB power? Because without battery I see the same problem.

You could try different USB cables. Sometimes (cable) connectors get bad, working in one situation but not in others. Even try a different USB port or a different computer if it possibly makes any difference.

I’ve had failing uploads in the past with one USB cable, while working with another USB cable of exactly the same model.

Does uploading to other ESP32 boards work without problems?

Maybe an issue with the USB connector on your T-Beam?

You may try powering the board separately, not via battery or USB port.
However, if the battery is sufficiently full it should work on battery only.
Have you checked battery voltage?

Battery voltage is about 4V, so I guess almost fully charged.

Flashing other esp work normally. Just was able to interface to the axp using another ESP32. Powering the board from the other esp and connecting the second ESP SDA and SCL ports to the TBEAM.

I got this output from the second esp:
[14:42:32]Starting !
[14:42:32]I2C device found at address 0x34 !
[14:42:32]axp192 PMU found
[14:42:32]done
[14:42:32]
[14:42:32]AXP192 Begin PASS
[14:42:32]DCDC1: ENABLE
[14:42:32]DCDC2: ENABLE
[14:42:32]LDO2: ENABLE
[14:42:32]LDO3: ENABLE
[14:42:32]DCDC3: ENABLE
[14:42:32]Exten: ENABLE
[14:42:32]----------------------------------------

So I guess the AXP is on. :frowning: that means there is still another problem :frowning:

Also the reset and other buttons don’t do anything. The only option is to remove power and add it again.

I just found something, put the module asside for a while, came back and saw the light was back on???

Could is be that the battery Voltage is to high? And now when lowered a bit is starts again? Problem is, put is on my pc and esp was still in bootloop from bad flash. But after a few seconds light went out again, maybe battery voltage back to high from usb power?

Very strange, will see if I can use the battery for something else to put some load on it…

:slight_smile:

Keep you posted

EDIT:

Saw it come online, stayed online like a minute and back offline. Could this be some kind off timer function???

EDIT 2: Just did it again, put my stopwatch against it. :slight_smile:
EDIT 3: Nope, completely random, already 45 minutes, nothing, before was 2 times in 30 minutes that it came back :frowning:

One of my T-beams V1.0 shows a similar behaviour. I am running the software of kizniche on two of them without any problems.
But the third one can most of the time not be startet by pushing the ON-button for abt. 4 seconds. It can only be startet by connecting the power supply to the USB-port.
I can switch it off by pushing the ON-button for abt. 8 seconds. But then, after some time, it starts again and continues until the battery is drained. The time can be between minutes and some hours.

Sadly I’d mention that of the half a dozen TTGO’s I have, only two or three (it’s a bit hard to tell) work as advertised. They all do something useful but I do chase my tail trying to figure out which version a board is and which bits are working correctly.

My gut feeling is the AXP chip is the bit that needs taming or removing!