Demo code bricks T-Beam 1.1

[roleohibachi]

Greetings.

I ran examples/AXP192.ino on my TTGO T-Beam v1.1, and the device turned off and could not be programmed. The example sketch puts the device in an unbootable state.

I recovered the device by using a Bus Pirate. The affected registers were:

10h (EXTEN & DC-DC2 Switch control register) - incorrectly set to 04h 12h (DC-DC1/3 & LDO2/3 Switch control register) - incorrectly set to 4dh 34h (Charge Control Register 2) - incorrectly set to 41h 35h (Charging the backup battery Control register) - incorrectly set to a2h

The correct initialization values for this device are: register 10h = 05h register 12h = 5fh register 34h = 61h register 35h = 22h

Or if you prefer, in bus pirate syntax:

[0x68 0x10 0x05]
[0x68 0x34 0x61]
[0x68 0x35 0x22]
[0x68 0x12 0x5f]

(note that I had to write 0x10 BEFORE 0x12, because "REG12Hbit6/4 corresponds to REG10Hbit2/0 respectively" per the datasheet)

Perhaps the example sketch should be modified to not write dangerous values by default! I think personally, it should not write any registers by default, and should only read them. Or perhaps read them, store the read value, and then write that same value back to the register as a demonstration of how to perform a write operation.

[ebbez]

Hi roleohibachi,

I am currently in the same boat as you were a few months ago. Thanks for documenting this as it is really helpful! I still have a question about the way you connected the bus pirate. Did you just connect the bus pirate to pin 21 (SDA) & 22 (SCL) of the LilyGO TTGO T-Beam? I currently also have no access to a bus pirate. Do you reckon this reconfiguration could be done with another ESP32 by connecting that ESP32's I2C wires to those of the T-Beam.

Thanks in advance, and thanks anyways for already posting this comprehensible yet advanced explanation!

[roleohibachi]

@Ebbez - happy to help.

You are correct on both counts. The T-Beam board SDA/SCL pins are connected directly to the AXP chip's SDA/SCL pins (and the ESP chip's as well - this is a "bus"). Also, you can absolutely perform the reconfiguration with any microcontroller that supports I2C.

You'll have to change the syntax a bit to suit your chosen I2C interface library. The AXP device address (68h), register addresses (10h,34h,25h,12h), and data contents (5h, 61h, etc) will stay the same. Using the Arduino IDE and Wire library, it might look like:

Wire.beginTransmission(0x68); Wire.write(0x10); Wire.write(0x05); Wire.endTransmission();

(no guarantees on that, I just freehanded it!)

[rickeho]

@roleohibachi Hello, I have just also tried running the demo code blindly and got my TTGO T-Beam module bricked as well. I have just purchased a bus pirate to fix my TTGO module and I have a few questions before I attempt to fix it.

How did you figure out which registers were affected and how did you know the correct initialization values for those registers? I looked at the datasheet at: http://www.x-powers.com/en.php/Info/support/article_id/29

and there were some default register values listed there that was not the same as the ones that you said was the correct values.

Also, what part of the demo code caused the register's data to be changed? Was it the demo code, or an inherent problem with the library files itself?

Thanks.

[rickeho]

I have fixed my TTGO T-Beam, by using a Raspberry PI and i2c-tools commands (i2cset), to set the registers' values. Thanks!

[roleohibachi]

Good work, @rickeho! The datasheet you linked is for the AXP chip itself, but remember that TTGO created their design around that chip, and as part of integration, changed the defaults. The values that the T-Beam ships with are different from the values that ship with a bare AXP192.

I had the benefit of a second T-Beam on hand to read the registers from :)

The library itself is not "broken", it is only the demo sketch (AXP192.ino) that should never be used with T-Beam boards. The 'I2C_AXP192_InitDef' that it uses does not match the default values on the board, and calling .begin() will write these erroneous values to the registers.

A better library design might allow for a non-modifying begin() which first reads out the current state of the chip's registers. However, a modified sketch which writes the correct values on startup would work just as well for our hobby purposes.

[tszolar]

I've managed to brick my T-Beam board as well by the example sketch.

The easiest solution how to revive it without any extra hardware is to:

1. disconnect the USB power
2. hold down reset button on the board
3. connect USB while holding reset
4. Run blank sketch upload and wait for the build log to show Connecting...,
5. Immediately release the reset button
6. Wait for the sketch to upload and flash

This approach will work because holding reset will keep the board in reset loop without actually starting the erroneous sketch and when the sketch flash will run, it will start the bootloader and not the actual sketch.

[donwade]

Ya. I got caught in the brick too. I noticed after applying power, the red power led would pop on for a sec then things went dead. But the serial port did report the reset reason, so I knew it could boot.

I made a script to run 'esptool --chip esp32 erase_flash' over and over while playing with the pwr and reset buttons.

The esptool eventually caught the brief window (where the red led comes on) and it nicely cleaned that flash and I'm back in business.

Has anyone modified this CODE to use better tbeam values or do I have to look at the bus pirate contributors to mod things up?