AtomS3R: re-probe the panel ID at low clock speed before giving up - #256
Conversation
There was a problem hiding this comment.
Pull request overview
Improves AtomS3R LCD autodetection robustness by retrying the RDDID (panel ID) probe at a much lower SPI clock rate when the initial high-speed probe returns an unknown ID, addressing cases where some GC9107 batches only return a valid ID at low read speeds.
Changes:
- Add a conditional slow re-probe (100 kHz) for AtomS3R panel ID detection when the first probe doesn’t match known IDs.
- Adjust SPI
freq_readconfiguration values in a couple of other board init paths (StopWatch, ED2208/M5PaperColor).
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| id = _read_panel_id(bus_spi, GPIO_NUM_14); | ||
| bus_cfg.freq_write = 8000000; | ||
| bus_cfg.freq_read = 8000000; | ||
| is_st7735 = ((id & 0xFFFF) == 0x7683 || (id & 0xFFFF) == 0x897C); | ||
| is_gc9107 = (id & 0xFFFFFF) == 0x079100; |
There was a problem hiding this comment.
The restore is not dead code: the subsequent board probes in this autodetect chain reuse bus_cfg and set only the pins, relying on the frequency staying at the probe speed. Without the restore, a failed AtomS3R retry would leave 100 kHz configured for every later probe on this chip. Added a comment in f04087d to make that explicit.
| bus_cfg.spi_host = SPI2_HOST; | ||
| bus_cfg.freq_write = 80000000; | ||
| bus_cfg.freq_read = 1000000; | ||
| bus_cfg.freq_read = 8000000; | ||
| bus_spi->config(bus_cfg); |
There was a problem hiding this comment.
Good catch — this was unintended collateral from a local experiment and is reverted in f04087d. The diff now touches only the AtomS3R probe block.
| bus_cfg.spi_host = SPI2_HOST; | ||
| bus_cfg.freq_write = 4000000; | ||
| bus_cfg.freq_read = 1000000; | ||
| bus_cfg.freq_read = 8000000; | ||
| bus_spi->config(bus_cfg); | ||
| bus_spi->init(); |
There was a problem hiding this comment.
Same as above — unintended, reverted in f04087d.
Some GC9107 batches return a valid ID over the RDDID command only at low clock rates; at the 8 MHz probe speed the readout is garbage, so autodetect rejected the panel and the unit appeared dead (issue m5stack#222). When the first probe matches neither known ID, re-probe once at 100 kHz. Verified on a healthy GC9107 unit that the 100 kHz readout returns the correct ID (0x079100), and on both GC9107 and ST7735 units that the normal first-probe path is unchanged. The ST7735 does not answer the RDDID readout at low clock rates at all (verified: 0xFFFFFFFF at 1 MHz and below, correct at 8 MHz), so the slow retry cannot misidentify it; a healthy ST7735 has already been caught by the first probe.
08ac370 to
f04087d
Compare
Fixes #222.
Problem
Some AtomS3R GC9107 panel batches return a valid ID over the RDDID command only at low clock rates. At the probe speed (8 MHz) the readout is garbage, so autodetect matched neither known panel ID and silently bound no display — the unit appeared dead (black screen, backlight on) under every M5GFX-based firmware.
Fix
When the first ID probe matches neither known ID, re-probe once at 100 kHz before giving up. The retry only runs after a failed first probe, so healthy units keep the exact same fast path. 100 kHz was chosen because it is the regime the reporter verified on an affected unit (bit-banged readback at ~100 kHz returns the exact expected
0x079100, and even there the readback is timing-marginal).Defaulting to GC9107 on an unknown ID was rejected as an alternative because it would misidentify ST7735 variants.
Verification (real hardware, one GC9107 unit and one ST7735 unit)
0x079100on the GC9107 unit and the panel initializes normally.0xFFFFFFFFat 1 MHz and below, correct at 8 MHz), so the slow retry cannot misidentify an ST7735; a healthy one has already been caught by the first probe.The affected panel batch itself was not available for testing. The issue reporter offered to run further tests on their unit; verification from this branch (or after merge) would be welcome.