Hi,
We are experiencing an issue with the resistive touch in our iMX7 system under WEC2013.
During development, we were already experiencing the issue described in: https://www.toradex.com/community/questions/36840/resistive-touch-not-always-responsive.html?childToView=46229#answer-46229
We mitigated this issue by using an approach based on the mouseDown event which seems to generally work ok in our case.
Nevertheless, we experience, in a rate of about 1 out of 30-100 clicks, that the mouseDown event is detected at the wrong position (we have a test application in C# that draws the position of the event) compared to where the click was performed physically on the touch panel.
Following inputs from our touch screen manufacturer we adapted the available parameters of the touch controller via the registry (Resistive Touch Screen on WinCE | Toradex Developer Center). The best results are achieved with a short acquisition time (“AcquisitionTime”=0 / 2us) and still a bit of warmup time (“FirstConversionDelay”=7 / ~1ms). The filtering helps as long as we keep a ratio of 2:1 between the filter size (“MedianFilterSize”) and the averaging (“Averaging”).
Despite these efforts we still experience the issue and since we use the interface to remotely control systems/machines an erroneous input could potentially be extremely problematic.
Note that the design already passed CE certification. We also tried to additionally shield the touch flex cable and the lines on the carrier board (with copper tape) without any visible positive impact.
How would you suggest to solve this issue?
Many thanks in advance for any input.
Regards, Thomas
It sounds more like a HW issue. Could you share your test app (binary and source)? I’ll try to repro your issue on our hardware.
Hi,
What type of HW issue could it possibly be in your opinion?
The interface is pretty straightforward. Close to the touch connector we have on each line a small cap (1nF) and a TVS (D1213A-01LP-7B) followed by a ferrite bead inline (not present in previous version but the reported problem was). We then go directly into the module.
I inspected the electrical signals while triggering events. I must say I could not spot something really special when the problem arises. What would you be looking for while inspecting the signals?
By the way, I started looking at the AD7879 setup by reading the configuration with the I2C from my application. It seems the controller is in master mode and uses the DAV interrupt (if I am not wrong). Could it be that the driver does not check the DAV level before reading out? Depending on the timing/interrupt response latency it could then lead to an erroneous value. Would that be a possibility?
It could be a lots of possible HW issues like interference from the display circuit, insufficient amount of decoupling capacitors, touch panel mechanical issue, bad cable connection etc.
If it’s a software issue it can be reproducible on all HW setups. I’m ready to do same tests as you did if you share a your app.
Here is a small test application (written in C#) running on WinCE8. It’s quite straightforward. It simply draws a small rectangle on the position of detected mouse events on the form. With the checkboxes you can enable the mouseDown or Up events. The clear button clears the stored list of previous events.
To produce the issue I usually use a rather sharp “pointer” (it tends to happen more that way than with fingers) and click on the display in a given small area. Out of about 30 to 100 clicks I see a rectangle completely out of the area.
test application
Regarding your remarks on the possible causes. Please note that following inputs from the display manufacturer we already tested the touch by having the display totally unmounted from the product enclosure (to rule out possible mechanical stresses on the frame of the touch). The reported issue was still present in this case.
I’ll run some test today. Do you mind to share source code as well?
I’ve run your test app using Colibri Evaluation board and 7" resistive touch screen
I’ve flashed a fresh WEC 2013 v1.2 image and install .NET CF - Toradex Documents - Toradex NET Framework 3.9
I’ve made around 1000 touches using stylus and haven’t found any inconsistency with touch position detection when “mouseDown” only events detected.
However enabling “mouseUp” events shows issue you reported.
However enabling “mouseUp” events shows issue you reported.
I also have the issue with the mouseUp events with a much higher rate than with the mouseDown. But I still have the mouseDown happening every about 100 clicks (best I can do by optimizing the parameters described in Resistive Touch Screen on WinCE | Toradex Developer Center). As stated the issue is more apparent by using a “sharp” pen pointer to click.
I have the issue on both events if I select only one or both with the checkboxes. The checkboxes only define if we store and draw the points in the test application.
Please find the sources of the sample code attached Sources
Again, note that this problem could also explain the behavior with normal clicks (that we also experienced) in https://www.toradex.com/community/questions/36840/resistive-touch-not-always-responsive.html?childToView=46229#answer-46229
If you are looking into the drivers for the touch, please also check how the “FirstConversionDelay” parameter is written in the AD7879 when defined in the registry.
I noticed that only the two lower bits (out of 4) are actually written in the AD7879 when I change this parameter. I could easily set values higher than 0b11 from my application using the I2C library but not with the registry.
OK MouseUp position could be wrong due to nature of resistive touch screen. So lets concentrate on mouseDown event. Per my tests (with default registry settings) all mouseDown events ware registered correctly. I did more than 1000 touches using touch screen stylus, pen and even small phillips screwdriver.
I did check driver source code -
Controller works in a master mode with PEN_IRQ enabled. So DAV interrupt is not in use. However it shouldn’t affect data read. PEN_IRQ is fired only after first sample conversion is done. So data should be valid.
I still believe that you have a HW issue.
However I’ve discover some problem with SW averaging at driver level. It works OK with default values (dwSamples=1). But if you set it to other value next reads do not wait till end of conversion. Looks like you are not using it, so it shouldn’t affect your readings.
I’d recommend to set dwSamples=1 (or just delete it), ConversionInterval = 0 and play with HW filtering - “AcquisitionTime”, “MedianFilterSize”,“Averaging” plus “FirstConversionDelay” (yes it limited to 2 bits if set by registry) and “AcquisitionTime”.
I’d set “MedianFilterSize” to 3 (16 samples) and “Averaging” to 1 (4 samples) or even 0 (2 samples).
Did you try to use that screen with Iris board?
Ok.
Well, when I read the configuration registers of the AD7879 from the application I had the following values the other day (readout done on startup of the app not on a click):
Cnt1 = 0x8cff
Cnt2 = 0x8023
Cnt3 = 0xD0F0
Bit15 of Cnt1 = 1 (PENIRQ disable) seems to indicate that PENIRQ is disabled according to the datasheet.
Bit13 of Cnt3 = 0 (INT mode) seems to indicate DAV interrupt mode.
Is there something wrong in these values (the only changes from default are some registry parameters for the touch)?
I cannot to find any documentation on dwSamples or ConversionInterval. Are these registry configurable? I introduced them in the registry (suggested values) and played with the other parameters but to no avail (we already made quite some tests with all these parameters before contacting you).
I cannot hook up this display (Display Visions EA TFT070-84ATP) directly to the Iris. The RGB interface is not 100% compatible unfortunately.
Sorry dwSamples is variable name registry key is “Samples”. It’s from Microsoft tchmain.c and define number of touch coordinates readings for SW averaging.
“ConversionInterva” is 8 bits value written to LSB of Crl1 i.e. AD7879 Conversion interval timer.
I’ve double check ctr1 setting and can confirm that you are right - PENIRQ disabled and DAV enabled. But it doesn’t change driver behavior - it reads data after interrupt. Please see a picture of test screen after 500 touches made by small screwdriver.
Ok, thanks for clarifying the parameters and the driver behavior.
How would you try to pinpoint the source of the problem if it was HW related? Any suggestion?
I’d start from finding which part is causing problem - touch screen, display or carrier board.
-
Fully disconnect display interface from your CB but keep touch panel connected. Use the Remote Display for GUI
-
If problem still exists, connect touch panel cable only to Iris (use VGA monitor or RemoteDisplay for GUI)
-
If problem still exist you can connect a Toradex provided display to your carrier board (just a 4 touch lines is enough). You can also verify that display with Iris board.
I tested the following:
-
Fully disconnected display with touch only on our carrier board. Feedback on Remote display
→ Issue still present
-
Connected the touch only to IRIS CB. Flashed and tested standard images WEC2013 v1.2 and 1.3b2. Feedback on VGA on external display
→ Issue still present
I will receive another completely different touch tomorrow and proceed with your last proposal.
I tested with another touch display (other brand) on our custom CB (again connecting only the touch and using remote display for visual feedback). This other touch display was used extensively in some of our other products (other processor platform) and never did cause any trouble with the touch.
Unfortunately, the issue was still present. I will still test this display with the Iris to have a complete picture and post my results when available.
