Luckfox Forums

Hi, I am debugging a problem with the 86panel, where the touch input only works sometimes, but sometimes not. I found the following:

The goodix touchscreen is configured at i2c address 0x14 in the dts (sysdrv/source/kernel/arch/arm/boot/dts/rv1106-luckfox-pico-86panel-ipc.dtsi in the SDK, lines 281ff).

However, sometimes the goodix chip appears at i2c address 0x5d (visible with i2cdetect 3). This is the alternate i2c address of the touchscreen chip when the IRQ line (connected to PA0) is logic low during reset (PD0).

Unfortunately, we don't seem to have a schematic diagram of the 86panel, so it's not totally clear how goodix IRQ is connected. But I guess it is just connected to PA0 without a pullup.

So my question is: shouldn't the pinctrl setup in the dts (line 305 in sysdrv/source/kernel/arch/arm/boot/dts/rv1106-luckfox-pico-86panel-ipc.dtsi) configure a pullup on the IRQ line to make sure it is not floating and always high when the goodix chip is reset? Like:
A floating IRQ does not seem to be a good idea in any case, I suspect that it could also be responsible for sudden freezes of the entire system I sometimes see when writing to the emmc. If that input starts oscillating, all sorts of bad things could happen.

Update: Yes - configuring a pullup for PA0 solves all the instability issues I had with both of my 86panels! These worked, but as soon as mounted near mains, apparently took up some EMI on that floating IRQ line and crashed/malfunctioned. I guess that DTS change should be added to the SDK, others might have experienced unstable operation, too

Hello, in our actual tests on the Luckfox-Pico-86Panel, we have not encountered this issue yet. Currently, our goodix initialization method is to load the driver after completing the power-on sequence required by 0x14 through /etc/init.d/S25goodix. The interrupt pin is also set as a floating input according to the requirements of the datasheet in the end.
From the source code of the goodix driver, the driver will determine the first obtained I2C address to decide whether to pull up the interrupt pin for the subsequent reset operation. There is a possibility that during a certain reset process, interference occurs and the address is determined as 0x5d.
We will attempt to reproduce this issue to determine the cause. If setting the interrupt pin to default as an upper pull-up can solve this problem, we will update the SDK and related images.

Hi, thanks for the reply. Now I understand why it works in the standard setup - I only looked at the dts and was not aware of the insmod_goodix.sh script that is in the SDK (IMHO, a bit of a hack ). In the openwrt build I'm working with these days, there is no such late-loading script, but just dts, and without the pullup it was just random chance that the GT911 got 0x14 and not 0x5d i2c address. So yes, no need to change the SDK because of that, as long as the S25goodix is in place and the driver is not autoloaded.

But the main problem I had was not the goodix not always loading, but quite frequent total freezes of the entire system, reproducibly caused by emmc writes or a bit elevated surrounding EMI. With or without goodix loaded. Those symptoms suggested a floating/oscillating input/IRQ line, that's why I came to enable the pullup on PA0. And since I did (and no other change!), the same 2 devices that were freezing shortly after boot before, are now running fine for ~48hrs already.

I agree that if INT output of the GT911 does drive low and high, the pullup should not be needed. However should INT just pull down (OC), a pullup is needed. The GT911 datasheet is not entirely clear about this, but as the INT polarity is configurable, the output certainly does have push and pull drivers, and probably does not leave INT floating.

So I am now confused about why enabling the pullup on PA0/INT does help, but it certainly does. I'm happy it works now, but I think I should also understand why…