Hi support,
thanks for the reply. Aftre these changes i don’t have new logs, but the exactly the same error. When the error occurs, the state of the SDA and SCL signals is as follows:
If I keep pressing the capacitive touch, the signals do not change state and remain as in the image
Thank very much for the help
Fabio
Dear @fmolon ,
Thank you for your measurements and the information.
This does seem to be rather strange behaviour. The controller seems to block the bus by pulling SDA down to 0. Unfortunately the measurements might not be telling the whole story. What might be of value, would be the knowledge of what happens during the final 20 clocks. For that to be captured you could try using the trigger mode normal and then to trigger on negative edge. Alternatively you could use a logicanalyser to get a visual of what data is being transmitted on the bus. We are still assuming that the controller is missing a clock cycle.
However, the kernel should be initiating a recovery, which does not appear to happen. It might also be interesting to see what happens on the bus, when it is blocked and the following command is being sent:
i2cdetect -r -y 1
Would the SCL line then toggle?
In essence the following two measurements could be interesting:
Best regards,
Collin
Hi @collin.tx,
thanks for the reply. I have a littele uptade regarding your question. When the issue occurs and the capacitive touch no longer responds, the following error messages are continuously printed:
When the system enters this state and I run the command i2cdetect -r -y 1, I get the following result:
[Update]
I verified another point that I believe is important. I checked the interrupt counter of the capacitive touchscreen using:
cat /proc/interrupts | grep ili
Every time I touch the capacitive touchscreen, the counter increments. I observed that when the issue occurs, the interrupt counter of the capacitive touchscreen increases autonomously, even without any touch input.
Thanks
Fabio
