iMX6UL TSC (Resistive Touch Interface) Problem

[paolobozzola]

Using the TSC driver with Linux, we see a behavior of the 4W  resistive touch which happens on any kind of connected 4W RTP (Resistive Touch Panel), independent of the size and form-factor.

Basically, this is the behavior:

1. If the touch is constant and finger presses the RTP firmly, the touch is correctly detected and cursor is positioned correctly
2. If the RTP is slightly touched, just place the fingertip and move it, but without a firm pressure,  then we see the TSC becomes crazy: the driver returns false touches and positions of touches (mainly pointing to top left corner near 0, 0). This is dangerous in machine applications in case your touch is not firm and strong, because the touch driver detects a touch elsewhere, and if happening on other "buttons" then unwanted actions happen.
3. If we use the same RTP, but disconnected from iMX6UL, and use a 4W controller board with USB interface,
   and we use it with same iMX6UL board, that controller does NOT "see" light touches; it only reacts to strong touches, so this behavior never happens.

Questions:

• does anybody has detected same behavior?
• is it possible to set thresholds for the TSC?
• can anybody explain in detail if/where to put hands to modify this behavior?

Today (DEC 6th) we could apply some workaround, adding a s/w filter inside the Interrupt routine. This make the RTP response slower but a lot less sensitive to light touches, so the user has to give a good fairly strong touch and there are not false touch responses any more. 

We are asking all users if anybody could ever see such behavior, and eventually how it could be fixed (in a different way than filtering coordinates by software).

Our RTP interface is exactly 1:1 the same circuitry used in the iMX6UL evaluation board.

Any feedback is welcome.

Important Notice:

To help readers who find absurd info in the iMX6UL manual about internal ADC registers, see attached document.

Unfortunately it does not help so much understanding the erratic behavior of the touch interface, but anyway can help ADC users...

[paolobozzola]

Dear Igor,

thanks for your interest in this problem.

But what you have given as info/link unfortunately does not help.

The info says "it works", and I can believe that somebody else has used the RTP (resistive touch panel) with inside TSC interface of iMX6UL and did a good job.

We also used it a LOT of times but the problem which appears (using the NXP standard driver) is always present. More or less evident, but always present. Smaller displays/touches make it less evident, but there is, always.

As you can see from the original NXP EVK and my photo.

In some applications it does not hurt so much; in others (like last one which is making us mad) is creating huge troubles due to false clicks detection.

So, knowing that "it works" it's not enough.

We need true help and problem analysis.

We can eventually put hands on the TSC driver, but let me say - honestly - that the User's Manual (reference Manual 2017) is terribly written. There are lots of mistakes. Even the English syntax is odd in many cases. In other words, what is written in the manual is fairly unusable from s/w point of view since there are no clear explanations nor examples of all the many possible settings.

NXP is giving the standard TSC driver in their EVK, and we have openly demonstrated that it has exactly the same erratic behavior we have tested on many boards, on many different touch screens, including EVK.

Probably the right solution should come from a better re-written driver, and we could even do, but with actual manual it's a guess. Since we tried changing some settings and nothing changes, so we stopped our analysis.

You told me in past answer that you do not know anybody using a different driver.

Perhaps somebody could help?

Can you eventually forward this conversation to somebody expert using the iMX6UL inner TSC interface?

Or have some better explanation of what the cryptic manual tells about TSC management?

We can hire an expert provided he can solve the problem, giving us a correct guideline for solving the problem with 100% working TSC programming.

Thanks in advance.

My best regards

Paolo

[paolobozzola]

Dear Everybody,

probably we have discovered the bad issue in the TSC interface of the iMX6UL.

The "detect" action is taken with a correct h/w setup but with possibly with a wrong reading method.

The h/w setup for the detect action is made by the TSC interface inside the iMX6UL with a big 200K pullup to the Xleft side of the RTP (resistive touch panel). Notice that typical resistance of an RTP (e.g.: 7") is about 700 Ohms on X axis (300 Ohms on Y axis).

The Xright side is connected to the ADC input.

The Y foil is set to GND level.

When there is a touch, the huge pullup and the small X resistance make a very low voltage to the Xright pin. Typically this voltage should be around 10 to 20 mV for a "good" contact.

But if the RTP is just slightly touched, this voltage can go up to 300mV or in some cases 500mV.

The "bad" issue is that TSC interface does not check the touch reading the ADC analog input, but manages the same input as digital GPIO input.

So the "logic 0" will result in "0" also for false/partial/unstable touches. Because the valid input range of a "0" for a GPIO used as digital input is quite large.

This leads to the erratic behavior discussed in the posts before.

We have dismantled the standard driver.

When we get interrupt from TSC which "detects" a touch we stop the state machine of the TSC, reprogram the ADC input to make an analog conversion, read the value, and we accept the detect interrupt as "true detect" only if we read below 25mV.

This action is still under development and analysis, but so far we can reject almost 98% of false touches, and the RTP response is now reasonable.

I would advice h/w designers that RTP is still largely used in cheap applications, where the 2 US$ overprice of an RTP on an LCD, compared to the 10+ US$ of a CTP brings a huge saving if the control system is used in thousands.

But end user will never accept any erratic behavior, because everybody is used to make touches on his smartphone: there you have a CTP (capacitive touch) with multiple touch detection and very fast response even for quick soft touches.

So it is likely that end users of a control device with RTP will touch the RTP in the same manner of a smartphone's CTP.

The only way to "train" the end user to the correct usage of an RTP is to apply a threshold to cut (un-detect) light touches. So the user will begin to give stable good-pressure touches to the RTP.

This is what we have done. It works. And usually this is done internally by RTP interface chipsets like Microchip AR1100 where you can set the touch sensitivity threshold.

It's a pity that the TSC interface inside the iMX6UL does not check the detection using analog conversion with a presettable threshold for the touch sensitivity.

I suggest that everybody using iMX6UL TSC should modify the driver to make the detect checking with analog measurement of the touch, against a threshold of a few mV (to be set by s/w).

We can eventually give more details to whom is interested.

Best regards

Paolo

[igorpadykov]

Hi Paolo

one can look at touch screen sensitivity suggestions provided on

Exposing touch screen sensitivity in the UI - User Experience Stack Exchange 

Also pay attention to adc power supplies, in particular ultra low noise ldo RICHTEK RT9193

used for powering adc

MCIMX6UL-EVK_DESIGNFILES

Design files, including hardware schematics, Gerbers, and OrCAD files

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[paolobozzola]

Dear Igor,

definitely, it is not a problem due to RTP (resistive touch panel). It's the internal controller native of the iMX6UL.

It is not a problem of noise. We use thousands of RTP with other boards and we do not have such troubles. In many cases we use the SAME RTP with cheap 3 US$ controller (4W to USB) and we do not have problems.

It seems that the internal TSC block cannot accept a threshold for touch pressure. It changes from idle status to active just when the RTP is slightly touched: then it triggers the ADC and in some cases the ADC starts converting when the two membranes of the RTP are already apart. This is clearly understood since many false touches happen in the 0,0 area (top left corner) of the RTP. If the touch is strong and stable enough, we do not have any problem.

We have made a workaround now, adding a filter inside the Interrupt routine, which can "recognize" false touches by comparing a buffer of some touches and check if their positions are congruent or not.

If not congruent (i.e.: initial touch 300, 600 then we see 50,100 then 25, 40) the whole touch is discarded. At least three samples must be congruent.

If the read coordinates happen in a +/-10% range off the first detected touch, we accept the first touch as valid.

This filter is not 100% fault proof but ensures a good behavior and does not slow the process.

If anybody could explain if the TSC block can be set with some threshold (so false light touches are discarded at once), we can upgrade the driver.

This phenomena, tested on many different RTP, happens all the times and can be perfectly replicated.

Best regards

Paolo

[igorpadykov]

Hi Paolo

to check hardware one can test with field DE_GLITCH

described in sect.51.3.9 TSC_DEBUG_MODE2

i.MX 6UltraLite Applications Processor Reference Manual

Best regards
igor

[paolobozzola]

Dear Igor,

thanks a lot for the hint, but we had the new manual version already, and we have wasted a lot of time to change settings inside the TSC registers as described in the manual's chapter, but nothing seems to change in behavior. I agree that it is a glitch issue (i.e.: a soft touch causes a detection but the ADC then converts a wrong X/Y position due to RTP membranes already moved apart) but changing register settings does not change nothing. Maybe we do some error but we are working on the original touch screen driver and any setting changes seems to be not working.

Do you know any updated driver for RTP which can enable thresholds or glitch-free behavior?

Any suggestion welcome

Thanks!

Paolo

[paolobozzola]

Dear Igor,

to cut away any doubt, we have done the following:

1. purchased fresh new EVK for iMX6UL, and its companion 4-3"  LCD + Touch (resistive)
2. plugged original uSD with original NXP image inside the uSD socket of the EVK mainboard
3. connected display
4. Powered on
5. When running, without any modification at all, we have made the touch calibration with the original utility
6. The desktop appears
7. Touching softly the blank desktop area with a finger or pencil, we see a lot of erratic touch behavior: sometimes the keyboard app is opened even if we were very far from it and did not touch it
8. then we have launched ts_calibration utility. It is alrready included in the original NXP image.
9. then we have run the ts_test utility, already included in the original image.
   By the way, THIS IS THE UTILITY WE HAVE USED TO DEMONSTRATE THE ERRATIC BEHAVIOR OF THE TSC INTERFACE
10. again touching softly we get the results of the attached photograph.
    
    AS you can see, even if with a 4.3" touch the erratic behavior is less evident than on a 7" touch, the wrong touches are A LOT.
    Every "spike"  you see is the line drawn between a good touch and a false (distant) touch which is falsely detected when we softly touch (or quickly touch) the resistive touch screen.
    This means that, when we use our controller's interface, for example if end user wants to touch the button area "run"  and there is (for example) a far away button like "stop" it is likely the controller is set to stop status even if the user wanted to run it! Because there can be a false touch detected in the wrong position!
    Really crazy.
    
    
11. This should give enough demo that the TSC block inside the iMX6UL has something wrong.
    Or we (and NXP, since we have above behavior using original NXP image) are doing something wrong???
    Missing proper s/w programming?

Now, the questions:

• is the TSC inside iMX6UL reliable or not?
• If yes, is there some special programming (not described in the manual) to make it running ok w/out false touch detection?
• If NO, why NXP is describing the TSC interface inside iMX6UL as " useable"  interface?
• Why nobody else could see such errativ behavior till now

Any help appreciated, ASAP!

Thanks

Paolo

[igorpadykov]

Hi Paolo

regarding "is the TSC inside iMX6UL reliable or not", there are some

verified POS designs below, which make believe that it is reliable:

https://www.nxp.com/docs/en/user-guide/POS-RS003SUG.pdf 

i.MX 6UltraLite SOM for POS applications from iWave Systems 

Probably your problems are related some specific configuration issues, for

such kind of support may be recommended Commercial Support and Engineering Services | NXP 

Best regards
igor

[igorpadykov]

Hi Paolo

unfortunately I am not aware of updated RTP driver with improved glitch-free behavior.

Best regards
igor