Xandrossian/homeassistant_espscreen
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bring the Elecrow's GT911 out of reset through the V3.0's PCA9557 (0.2.95, firmware 0.2.81)
CI / checks (push) Waiting to run
Details
CI / firmware (add-on) (push) Blocked by required conditions
Details
CI / firmware (min_version) (push) Blocked by required conditions
Details

Browse Source 
A unit's touch never answered: "touchscreen is marked FAILED: Calibration error" at setup, the GT911 still in reset
behind the PCA9557 (I2C 0x18) of the V3.0 board. The board file declares the expander as ESPHome's pca9554 (the same
register map) and hands the GT911 driver its reset (IO0) and interrupt (IO1) pins on it, so the driver runs Elecrow's
own sequence: reset low with the interrupt line low, reset high, 56 ms, address 0x5D. A V2.0 without the expander boots
its GT911 by the pull-up as before. The bus is scanned at boot for the log.
This commit is contained in:
Xandrossian
2026-09-21 12:54:18 -07:00
parent a3ef7f09a1
commit da28d19961
7 changed files with 50 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ELECROW.md
+11 -12
View File
@@ -39,19 +39,18 @@ suits a screen that stands further away.
### Touch
The GT911 is polled every 20 ms over I2C at 400 kHz, with no interrupt pin and no reset: the **V3.0** has a PCA9557
I/O expander (I2C 0x18) on the GT911's reset and interrupt lines, and writing it during boot is what breaks the touch
on that revision. It powers up with every pin as an input, a pull-up brings the GT911 out of reset before the firmware
starts, and the driver finds it ready. A bus scan at boot upsets the GT911 too, so `scan: false`.
The GT911 is polled every 20 ms over I2C at 400 kHz. The **V3.0** has a PCA9557 I/O expander (I2C 0x18) on the
GT911's reset (IO0) and interrupt (IO1) lines, and a unit tested here kept its GT911 in reset until something drove
them (`touchscreen is marked FAILED: Calibration error` in the log, firmware 0.2.79 and 0.2.80). The board file
(firmware 0.2.81) declares the expander as ESPHome's `pca9554` (the same register map) and hands the GT911 driver its
reset and interrupt pins on it: the driver runs Elecrow's own sequence, reset low with the interrupt line low, reset
high, then 56 ms, which also fixes the address at 0x5D. A V2.0 board without the expander boots its GT911 by the
pull-up as before; the expander's setup fails there, harmlessly, and the driver tries 0x14 by itself when 0x5D does
not answer, so no address override is ever needed.
The GT911 takes I2C address **0x5D** when GPIO 38 reads low at power-on and **0x14** when it reads high; on this
board it is 0x5D on most units, and a unit that never reports a touch may be a 0x14. Give that screen an Override YAML
in ESP Screens (Screen settings → Override YAML) with:
```yaml
touchscreen:
address: 0x14
```
The bus is scanned at boot. For a diagnosis, give the screen `logger: level: DEBUG` in its Override YAML (Screen
settings → Override YAML) and read its log: the scan lists 0x18 (the expander) and 0x5D or 0x14 (the GT911), and the
driver logs `Switches ADDR: 0x5D`; a screen without a working bus lists nothing.
**GPIO 19 and 20, the touch I2C, are the ESP32-S3's USB D- and D+.** The ROM leaves the USB PHY on those pads and
ESP-IDF's I2C driver cannot take them back: the bus reads as `I2C software timeout` and the touch never answers