Capacitive touch problems under linux (FT5x06)
Hi,
now we are prototyping couple of devices using TI AM3358 Starter Kit. (http://www.ti.com/tool/tmdssk3358)
Original kit goes with resistive touch but we purchased couple of displays with capacitive touch from digikey:
1) NHD-7.0-800480EF-ATXL#-CTP
2) NHD-4.3-480272EF-ATXL#-CTP
Then we tried several FT5x06 drivers found on internet. One driver was good enough to work with touch screen. Most of them failed due to firmware version mismatch. However, several problems still exist.
1) Now driver works only with 7" display. 4.3" does not. Driver recognizes both displays via I2C, handshakes, etc. but in case of 4.3" there are no interrupts from FT5x06 during touch activity. We tried 3 different 4.3" displays from one purchase and result is the same. Then we supposed that driver has set touch threasholds too high so it does not recognize events. We tried to write different values of amplifier via the linux driver but this does not help. So, 4.3" touch does not work even without any glass.
2) Display of 7" works if direct touched but does not when placed beyond 4mm glass. Similar to item 1 we could not find solution how to improve sensivity. We see in linux kernel log that 7" and 4.3" displays report slightly different descriptors during handshake. Now I cannot remember exact phrase but something about different number of rows in matrix.
Is there any guide how to set up touch controller settings to force it to work? We actually need it to be placed beyong glass as thick as 2 mm (or even 4 mm).
Best regards.
-
The 4.3" TFT uses the FT5306, and the 7.0" TFT uses the FT5406. There are a different number of rows between the two touch panels.
The controller IC has various registers that can be set to custom values, such as touch threshold. Below is a link to the FT5x06 application note, which shows these registers:https://support.newhavendisplay.com/hc/en-us/articles/4410042626839-FT5x06-Registers
You can see the table of registers on pages 4-7, and more detail about the threshold registers on pages 9 & 10.0 -
Michael,
We could set up 7" sensivity and now it works with 4 mm glass cover. However, for this case threshold is too close to sensor noise margin. Spontaneous cursor movement can be seen with a threshold of 3 and glass strart to work at threshold 5. So, 7" touch screen works OK.
The most urgent problem remains with 4.3" display. As we discovered it does not work as described. In fact, it is present on i2c bus but it allways reads ad last byte written to it. For example, if we write in u-boot i2c tool:
i2c read 38 80.1 2 80200000
it reads two bytes: 80 80
if we asked it to read 5 bytes it would read 5 times the same byte, 80. The byte is always equal to register number being written.
7" display reads correctly: reading 5 bytes gives us 5 consecutive registers starting from given register number.
We tried both 400kHz and 100kHz bus speed. The rresults are the same.
So we still have problem with it.0 -
The I2C protocol between the two displays should be the same. Do you have another 4.3" TFT with capacitive touch panel to try?
0 -
We have three displays with the same behavior.
We tried to write to mode register hoping that it will hear and exit test mode but that didn't help.0 -
I have just confirmed what I have said above, with the below code:
//---------------------------------------------------------
/*
CTP_Register_Test_mega.ino
Program for writing/reading to/from Newhaven Display Capacitive Touch Panel with FocalTech FT5x06 controller
Please refer to the below URLs for the touch panel controller documentation:
http://www.newhavendisplay.com/app_notes/FT5x06.pdf
http://www.newhavendisplay.com/app_notes/FT5x06_registers.pdf
(c)2014 Mike LaVine - Newhaven Display International, LLC.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
*/
//---------------------------------------------------------
#include <Wire.h>
int WAKE = 14; //WAKE signal is connected to digital pin 14 on the Arduino Mega2560
int INT = 15; //INT signal is connected to digital pin 15 on the Arduino Mega2560
//SDA line is connected to digital pin 20 (SDA) on the Arduino Mega2560
//SCL line is connected to digital pin 21 (SCL) on the Arduino Mega2560
unsigned char dummy, gesture, numpoints, t1xh, t1xl, t1yh, t1yl;
unsigned char x, read1, read2, read3, read4;
unsigned int t1x, t1y;
const char slave = 0x38; //slave address of 0x70 shifted over 1 bit
const char slave_read = 0x39;
void init_CTP()
{
digitalWrite(WAKE, HIGH);
delay(100);
digitalWrite(INT, HIGH);
delay(100);
digitalWrite(WAKE, LOW);
delay(200);
digitalWrite(WAKE, HIGH);
delay(200);
}
void i2c_read(char addr, unsigned char reg) //function for reading a specified register
{
unsigned char x;
Wire.beginTransmission(addr);
Wire.write(reg);
Wire.endTransmission();
Wire.requestFrom(addr, 1);
while(Wire.available())
{
x = Wire.read();
Serial.println(x, DEC);
}
}
void i2c_read4times(char addr, unsigned char reg) //function for reading 4 registers in a row, starting from specified register
{
unsigned char x;
Wire.beginTransmission(addr);
Wire.write(reg);
Wire.endTransmission();
Wire.requestFrom(addr, 4);
while(Wire.available())
{
read1 = Wire.read();
read2 = Wire.read();
read3 = Wire.read();
read4 = Wire.read();
}
}
/*****************************************************/
/*****************************************************/
void setup()
{
pinMode(WAKE, OUTPUT);
pinMode(INT, INPUT);
init_CTP();
Wire.begin();
Serial.begin(9600);
}
void loop()
{
while((digitalRead(INT)) == LOW)
{
i2c_read4times(slave, 0x00);
dummy = read1; //dummy read
gesture = read2; //which gesture register read
numpoints = read3; //how many touch points register read
t1xh = read4; //upper 8 bits of X-axis touch location
i2c_read4times(slave, 0x04);
t1xl = read1; //lower 8 bits of X-axis touch location
t1yh = read2; //upper 8 bits of Y-axis touch location
t1yl = read3; //lower 8 bits of X-axis touch location
dummy = read4; //dummy read
t1x = t1xl | (t1xh << 8); //get the 16 bit X-axis touch location
t1y = t1yl | (t1yh << 8); //get the 16 bit Y-axis touch location*/
i2c_read4times(slave, 0x80);
dummy = read1;
//****************************************************************************//
// UNCOMMENT THE LINE BELOW THAT YOU WANT TO BE SHOWN ON THE SERIAL MONITOR //
//****************************************************************************//
//Serial.println(gesture, HEX);delay(25); //show gesture value
//Serial.println(numpoints, HEX);delay(25); //show how many touch points
//Serial.println(t1x, HEX);delay(25); //show 16 bit X-axis touch location
//Serial.println(t1y, HEX);delay(25); //show 16 bit Y-axis touch location
Serial.println(dummy, DEC);delay(25);
//delays are only used here to slow down scrolling in the serial monitor
//********************************************************************//
}
}I get decimal 25 from the HEX 80 register with the 4.3" display.
0 -
Michael,
1) We use the same code to work with both displays. As you understand this code is either linux or u-boot (based on the same linux) i2c bus framework that has been testing for many years.
2) We used an oscilloscope to inspect the signals on the bus. We didn't see any artefacts on signal timings. Also, we saw the display responds with an ACK so this behavior cannot be thought as just undefined bus.
We need some advice from you what can we check to solve this issue. Probably, there are some issues with an /WAKE signal that works differently for 7" and 4.3" display. This signal is tied to ARM GPIO and goes between pulled up, pulled down and undefined state sereval times during linux boot.
Best regards, Vladimir0 -
I have not heard of this issue before, and have posted code I have just used confirming the register read does work. I very highly doubt you have defective displays, but if you would like to send them back to us for analysis, you may email nhtech@newhavendisplay.com with the part number, requesting an RMA form.
You may be correct, since the WAKE signal operates as you have described. As you will see from my code, I have it set HIGH, then LOW, then kept HIGH (to initialize it) and I am able to read the registers from all sizes of our capacitive touch panels.0 -
Michael,
Unfortunately, the WAKE signal is poorly documented. As I could understand, it is either interrupt to Touch MCU or just a reset. It is called /WAKE in datasheet but actually on the ribbon pcb of display is marked as RST so we are confused. There is a period during boot when this signal has about 2V, not 3.3 and not 0. Moreover, this voltage is strong enough - when we tried to short /WAKE to adjacent INT pin on the connector (being 3.3V and that time) we got just 2.3V, not 3.3. I suspect that all this issues could force FT5x06 to hang. So, do you know the way to get it back to initial state? Will the one ground pulse of 100ms to WAKE signal be enough?
Vladimir0 -
The marking on the ribbon PCB should say WAKE, not RST. Regardless, they are the same function.
To get back to the initial state you would need to power cycle it, although there shouldn't be any hanging if you are initializing it as shown in the code I've posted.
(This part):
void init_CTP()
{
digitalWrite(WAKE, HIGH);
delay(100);
digitalWrite(INT, HIGH);
delay(100);
digitalWrite(WAKE, LOW);
delay(200);
digitalWrite(WAKE, HIGH);
delay(200);
}
The delay values are in milliseconds.0 -
To say trouth, the marking on PCB is as follows:
1) 4.3" - WAKE
2) 7" - RST
However, i see /WAKE signal in both datasheets. That's why I was confused.
Ok, we will try to issue a reset to wake signal. Actually, we did it manually by wire (sporadic pulse, not equal 100ms) but this didn't help. Probably we need something else?0 -
Michael,
It seems we found a reason of the strange behavior. The problem is how fast I2C host goes to reading stage of I2C transfer after finishing its write state. FocalTech chip in 4.3" display is slow so it is not ready with data when the ARM processor starts read part of transaction. Now I tested it with another host which can wait for 1 ms between writing register address and issuing next start condition. In this case display works.
I think you should also test this and add this information into display datasheet. It is TOO IMPORTANT to be in NHD datasheet, not in an application note. Also, you should clearly state in datasheet what chip is used for each display.
I looked through FT chip datasheet and there is no information of this issue. All the delays reported in the spec are about 4-5 mks that is about 2 bit intervals on 400KHz bus and half bit interval of 100 kHz bus. I saw using the scope that we actually have reading delay not less then 2-3 byte intervals but this doesn't work. I think that FT5306 processes its I2C interrupt too slow to update the I2C transmit register so we get the value that has been written in write stage of the transaction.
We will try to play with reading delay on ARM processor to clarify the typical value of delay that works. Now we see that 5406 and 5306 have different delays, possibly because they have different clock frequencies, 5406' being higher that one of 5306.0 -
Thank you for sharing your findings, I'm sure it will help others that run into the same issue. I had not run into this issue before using our testers, but it seems it is highly dependent on which processor is being used.
We will of course keep your suggestion for the datasheets in mind for any future revisions.
Thanks again!0 -
Michael,
Ops! Sorry, that was a graceful explanation but it's not true I made a conclusion comparing two different timings but once programmers added delays on ARM linux nothing actually changed.
But! Then I proposed to pull the flat cable out of connector and push it back while the u-boot is running. And it started to work properly!
The difference between these two cases is that when it is a 'cold' start processor has undefined state on GPIO pins. Most probably they are tri-stated. And there are no pull-up resistors on INT and WAKE, so they float. But then u-boot starts and places GPIO pins in a known state. When we re-plug the cable we power up FT5306 with WAKE being high, not undefinied. And it works.
Now we patched the starter kit by adding 10K pull-up to WAKE. And it works now.
It seems that FT5306 monitors WAKE during its startup and enters some test mode if WAKE is low. Probably, you can ask FocalTech what do they know about this? And what do they think?
Please, check this issue with your displays if possible. If so, this 'feature' must be documented.
Vladimir0 -
Thanks again for sharing your solution, I have added this to the datasheet. Please allow a day or so for this to reflect on our website.
0 -
I understand this may be a shot in the dark, but would you mind posting a link to the kernel driver you found that was workable? I am using the same 7" display in a prototype I am working on, and have had a difficult time with the module sources I tried using/modifying so far.
0 -
Can you please share the firmware driver for this module under linux because it is not a part of standard linux distribution from TI. I am using the same and will appreciate if you provide that as i could save some time.
0 -
We have a linux driver available for the capacitive touch panel, and if you would like it please email nhtech@newhavendisplay.com.
0 -
I have just sent an email to the address provided.
Thanks
Abhishek0 -
We used this driver:
http://lxr.free-electrons.com/source/drivers/input/touchscreen/edt-ft5x06.c?v=3.120
Please sign in to leave a comment.
Comments
19 comments