Issue with Multi-Touch solution for FT5x06

We are implementing the Multi-Touch solution on a Colibri iMX6 Solo with an FT5x06 display from Newhaven Display, using the information at Capacitive Multi-Touch Solution | Toradex Developer Center. The display resolution is 800 x 480.

On this page: Capacitive Multi-Touch Solution Source Code | Toradex Developer Center
the source code for the FT5x06 using Toradex CE libraries is not available (the Windows CE version is not compatible with our HW) so we ported it from the Windows CE libraries version for the FT5x06 that is available. This was not a big deal and the port to the Toradex CE libraries went smoothly: it was basically a port to the Toradex I2C, GPIO, and INT libraries that was required.

The registry is configured to the best of our abilities, and in particular the CapTouchMapping entry has the following values: “799,479,0,0,799,479” and the number of touch points is 1. The HW adapter is now running and the logs indicate the driver loads fine.

Now here is the issue (finally!):

When I touch the display and slide my finger around

  • The logs show that the Y value varies from 0 to 799 very nicely as I move from left to right. I actually thought that would be the X value but I can deal with the flip.
  • However, the X value only varies between 0 and 1 when I move from top to bottom, and quite randomly. There is also a spurious X value of 2049 that pops up from time to time

Here are the logs from the debug console. Note the X() value:

MultiTchAppDriv:vTouchPanelGetPoint() FT5x06 FirstTouch TipSwich(1),TouchID(8), X(1), Y(516)
MultiTchAppDriv:vTouchPanelGetPoint() Input[0] dwID(8), dwFlags(9), X(1), Y(516)
Touch move 0x9
MultiTchAppDriv:vTouchPanelGetPoint() FT5x06 FirstTouch TipSwich(1),TouchID(8), X(0), Y(519)
MultiTchAppDriv:vTouchPanelGetPoint() Input[0] dwID(8), dwFlags(9), X(0), Y(519)
Touch move 0x9
MultiTchAppDriv:vTouchPanelGetPoint() FT5x06 FirstTouch TipSwich(1),TouchID(8), X(2049), Y(522)
MultiTchAppDriv:vTouchPanelGetPoint() Input[0] dwID(8), dwFlags(9), X(2049), Y(522)
Touch move 0x9

I have tried a few variations for the CapTouchMapping registry setting but nothing seems to make a difference in the operation. The Newhaven data sheet does not offer any clues.

Can anyone suggest what might be going on to prevent the X direction from working when the Y direction works so nicely?

We would be happy to post our HW adapter solution (i.e. FT5x06 using Toradex CE libraries) once this final issues is resolved.

From what I see from source code, the X value that is printed out is the value read from the controller’s internal registers, no scaling etc. it’s applied, so it seems that the controller has some issues reading the X axis. Also the fact that X and Y axis seem to be swapped is quite strange.
Did you try with multiple panels or this happens just with a single one (to rule out hardware issues)?

Can you add some code to dump what’s read by bReadInRegister?
Did you keep the re-aligned buffer used to read data?

“Did you keep the re-aligned buffer used to read data?”

  • yes we did

Here is the new debug output from bReadInRegister. The Y value looks fine, but the X value does not even have an event in bits 7-4 of TOUCH1_XH:

bReadInRegister index=  2  value = 0x01
bReadInRegister index=  3  value = 0x00
bReadInRegister index=  4  value = 0x01
bReadInRegister index=  5  value = 0x81
bReadInRegister index=  6  value = 0x8d
bReadInRegister index=  7  value = 0x00
bReadInRegister index=  8  value = 0xa1
bReadInRegister index=  9  value = 0x00
bReadInRegister index= 10  value = 0x00
bReadInRegister index= 11  value = 0xff
bReadInRegister index= 12  value = 0xff
bReadInRegister index= 13  value = 0xff
bReadInRegister index= 14  value = 0xff
MultiTchAppDriv:vTouchPanelGetPoint() FT5x06 FirstTouch TipSwich(1),TouchID(8), X(1), Y(397)
MultiTchAppDriv:vTouchPanelGetPoint() Input[0] dwID(8), dwFlags(9), X(1), Y(397)

We have another display and will test with that today.

How did you set the “RegisterAddress” and the “RegisterAddressSize” parameters using the I2C APIs, before reading the block of registers?
It may be that the read operation is starting from index 0 instead of 2, that would explain the shift.

"How did you set the “RegisterAddress” and the “RegisterAddressSize”

Well, that was an excellent question indeed.

The RegisterAddressSize is set during initialization however somehow I neglected to set RegisterAddress in the I2C read and write routines :frowning:

I have used your I2C libraries before so I should have known about this. Sorry, my mistake and terrific work on your part to identify the possible problem.

Once I complete the testing and integration with our app I’ll post an answer here with the HW adapter source code as an attachment. Hopefully others will find it useful and you can even re-post it on the Capacitive Multi-Touch Solution Source Code web page.

I have one final issue which may be just a logging omission. The following logs are from instrumented code that calls DeviceIoControl when touch events are processed. The unified driver reports Touch Move and Touch Up events, but not Touch Down events. There is no log posted by the unified driver when flags are 0x0a (i.e. TOUCHEVENTF_DOWN|TOUCHEVENTF_INRANGE)

I wonder if the event is ignored or just not logged?


So thanks to the Toradex support guys for asking a question that led me to find the bug in my FT5x06 HW adapter. See my comment above for the solution to the problem.

Everything works fine and I’m posting the source code for anyone who might find it useful. Please note that this code is provided as is, and I’m not really willing or able to provide any support for it. Toradex support is really great so they’ll be able to help you with pretty much any problems you might have,


This project basically provides touch controller source code as indicated below in the Toradex download area.


@guzoo, thanks a lot. We really appreciate your feedback and of course also the code you shared! We will also have a look at it, do some tests and then link it from our official website. Can we just copy the code and share it from our own servers?

By all means post the code on the official web site. I’ve found it to be a great resource and I’m happy to contribute.

Hi there!
Excellent work all of you!!
Here´s my issue.
I´m working on VF61, WEC7 and I can´t get this to work.
Here´s what I do: I building all of this with 2.0CE libs (is that a problem?) and checking on the correct GPIO setup. and I get only this:

14:44:00.571> MultiTchHwAdapt:bReadInRegister() illegale response in I2c_Read()
14:44:00.991> MultiTchHwAdapt: restars communication with touch controller...
14:44:01.331> MultiTchHwAdapt: Start commnication with the toch controller FT5x06
14:44:01.331> I2cTransaction, KernelIoControl failure 170
14:44:01.369> MultiTchHwAdapt:bReadInRegister() illegale response in I2c_Read()

I´m not sure, but should I keep the re-aligned buffer, as It works with Tegra I2C?

I also must say that the PCAP is working with T20 module.
I switch between T20 and VF61 and can´t get VF61 to work on this…

Also, here is the debug information:
. TOUCH:GetCapTouchMappingValues - RegQueryValueEx failed. Key TouchMappingValues missing or wrong typedone
. UnfdMutiTchDrv: MaxTouchPoints 2

I only have experience with a Colibri iMx6 Solo on an Iris carrier board, so your situation is quite different.

Before you worry about the missing TouchMappingValues you need to get your I2C working on the VF61. I got that error (illegale response in I2C_Read) when my SDA and SCL wires were crossed in our HW. It was an easy fix. Do you have the luxury of a logic analyser (e.g. Saleae) for diagnosing the actual I2C signal? Are you using the same GPIO mapping for the VF61 and T20? And are you sure this is correct? I am not familiar with those boards but close inspection of the data sheets should identify any differences.

BTW I used the CE 1.9 libraries, but I would be surprised if this would be the problem.

“I´m not sure, but should I keep the re-aligned buffer, as It works with Tegra I2C?”. I’m not sure either but it’s safer to do so.

I wish I could offer some more concrete advice besides “check your configuration and wiring” :frowning:

great! that´s quite a beggining…
Don´t worry, I will come back with some moore questions!!

And thanks in advance.


Please share Vybrid image version?

Recently we changed [I2C library structure][1, Vybrid 1.5 b4 requires Toradex CE Library V2.1. But we are not yet released Toradex CE Library V2.1. We would like to suggest you the workaround or try Vybrid 1.5 B2 or prior with Toradex CE Library 2.0.

Let us know if you face any problem on that.


We have implemented a library for related to this change but it is not yet released. We would like share preliminary version of that library. Build the HwAdapt application with this library and test on your side.

Let us know if you face any problem on that.

I´m using the latest official image, 1.4 (CE 7.0).
I will try the workaround and let you know.

Updates: Now, with 1.5b2 and HwAdapt builded with the preliminary version can see the I2C runnung on the scope.
Still getting a similar error:

16:06:52.883> MutiThHAdat loading...MultiTchAppDriv:I2C Library Version=2.0 Build=4142
16:06:52.214> MultTchHwAdapt: Start communication with the touch controller FT5x06
16:06:52.214> I2C rror: .\src\i2c_vyb.c, 674: Start ailed
16:06:52.214> MultiTchHwAdapt:bReadInRegister() illegale response in I2c_Read()
16:06:52.634> MultiTchHwAdapt: restarts communication with touch controller...
16:06:53.951> MultiTchHwAdapt: Start communicatio wit the touch controller FT5x06
16:06:53.951> I2C Error: .\srci2c_vyb.c, 674: Startfailed

What do you think?

@MartinAused ,

Sorry for asking again do the test.

Please use 1.5 B4 image with preliminary version library.


Use 1.5 B2 or prior image with our standard release library

Let us know which combination you are seeing the problem and did you made any changes on @guzoo sample code? You can use I2C_demo program to detect touch controller slave address. If it is not detecting the slave address, please check RESET pin is in the inactive state. Also, confirm Interrupt pin is the proper state.

We have tested I2C communication, didn’t see any problem.

None of the combinations gives me any response for the I2C.
I´m just asking: I only see I2C1 and I2C2 in register keys.
and I´m trying to use original pins #194 for SDA and #196 for SCL, that in datasheet have as Vybrid Signal Name I2C0_SDA and I2C0_SCL.

how do I bring I2C0 up in the image? i´m I right if I said that the driver is not loading I2C0?

I can see in debug port the following stuff:

13:57:43.690> Loading I2C1...
13:57:43.690> Done I2C1

but I do not see anything about I2C0…