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#-CTP2) 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).

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:http://www.newhavendisplay.com/app_notes/FT5x06_registers.pdfYou can see the table of registers on pages 4-7, and more detail about the threshold registers on pages 9 & 10.

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 80200000it reads two bytes: 80 80if 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.

In that case, it is most likely something with your driver/code. Please verify this and try the display again. I have used all of our TFT's capacitive touch panels with the same code and they have all been proven to work.

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>

//****************************************************************************// // UNCOMMENT THE LINE BELOW THAT YOU WANT TO BE SHOWN ON THE SERIAL MONITOR // //****************************************************************************//

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.

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.

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?

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):

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.

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.

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.