fix: backlight on CrowPanel Advance 4.3/5.0/7.0 V1.2+ hardware (STC8H1K28 MCU) - #307
Conversation
The V1.2 hardware revision of the CrowPanel Advance 7-inch (and the 4.3/5.0 siblings sharing this LGFX driver) replaced the TCA9534 I/O expander with an STC8H1K28 microcontroller at I2C 0x30 that now gates the backlight, buzzer, speaker and touch enable. The existing driver only programmed the TCA9534 at 0x18, so boards from V1.2 onward (incl. the V1.3 'latest' revision and V1.4 units currently in the wild) boot with the backlight off — the panel initialises correctly but is only visible under a flashlight. See meshtastic/firmware#7126. Probe I2C 0x30 at init_impl() time and, when the MCU is present, follow Elecrow's reference sequence (pulse GPIO1 low, write 250 to activate touch, write 0 for max backlight) instead of the TCA9534 path. Sleep/wakeup on V1.2+ hardware now toggle backlight via the same MCU (write 245 to disable, write 0 to re-enable). V1.0/V1.1 boards with the TCA9534 at 0x18 continue to use the original code path unchanged. Co-Authored-By: mirko sacchi <sacchimirko44@gmail.com>
Probing I2C 0x30 directly is unreliable on cold boot — the MCU hasn't finished coming up yet and NACKs every probe attempt, which caused the driver to fall through to the TCA9534 path and leave the backlight disabled on V1.4 hardware after a power cycle (though it worked after a soft reset because the MCU retained state from the previous run). Discriminate hardware revisions via the TCA9534 at 0x18 instead — it's always passive and always ACKs on V1.0/V1.1. If the TCA9534 is absent we assume V1.2+ and execute Elecrow's reference wake sequence unconditionally (write 250, pulse GPIO1 low for 120 ms, write 0 for max brightness), repeated 5 times so a single NACK during MCU boot doesn't leave us dark. Co-Authored-By: mirko sacchi <sacchimirko44@gmail.com>
|
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
ElBartoCompany
changed the title
|
I don't have a ver 1.1 in 7" only a 3.5 ver 1.0. My board is silkscreened DIS02170A 7" hdw ver 1.4. I do not have a brightness slider. |
yeah, that's all correct. Ver 1.0 does not have means to change display brightness because that's what has been added in later hardware versions only. |
📝 WalkthroughWalkthroughThe display driver detects Elecrow board revisions during initialization. It uses the STC8H1K28 control path for V1.2+ boards and the TCA9534 GPIO path for V1.0/V1.1 boards during initialization, sleep, and wake. ChangesElecrow hardware revision support
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant init_impl
participant TCA9534
participant STC8H1K28
init_impl->>TCA9534: Probe address 0x18
alt TCA9534 detected
init_impl->>TCA9534: Configure GPIO and backlight
else STC8H1K28 board
init_impl->>STC8H1K28: Send wake and touch activation
init_impl->>STC8H1K28: Send repeated backlight commands
end
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
include/graphics/LGFX/LGFX_ELECROW70.h (1)
53-69: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winConsider an early exit from the wake loop once the MCU acknowledges.
The loop always runs all 5 iterations (~1.1s total:
delay(120) + delay(100) + delay(20)per iteration), even after the MCU responds successfully on an earlier iteration.writeMcu()'s return status is discarded, so there is no way to stop early. The PR description itself calls out this wake-loop duration as a point worth reviewer consideration.Track the
Wire.endTransmission()result and break out of the loop once a write succeeds, to avoid the fixed ~1.1s delay on every boot once the MCU is confirmed awake.♻️ Proposed early-exit refactor
- for (int attempt = 0; attempt < 5; ++attempt) { - writeMcu(CROW_MCU_TOUCH_ACTIVATE); - pinMode(1, OUTPUT); - digitalWrite(1, LOW); - delay(120); - pinMode(1, INPUT); - delay(100); - writeMcu(CROW_MCU_BL_MAX); - delay(20); - } + for (int attempt = 0; attempt < 5; ++attempt) { + Wire.beginTransmission(CROW_MCU_I2C_ADDR); + Wire.write(CROW_MCU_TOUCH_ACTIVATE); + bool ok = (Wire.endTransmission() == 0); + pinMode(1, OUTPUT); + digitalWrite(1, LOW); + delay(120); + pinMode(1, INPUT); + delay(100); + writeMcu(CROW_MCU_BL_MAX); + delay(20); + if (ok) { + break; + } + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@include/graphics/LGFX/LGFX_ELECROW70.h` around lines 53 - 69, Update the wake loop in the hasMcu initialization path to use the success status from writeMcu for each MCU command, and break once the MCU acknowledges successfully. Preserve the existing retry sequence and GPIO pulse behavior when writes fail, while avoiding remaining iterations and delays after a successful acknowledgment.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@include/graphics/LGFX/LGFX_ELECROW70.h`:
- Around line 53-69: Update the wake loop in the hasMcu initialization path to
use the success status from writeMcu for each MCU command, and break once the
MCU acknowledges successfully. Preserve the existing retry sequence and GPIO
pulse behavior when writes fail, while avoiding remaining iterations and delays
after a successful acknowledgment.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 57d06fef-47e7-4243-ae8a-0ede6301ce64
📒 Files selected for processing (1)
include/graphics/LGFX/LGFX_ELECROW70.h
4 participants
Summary
LGFX_ELECROW70only knew how to drive the TCA9534 I/O expander at I²C0x18, which is present on CrowPanel Advance 4.3"/5.0"/7.0" V1.0/V1.1 boards. Starting with hardware revision V1.2 (and including V1.3 / V1.4 currently shipping in the wild) Elecrow replaced the TCA9534 with an STC8H1K28 microcontroller at I²C0x30that now gates the backlight, buzzer, speaker and touch-controller enable. With the old driver, V1.2+ boards would initialise the RGB panel correctly but the backlight would never be turned on — the screen was only visible under a flashlight (matches the report in meshtastic/firmware#7126 for the 7" board).Protocol (from Elecrow's CrowPanel-Advance-7-HMI-ESP32-S3 reference repo):
0→ backlight max (V1.3+ scale, also valid on V1.2 as a no-op which leaves the panel dark)245→ backlight off246/247→ buzzer on/off248/249→ speaker on/off250→ activate touch controllerThe MCU needs a wake sequence on cold boot (pulse
GPIO1low for ~120 ms, write250, write0) — a plain I²C probe doesn't work because the STC8H1K28 is still coming up and NACKs every early transmission.What this PR does
0x18atinit_impl()time to classify the hardware revision.write 250 → pulse GPIO1 LOW 120 ms → write 0), repeated 5 times to cover the window during which the MCU is still booting.245= off,0= max) on V1.2+ boards; keep TCA9534 sleep/wakeup for V1.0/V1.1.writeMcu()helper and named constants for the single-byte commands.Validated on real CrowPanel Advance 7.0" V1.4 hardware running
elecrow-adv1-43-50-70-tft: backlight now comes up at full brightness on cold boot, and the device stays stable afterwards.Review & Testing Checklist for Human
Risk: yellow — small, targeted change confined to
LGFX_ELECROW70.h, but it changes the init order slightly and I've only been able to verify on V1.4 hardware.0x30) that backlight comes up on cold boot and stays on during normal use.Wireearly during boot (the I2C scan runs beforescreen->setup()soWireis already begun on SDA=15/SCL=16 by the timeinit_implruns on this variant).Suggested test plan: flash
elecrow-adv1-43-50-70-tfton both an older TCA9534-based unit and a newer STC8H1K28-based unit, cold boot each, and confirm visible backlight + normal LVGL UI on both.Notes
adv2-*envs are not affected by this change.meshtastic/firmwarewill bump thedevice-uipin so the fix reaches users without requiring a local rebuild.250(activate touch) command is issued unconditionally on V1.2+; on boards where touch was already awake this is a no-op, and without it the GT911 touch controller remains unpowered on cold boot.Summary by CodeRabbit
New Features
Bug Fixes