1. Home
  2. Embedded Programming
  3. Detecting/handling stuck keys

Detecting/handling stuck keys

My employer produces a medical device with a keypad that's had some reported cases of "stuck"/shorted keys. While others are looking in to a correction for the root cause of the hardware problem, I've been asked to investigate software detection of stuck keys so we can present the user with an alert that the device requires servicing.

Are there any applicable industry standards I should be aware of re: detecting/handling stuck keys? If not, any thoughts on high-level detection strategies? My primary concern is avoiding false positives - distinguishing between a stuck key and a user simply holding down a key for an abnormally long period of time, or storing the device in such a way that one of the keys is pressed down.

--------------------------------------- Posted through

formatting link

Reply to
Ed Laird
Loading thread data ...

You'd think every key handler would have a debounce timer. Can you use that to signal presses longer than some limit?

Reply to
mike

As well as another regular task to ensure debounce timer is running The debounce timer could have stopped if all keys do not respond or seems stuck on last key pressed.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate
Reply to
Paul

to a

IMO, before finding a purely software solution, you should work out the system requirements. How will you be able to make the distinction between a stuck key and a pressed key in storage. You have no workable time limit.

Should you have a time limit, you could simply poll the key state at regular intervals (say 1s) and declare a key stuck when for a given number of times (50), the key state has remained the same. Each key state change reinitialises the algorithm.

Reply to
Lanarcam

I'm confused about these. Seems if the user holds down a key for a long time and a stuck key message appears and then the user releases the key and the message goes away, there's no ill effect. Just word the message to speak about "possible" stuck key.

Again, if the unit is stored, why is it monitoring its keys? And if the unit is then "unstored" and the message goes away, what's the problem?

Reply to
mjsilva

Is there any reason the user would do that? We're simply detecting "press > N minutes" as a stuck key, unless there is a reason that the user sensibly uses that key this way (e.g. "fast forward"). However, we don't give him a popup, just a log file entry for the service.

If that's an issue, you'd have to detect sensible use. Like "if the device is turned on, and the first menu screen answered within N minutes (to detect spurious turn-on in a user's pocket), and a key is reported pressed all over the time, it's probably stuck".

Stefan

Reply to
Stefan Reuther

I've worked on two different types of products that have stuck key requirements.

Usually, a key is declared stuck if it is pressed continuously for around 2-5 minutes, and then the key has to be released before it will be recognized if pressed again.

This is clearly also a requirements issue ... depends on under what circumstances the user might hold the key for longer than 2-5 minutes, and what the consequences are if the software guesses wrong. Phrased differently, 2-5 minutes isn't a one-size-fits-all.

Also, you need to have a clear idea of how the hardware can fail and what you are trying to protect against (how does a key get stuck and what are its characteristics when stuck?). If a stuck key stays closed non-stop, then the strategy I've described above might apply. But if the hardware might fail differently, you'd need a different strategy. For example, for electrical or mechanical reasons, maybe a stuck key is a key that has remained pressed 75% of the time over the last 5 minutes. Perhaps not all stuck key faults are seen by the software as continuously pressed--depends on the failure modes.

Reply to
David T. Ashley

[...]

IMO, if the system *really* needed a requirement for stuck keys the hardware would have never passed the verification phase. So I would revise both the product requirements and the hardware verification process (if there is a requirement, why the 'stuck key test' was not included in the hardware verification phase?).

If the specifications did leave the 'stuck key' requirement out, it means that your goal is a 'nice to have', in order to reduce the amount of annoyed users. But as you correctly pointed out, you do not want to have 10% of currently affected users happy and annoy the rest which were happy before the 'fix'.

[...]

Couldn't agree more. Try to describe what is the signature of the hardware problem:

- what are the conditions? (hints on which parameter to check)

- what else is affected? (hints on which other parameter to check)

- any timing issue involved? (hints on 'race' conditions)

Work closer with the hardware team to understand what goes wrong and you may then implement a check over the condition depending on the hardware resources you have.

If the problem is not fully reproducible on a testbench then it will be hard to find the root of the problem and a solution to it, therefore invest in a setup which will reproduce the problem *exactly* how the failure will happen (simply testing your code keeping a key pressed will not help).

Reply to
alb

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.