T-Beam Supreme V3 OLED Display is not showing information

[derSuessmann]

Problem description

After installing the companion firmware v1.15.0 on a Lilygo T-Beam Supreme ESP32-S3 V3.0 the display stays dark.

The device came originally with Meshtastic preinstalled. It showed the Meshtastic information on its OLED display. Installing MeshCore Companion Bluetooth from https://flasher.meshcore.io/lilygo-t-beam-supreme-sx1262/ seemed to work, but the OLED display stays dark after rebooting.

Analysis

Lilygo's documentation at https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/blob/master/docs/en/t_beam_supreme/t_beam_supreme_hw.md states that the OLED has a another I2C address (0x3D instead of 0x3C), if the device has a MAG sensor QMC6310N at 0x3C.

Proposed solution

Extend the code to include 0x3D as I2C address.

1. change bool SH1106Display::begin() similar to the proposal in Display Fix for different versions of TBeam Supreme #2591, but extending bool SH1106Display::i2c_probe(TwoWire &wire, uint8_t addr) to probe for a SH1106 at the probed address instead.
2. remove DISPLAY_ADDRESS completely. This will also affect the code of wio-tracker-l1.
3. change void TBeamBoard::scanDevices(TwoWire *w) to add the additional address for debugging.

The best solution seems to check if at 0x3C is a SH1106 and try 0x3D, if it is not.

Please advise me, if I should just add another variant (e.g. lilygo_tbeam_supreme_SX1262_v3).

[falkowickbold-ctrl]

I got the same display problem with my TBeam supreme sc1262.

[tblake84]

We need a resolution on this issue. Is there any feedback or available fix yet?

[UltimateCodeWarrior]

T-Beam Supreme V3: OLED stays dark — root cause + fix

Re: #2609 (and related #2591)

Affected hardware: LilyGo T-Beam Supreme V3 (ESP32-S3 + SX1262, SH1106 1.3" OLED, AXP2101 PMU)
Firmware: built from main (reproduced on the T_Beam_S3_Supreme_SX1262_repeater env; the companion envs share the same SH1106Display/TBeamBoard code paths)
Symptom: Device boots and operates normally (CLI/BLE work), but the OLED never lights up. The board shipped with Meshtastic, whose OLED worked fine, so the panel/hardware is good.

TL;DR

On the Supreme V3 there are two independent problems, and you need both fixes:

1. The OLED I2C bus (Wire) is never initialized. On the Supreme the PMU/RTC live on Wire1 (GPIO 42/41, brought up by XPowersLib). The OLED + BME280 + magnetometer live on the primary Wire bus (GPIO 17/18), but nothing ever calls Wire.begin() for it, so Adafruit_SH110X talks on the wrong (default) pins.
2. The OLED is at I2C address 0x3D, not 0x3C. On this board 0x3C is taken by the QMC6310 magnetometer, so the panel was moved to 0x3D (confirmed by LilyGo's hardware docs). SH1106Display::begin() only ever tries DISPLAY_ADDRESS (0x3C), so it never finds the display.

Evidence

After initializing Wire on GPIO 17/18 and scanning the bus at boot:

OLED: I2C scan -> 0x3C 0x3D 0x77
OLED: initialised at 0x3D

• 0x3C = QMC6310 magnetometer
• 0x3D = SH1106 OLED
• 0x77 = BME280

With the stock code, begin() probes 0x3C (the magnetometer), fails to drive a real display, and the screen stays dark.

Fix

1. Bring up the OLED I2C bus — src/helpers/esp32/TBeamBoard.cpp

 void TBeamBoard::begin() {

     ESP32Board::begin();

+#ifdef TBEAM_SUPREME_SX1262
+    // On the T-Beam S3 Supreme the PMU + RTC sit on Wire1 (GPIO 42/41, brought
+    // up by XPowersLib), while the SH1106 OLED (0x3D) and the BME280/QMC6310
+    // sensors sit on the primary bus, Wire (GPIO PIN_BOARD_SDA/PIN_BOARD_SCL).
+    // Nothing else initialises Wire on this board, so the display driver would
+    // otherwise talk on the wrong (default) pins and display.begin() fails,
+    // leaving the screen blank. Bring the OLED bus up here.
+    Wire.begin(PIN_BOARD_SDA, PIN_BOARD_SCL);
+#endif
+
     power_init();

(PIN_BOARD_SDA=17 / PIN_BOARD_SCL=18 are already defined in the Supreme env's build_flags.)

2. Probe the correct OLED address — src/helpers/ui/SH1106Display.cpp

 bool SH1106Display::begin()
 {
-  return display.begin(DISPLAY_ADDRESS, true) && i2c_probe(Wire, DISPLAY_ADDRESS);
+  // Address selection: on some board revisions (notably the LilyGo T-Beam
+  // Supreme V3) the OLED lives at 0x3D because 0x3C is occupied by a
+  // magnetometer (QMC6310N). 0x3D is only ever used by the OLED, so prefer it
+  // when present, otherwise fall back to the standard 0x3C.
+  uint8_t addr = 0;
+  if (i2c_probe(Wire, 0x3D)) {
+    addr = 0x3D;
+  } else if (i2c_probe(Wire, DISPLAY_ADDRESS)) {
+    addr = DISPLAY_ADDRESS;
+  }
+  return addr && display.begin(addr, true);
 }

Preferring 0x3D (rather than just adding it to a list) avoids the false-positive where 0x3C ACKs because of the magnetometer. 0x3D is only ever the OLED, so its presence is an unambiguous signal.

Notes

• This is a clean, backwards-compatible change: boards with the OLED at the standard 0x3C (and no device at 0x3D) still fall through to 0x3C.
• The same 0x3C/0x3D ambiguity is called out for wio-tracker-l1 in the issue thread; the address-probe change above covers it too.
• Suggestion for maintainers: either land the auto-probe in SH1106Display::begin(), or add a dedicated lilygo_tbeam_supreme_SX1262_v3 variant. The auto-probe is preferable since it's a single code path that "just works" across both board revisions without users having to know which one they have.
• A no-op but helpful addition: have TBeamBoard::scanDevices() (under MESH_DEBUG) also recognize 0x3D as a display so the scan log labels it correctly.

Repro / verification

pio run -e T_Beam_S3_Supreme_SX1262_repeater -t upload

Boot log shows OLED: initialised at 0x3D and the panel renders the boot logo + home screen.

[UltimateCodeWarrior]

Opened #2815 with a fix. Two parts, both needed on the Supreme V3:

1. The primary I2C bus (Wire, GPIO 17/18) that the OLED/BME280/magnetometer share is never initialized (only Wire1 for the PMU/RTC is), so the display driver talks on the wrong pins.
2. The OLED is at 0x3D (because 0x3C is the QMC6310 magnetometer), but SH1106Display::begin() only tried 0x3C.

The PR brings up Wire for TBEAM_SUPREME_SX1262 and makes begin() prefer 0x3D (only the OLED uses it) before falling back to 0x3C. Backwards-compatible for standard 0x3C boards.