"FT6202: bad FT6206_REG_VENDID!" on the current M5Stack Core2 revision

[meganetaaan]

Build environment: Any OS
Target device: esp32/m5stack_core2

Description
I am reporting this issue because changes on the Moddable side are required for the issue in stack-chan/stack-chan#135. Due to a specification change in the touch control chip for M5Stack Core2, the value of VENDID has been changed from 17 to 1.

Steps to Reproduce

1. Build and install any app using: mcconfig -m -d -p esp32/m5stack_core2
2. See error

/Users/apple/dev/moddable/modules/drivers/ft6206/modFt6206.c (131) # Break: FT6202: bad FT6206_REG_VENDID!

Expected behavior
The app should launch without errors.

Other information

I have received a report that the issue was resolved after modifying the relevant code to

if ((1 != data[0]) && (17 != data[0])) xsUnknownError("bad FT6206_REG_VENDID");

However, it is necessary to consider whether this workaround is appropriate as a driver for FT6202.

[phoddie]

Interesting. Thank you for the report. So... if I understand correctly, they changed from FT6206 to FT6202?

[meganetaaan]

However, it is necessary to consider whether this workaround is appropriate as a driver for FT6202.
FT6202

Oops. This is my typo of FT6206. Please forget it.

The reported issue is due to a silent breaking change, as there have been no changes to the specs of the M5Stack Core2, which currently uses FT6336u. According to one of the developers of M5Stack, the new chip is compatible at the application level except for the vendor ID. The default value of the vendor ID in the datasheet is 0x11, which differs from both the old value of 0x17 and the new value of 0x01. While it may seem ad hoc, I believe that treating 0x01 as a valid ID, similar to the aforementioned workaround, would be sufficient in this case.

[meganetaaan]

Ah, by the way, @Fuji-P, who reported this workaround, is positive about contributing code. It would be greatly appreciated if you could check the pull request later.

[phoddie]

Thank you for the clarifications. I wonder why the vendor ID changed. Perhaps this part is a clone. In any case, I agree that we should support this configuration.

FWIW– the vendor ID that our implementations check for appears to be consistently 17 which is equal to the datasheet value of 0x11.

I see the PR from @Fuji-P. Always happy to welcome a new contributor. We'll get that taken care of.

[phoddie]

This has been merged. The corresponding changes have been applied to the ECMA-419 version of the FT6202 driver.