Electronics Product Development: 3 Tips for Detecting Touch Controller Failures
In electronics product development, touchscreens can be difficult to stress test; and whilst there are several sophisticated systems available for touchscreen stress testing, there are other ways to get the job done – like a low-tech approach…
For example, take a look at this rig built from a child’s toy. Our engineer built it as part of the debug process to try to fix a failed touchscreen unit.
Thanks to our brightly-coloured debugger, we discovered that the touchscreen controller chip itself was unreliable. The rig kept tapping the screen over and over and over again. However, what the debug process uncovered was that it took slightly more than a mere tap-tap-tap motion to uncover the bug. So:
Tap-tap-tap motion = unit functioning normally.
Tap-slide-and-up motion (closer to an actual human movement) = bug activated, problem re-created
The rig was built as it would take many, many hours to reproduce the problem. As it turned out, it took anything between 1 and 6 hours before the touch screen controller chip malfunctioned.
The situation can be a lot more complicated when you have multiple systems interacting or multiple components within the same device – all on the same communication bus for example – causing some kind of combinational problem. This can be very difficult, especially since it can be that adding debugging into the system actually changes the behaviour of the system.
Touch Screen System
A touch screen system consists of a number of different components. First a touch sensor chip, senses changes in a resistive or capacitive sensing element (the touch screen). This communicates with the application processor over a serial link typically, perhaps with a separate interrupt line.
A software driver, as part of an operating system reads back the location over this serial port and then passes the location changes to the application software.
As such, bugs can occur in any of these components, and it is important at an early stage to locate in which part of the system the bug is residing.
Recreating the Bug
It’s a well-known maxim; the more debugging you put into a system, the better behaved the system is, because you’re adding additional delays or you’re single threading the system – when, actually, what you’re seeing is a combinatorial problem.
Once you can recreate the bug you can then progress to either curing or mitigating it by working round the problem.
Depending on the device and the actual bug(s), stress testing touchscreens can be a very difficult stage of electronics product development.
The most challenging issue can be to try to reproduce the problem in the first place. Once you can do that, then it’s really a question of time and effort, and understanding the problem as quickly as you can. This way, you can minimise the number of iteration cycles to try different fixes (as clearly each one takes a long time!).
Dealing with Drivers
When you’re developing a driver, it’s relatively easy to determine – at unit test level – whether the driver is functioning or not.
There can be subtle interactions in the system where the action of another driver can interfere with a particular driver; for example, they’re all using the same communication bus or it can be some type of interaction with the system overall or with the user. So, being able to understand all of those to be able to recreate the failure scenario is the most important thing.
The point of doing the stress test is that it takes a long time to reproduce that particular bug. If you can take that away from someone having to manually reproduce the test, then clearly that improves your productivity because you can work on some other task, while that’s happily working in the background. Just be sure that you have enough remote logging in place to discover exactly what’s happening.
Electronics Product Development – Our Top 3 Tips for Detecting Touch Controller Failures
As you can see, stress testing touchscreens during electronics product development can be very demanding. Follow our top tips to take the stress out of the process:
1. Understand the Dynamics of the Problem
Understand as quickly as you can at what level the problem is occurring eg hardware, driver or application. Think from the user’s perspective – what are they doing to the system that’s causing the problem?
In this case it was that they were touching the screen, sliding across the screen and then releasing at some other point, as opposed to just tap-tap-tap on the screen.
Maybe the issue is one of accuracy at a single point; so, for instance, could be related to a noisy touchscreen signal. Or perhaps the bug is related to an actual operation that is created by the use of the touchscreen, e.g. dragging an icon on the screen. This would indicate that the bug is at a higher level in the software – in this case at an operating system level.
It is therefore important to establish what repeatable action causes the bug to establish the part of the system that is faulty.
2. Add Debug Information
Next, think about what the potential causes could be, and add debug information around these. This way, when the bug reoccurs, you can identify it as quickly as possible and understand exactly where it is happening.
3. Prevent – or Recover From – the Problem
Here’s the crucial question to answer at this point of your electronics product development:
“Is there anything I can do to prevent the problem from happening? If not, is there anything I can do to recover from the problem?”
It’s best to work on both of those at the same time if possible; it may be you can’t fix the problem, but what you can do is identify when the problem occurs, take some corrective action and the user doesn’t see any problem at all.
It could be, for instance, that noise means that averaging of values is required to establish a reliable position. If a touch screen chip is locking up, then a wakeup, or reboot of it may be required as a workaround (frequently these devices are embedded in the display, so a hardware fix is not possible).
Interrupt Priorities May Need Changing
As is often the case in systems design, the touchscreen driver requires a trade-off between several conflicting requirements such as responsiveness vs accuracy and processing time vs reliability. Therefore, the designer must adjust factors such as settling times, sample depth, conversion rate, noise rejection & filtering, interrupt priorities and thread priorities.
Above all the driver must co-operate with all other system elements so that all this happens in the background unnoticed by the user and without affecting other time-critical system tasks such as USB.
What are your top tips for debugging touch screen controller failures? Let us know, it’d be great to hear from you! Connect with us on social media or via the website.
