Conversation
|
Thanks for the PR. The whitelist approach could not cover the retail units we measured (the tuple varies between C units), so #296 replaced the touch-based detection with a probe of the LCD controller and removed the warning path entirely; your CoreS3-SE is covered by that. Since the code this PR changes no longer exists in develop, I'd suggest closing this one. Note that PRs here should target |
|
Thanks for investigating this and for implementing the panel-based detection in #296. That addresses the warning and delay on our CoreS3-SE without relying on a touch-controller tuple. Closing this PR and validate the change when it reaches the next M5GFX release. |
|
Thanks for investigating this and for implementing the panel-based detection in #296. That addresses the warning and delay on our CoreS3-SE without relying on a touch-controller tuple. We’ll close this PR and validate the change when it reaches the next M5GFX release. |
Fixes #276.
A physical CoreS3-SE reports the FT6336U identity tuple CIPHER 0x64, FIRMID 0x03, VENDID 0x20. The current whitelist rejects it, logs a misleading read-failure warning, and falls back to ILI9342C even though all three reads succeeded.
M5Stack documents CoreS3-SE as FT6336U plus ILI9342C, so this change accepts the complete tuple as the ILI9342C variant. Existing 0x11 vendor handling and ILI9342E selection remain unchanged. It also requires the cipher register read to succeed before accepting any identity.
Hardware verification:
Hardware reference: https://docs.m5stack.com/en/core/M5CoreS3%20SE