markqvist / RNode_Firmware

RNode is an open, free and flexible digital radio interface with many uses
https://unsigned.io/rnode
GNU General Public License v3.0
145 stars 52 forks source link

LilyGO T-Beam Won't Boot After Losing Power #52

Closed iqw1345 closed 4 months ago

iqw1345 commented 7 months ago

After flashing the latest firmware onto the LilyGo T-Beam, everything appears to work correctly. After power loss, the device doesn't seem to boot up at all. rnodeconf classifies as missing.

The only way I've been able to recover it is to go to https://flasher.meshtastic.org and reset the device. Afterwards, RNode appears with Hardware Failure. Flashing LilyGO LoRa32 v2.1 fixes that issue. The only difference I've noticed between the two firmwares is that the battery icon doesn't work.

markqvist commented 7 months ago

Thanks for reporting it. Can you provide some more detail on what "losing power" means? As in, running out of battery, or just disconnecting the power cable?

It would also be helpful if you can post the output of rnodeconf --info /dev/YOUR_DEVICE_PORT. Thanks!

iqw1345 commented 7 months ago

Just by disconnecting the power cable with no battery connected.

[23:30:09] Opening serial port /dev/ttyACM1...
[23:30:12] Device connected
[23:30:12] Current firmware version: 1.68
[23:30:12] Reading EEPROM...
[23:30:13] EEPROM checksum correct
[23:30:13] Device signature validated
[23:30:13] 
[23:30:13] Device info:
[23:30:13]      Product            : LilyGO T-Beam 850 - 950 MHz (e0:e9:33)
[23:30:13]      Device signature   : Validated - Local signature
[23:30:13]      Firmware version   : 1.68
[23:30:13]      Hardware revision  : 1
[23:30:13]      Serial number      : 00:00:00:17
[23:30:13]      Frequency range    : 850.0 MHz - 950.0 MHz
[23:30:13]      Max TX power       : 17 dBm
[23:30:13]      Manufactured       : 2023-12-15 23:29:37
[23:30:13]      Device mode        : Normal (host-controlled)

I flashed this moments ago and it won't boot after the power cable is removed. Please let me know if any additional information is needed.

faragher commented 7 months ago

It lists the checksum and signature as correct, so I'm beginning to wonder if it's actually not an EEPROM issue. You can dump the EEPROM and run it through this: https://github.com/faragher/RNodeEEPROMView/tree/main or you can dump it and check it against one that's working just after you flashed it. If it's reporting the same information, then I'll have to change where I'm investigating.

I ordered a T-Beam, so some time next week I can start doing hands-on testing, if you don't find a solution prior to that.

assada commented 7 months ago

Same issue after announce node in nomadnet.

Parsed EEPROM dump:

python ./Parse.py 
Dump length: 200 (expected 200)
Product: TBeam
Model: 0xe4
420 - 520 MHz rnode_firmware_tbeam.zip
HW Revision: 0x1
Serial: 00000002
Made: 15Dec2023, 23:55:32 
Stored Checksum:    9df102b22d422a13bd00acf34c5c7b3e
Generated Checksum: 9df102b22d422a13bd00acf34c5c7b3e
Signature: 714a11e4616328b0b4f07784e2460f43d7480978e49d11c283894b5c458ef07e2d0f380d0f469dedb0e1c83710a8518b68f070e8fb9d9a9855845b7d29089afe59a8c94e7d6741c6299cbc0fcdfcbe9532495857a00947267cb74a4d9bf2e1d04724a79ef6159a7cece6bf3ee6d804c878a2f9910e14dc596d35a3b018d3714f
Info Lock: 0x73
SF: 0xff
CR: 0xff
TXP: 0xff
BW: ffffffff
Freq: ffffffff
OK: 0xff
BT: 0xff
DSET: 0x73
DINT: 0xff
DADR: 0xff
UT3UMS commented 7 months ago
[2023-12-16 22:29:47] [Verbose] Attempting to reconnect serial port /dev/ttyACM0 for RNodeInterface[RNode LoRa Interface]...
[2023-12-16 22:29:47] [Notice] Opening serial port /dev/ttyACM0...
[2023-12-16 22:29:49] [Notice] Serial port /dev/ttyACM0 is now open
[2023-12-16 22:29:49] [Verbose] Configuring RNode interface...
[2023-12-16 22:29:49] [Verbose] Waiting for radio configuration validation for RNodeInterface[RNode LoRa Interface]...
[2023-12-16 22:29:49] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting frequency is 443.0 MHz
[2023-12-16 22:29:49] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting bandwidth is 125.0 KHz
[2023-12-16 22:29:49] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting TX power is 3 dBm
[2023-12-16 22:29:49] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting spreading factor is 8
[2023-12-16 22:29:49] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting coding rate is 5
[2023-12-16 22:29:49] [Verbose] RNodeInterface[RNode LoRa Interface] On-air bitrate is now 3.12 kbps
[2023-12-16 22:29:49] [Debug] RNodeInterface[RNode LoRa Interface] Radio reporting state is offline
[2023-12-16 22:29:50] [Error] Radio state mismatch
[2023-12-16 22:29:50] [Error] After configuring RNodeInterface[RNode LoRa Interface], the reported radio parameters did not match your configuration.
[2023-12-16 22:29:50] [Error] Make sure that your hardware actually supports the parameters specified in the configuration
[2023-12-16 22:29:50] [Error] Aborting RNode startup

rnsd -vvv log while connecting to "radio not found" RNode

faragher commented 7 months ago

EDIT: This appears to be entirely a red herring, and the problem is likely a power controller issue.

I have dumped the LoRa registers from a non-functional build. I will begin parsing them shortly, but here's the raw data:

0x0: 0x16
0x1: 0x81
0x2: 0x1A
0x3: 0xB
0x4: 0x0
0x5: 0x52
0x6: 0xE4
0x7: 0xC0
0x8: 0x0
0x9: 0x8F
0xA: 0x9
0xB: 0x2B
0xC: 0x23
0xD: 0x1
0xE: 0x0
0xF: 0x0
0x10: 0x0
0x11: 0x0
0x12: 0x0
0x13: 0x0
0x14: 0x0
0x15: 0x0
0x16: 0x0
0x17: 0x0
0x18: 0x10
0x19: 0x0
0x1A: 0x0
0x1B: 0x0
0x1C: 0x0
0x1D: 0x72
0x1E: 0x70
0x1F: 0x64
0x20: 0x0
0x21: 0x8
0x22: 0x1
0x23: 0xFF
0x24: 0x0
0x25: 0x0
0x26: 0x4
0x27: 0x0
0x28: 0x0
0x29: 0x0
0x2A: 0x0
0x2B: 0x0
0x2C: 0x0
0x2D: 0x50
0x2E: 0x14
0x2F: 0x45
0x30: 0x55
0x31: 0xC3
0x32: 0x5
0x33: 0x27
0x34: 0x1C
0x35: 0xA
0x36: 0x3
0x37: 0xA
0x38: 0x42
0x39: 0x12
0x3A: 0x49
0x3B: 0x1D
0x3C: 0x0
0x3D: 0xAF
0x3E: 0x0
0x3F: 0x0
0x40: 0x0
0x41: 0x0
0x42: 0x12
0x43: 0x24
0x44: 0x2D
0x45: 0x0
0x46: 0x3
0x47: 0x0
0x48: 0x4
0x49: 0x23
0x4A: 0x0
0x4B: 0x9
0x4C: 0x5
0x4D: 0x84
0x4E: 0x32
0x4F: 0x2B
0x50: 0x14
0x51: 0x0
0x52: 0x0
0x53: 0x10
0x54: 0x0
0x55: 0x0
0x56: 0x0
0x57: 0xF
0x58: 0xE0
0x59: 0x0
0x5A: 0xC
0x5B: 0x0
0x5C: 0x8
0x5D: 0x0
0x5E: 0x5C
0x5F: 0x78
0x60: 0x0
0x61: 0x1C
0x62: 0xE
0x63: 0x5B
0x64: 0xCC
0x65: 0x0
0x66: 0x1
0x67: 0x50
0x68: 0x0
0x69: 0x0
0x6A: 0x0
0x6B: 0x0
0x6C: 0x0
0x6D: 0x0
0x6E: 0x0
0x6F: 0xB
0x70: 0xD0
0x71: 0x0
0x72: 0x13
0x73: 0x0
0x74: 0x0
0x75: 0x0
0x76: 0x0
0x77: 0x0
0x78: 0x0
0x79: 0x0
0x7A: 0x0
0x7B: 0x0
0x7C: 0x0
0x7D: 0x0
0x7E: 0x0
0x7F: 0x0

Edit:

Bear in mind some of this may be from the test application's initialization.

faragher commented 7 months ago

While it sounds like a fix is in the pipe, the issue appears to be based on the AXP2101 not being supported by the current library,

For reference, from https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/blob/master/schematic/LilyGo_TBeam_V1.2.pdf :

ALDO2: LoRa Chip ALDO3: GPS

I'm not sure any of the other power outputs are actually in use.

markqvist commented 6 months ago

Is my understanding correct, that this currently seems to be stemming from some T-Beams now using a new PMU chip (AXP2101)?

In that case, we will need a way to differentiate between the different models (a new board/model code) in the firmware, and include (a hopefully already existing) driver for the PMU chip.

assada commented 6 months ago

I have a TBeam_V1.1 with an axp192 chip, experiencing the same issues as described above. board marked as TBeam_V1.1 , but with AXP2101..

markqvist commented 5 months ago

Just tagging #53 to keep track of this one

markqvist commented 4 months ago

This was included and released in 1.70.

Assuming issue is fixed, but would love to hear confirmation from anyone who can test it.

iqw1345 commented 4 months ago

Yes, it's fixed. Thank you!

markqvist commented 4 months ago

Awesome to hear! Thank you!