Error/Beep/Blink codes

Yes, that's what I've seen in many BIOS's.

But, I am questioning the cognitive load that it imposes on the user. I.e., he has to count the number of beeps in the "current digit" while *remembering* the number of beeps in previous "digits".

At what point does this become a source of error? Are there other "encoding methods" that are *less* error prone?

My last motherboard had a BIOS that would use speech output to tell me what was going on.

Simple as you like. Say "System error, please call support, write down this number: 1..2..3..4..5..6..7". That one canned message plus the digits needs about 10 seconds of recording time, and you don't need to process anything more complex than the waveform files. A crude text-to-speech (probably synthesized phoneme based) is also possible, if a bit more work up front, and gives you a great deal of output flexibility. Since you're generating all the messages, you can code them as the required phonemes rather than normal text (that kind of synthesizer can be quite small, but will definitely sound artificial). Shorten it if you have space limitations, you could just do the digits. You could even just do four digits, and output the code in base-4.

It doesn't have to sound fantastic, after all, just intelligible to a user with an otherwise dead system. It would certainly be friendlier than beep codes.

[8>> >>>> Taking audible annunciators, first...

But 10 seconds at even 32Kb/s (the low end for "phone quality audio"?) is already more than an entire (crude) synthesizer! Plus, you need to add the *code* to run the CODEC (decoder).

Yes. Eliminating the "text-to-phoneme" portion of the code saves you a few (5?) KB. IMO, not really worth the hassle as it forces you to limit what you can "say", artificially. And, the computational load required for this phase is pretty trivial (esp if you restrict the vocabulary that you use)

Understood. But, doesn't help in applications that don't have audio (or, don't have a "full range" audio driver/speaker). And, is a bit heavy on computational requirements (for low end processors).

I am hoping for a scheme that doesn't care (need to know) what the actual representation of the "code" will be at presentation. E.g., blinks and beeps *can* have an inherent duality.

This is good as long all your users understand English :-).

If you ship your products world wide, either make regional versions of it or have some means of selecting the language _before_shipping_. Of course the language selection DIP switches/flash may also fail .....

I am not quite sure what the OP is actually trying to do. In practice, if the system suffers a catastrophic failure, the most likely user action would be to restart the device (based on past experience of bad devices locking up :-).

Thus, the problem is simplified to the Power Up Self Test (POST) sequence. If it is a persistent failure, then the problem will reappear during the POST and indicated by means available at that particular phase of boot sequence.

The POST sequence should initially only check for resources that are needed by the following stages (and reporting error in them), thus the number of errors that needs to be reported with a single flashing LED is quite small (such as missing or faulty RAM, run the check code from ROM and use only internal registers).

In the next stage some speaker/sounder can be driven with PWM from a binary output pin and then to check the availability of sound card or display adapter etc. and if verified good, use these for more expressive error messages.

Rather than use just one LED to blink a fault code, I wonder if the product has more than one LED attached. If so, a fault code can be written out in binary to the LEDs. If the product has just 3 LEDs, that's 7 different fault codes available right there.

To distinguish from normal operation, the code driving the LEDs can just flash the binary 1 LEDs at a rate of, say, once per second.

All you need to do then is ask the end user which LEDs are flashing without having to worry about asking them what pattern they are flashing.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

n

Plus, you still have the multiple language problem.

I still think a sweep UP (maybe lasting a few hundred milliseconds) follwed by the 'tens' digit in beep-code, then a freq sweep DOWN followed by the 'ones' beep-code is doable. It has at least some logic to it, probably works over the phone, and could easily give 99 codes - maybe more. It doesn't translate well to visual directly, but you might be able to alter the duty cycle going to an LED to get a similar effect. long pause, UP brightness short pause, flash-code, long pause, DOWN brightness, short pause, flash-code.

Or, if the device is used by more than one individual with different language skills... how likely is it that the user will remember to reconfigure the all-else-fails error indicator when he starts to use the device (recall that you can't count on the higher level functionality doing this *for* you... since we are dealing with a case where that has failed or is about to fail)

Ideally, you want something that has universal recognition. Granted, the terms that a user uses for LONG/SHORT, HIGH/LOW, FAST/SLOW, etc. may vary from language to language but the

*concepts* don't!

I'm trying to protect against "failure to perform as intended". That can be because of a hardware failure, a user failure, a software failure, etc.

E.g., returning to the laptop analogy I used earlier...

If the inverter for the CCFL's fails, the display is rendered unreadable (to the majority of non-technical users). So, to rely on that mechanism to communicate with the user (i.e., imagine if the software can monitor the HV output of the inverter and *knows* that the display is unreadable!) is meaningless.

Similarly, if the display interface (API) crashes, you have the same constraint (different reason).

This would catch the bad inverter problem (though still leave you with the need to convey this information to the user, in some form!). But, the crashed API will slip through the POST/BIST until whatever set of circumstances reappears. At which time, you're stuck with the same problem of conveying this to the user.

Battery has insufficient charge to bring up other devices Charger failure Earphone disconnected

etc.

(Believe me, I've been down this road many times before! :> )

*If* there is a speaker to drive! :>

Designing robust BISTs is part science, part art. You have to think in terms of baby steps and the types of things that are likely to "go wrong" (user/hardware/software).

E.g., with an MCU/SoC design, you first start with resources that can't be as easily compromised. So, you *start* the BIST using internal ROM/Flash (as an external bus could be compromised more easily than an internal one). First step (after ensuring the hardware is REALLY reset and "made quiescent") is a tiny routine that checks the integrity of it's "successor routine". I.e., verify the integrity of the *full* BIST routine before you transfer control to it.

You don't use RAM until you know it works -- at least the portion that is pertinent to you. You don't use timers until you know

*they* work. You don't use external resources until you can assure yourself that they are well-behaved (imagine if something, once enabled, misbehaved and hammered on an IRQ at some high frequency).

Etc.

And, while you are doing this, you are dropping breadcrumbs so an outside observer -- as well as "you", the BIST -- can watch the progress and know on subsequent attempts what to *avoid*.

Personally, I find writing these things to be a really fun project! (assuming the hardware has been designed with this in mind) It's like a contest between you -- and yourself! Trying to anticipate everything that can go wrong including the code you are writing and its assumptions.

The solution is to loop through several iterations. It's like replaying a recorded phone message when the callback number is rattled off at 4.5 digits/second.

--
Thad

[ OT Being on intensive care a couple of weeks ago, I can testify that a heart monitor doesn't bleep, except in films. It would keep you awake all night. In films it is a nice dramatic touch if you have an actor who doesn't know how to die. ]

In my ciforth systems (also on Renesas and 6809) it works like this. Each error situation is identified by a number. On error always the text "ERROR " and the number in decimal is output *immediately*. Then an attempt is made to get a one line description from the back ground device, and if that succeeds that is printed. If a user is clever enough to note the number, he can find information pertinent to what could cause the error in the documentation. I could be called weakly tiered ...

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[8>>> This last level is roughly the equivalent of BIOS

Presumably, you didn't take that opportunity to "expire" ;-) (hope you are well)

ROTFL! Yes, good point!

Actually, most of the "sound" is that from medical staff. One wonders if they've ever *thought* about how noisey their activities really are -- especially to a patient who may be having trouble getting sleep as it is (hourly wellness checks, etc.)!

This is similar to many common protocols: error number (which can be parsed by a piece of code) followed by a terse "description" (which often sheds very little light on the problem *or* remedy).

In my "top tier" (for want of a better term), each *point* in the code that can generate an error is "tagged" (even if more than one point can "signal" the "same" error). These are then mapped through a database/expert system to a "likely cause". This, in turn, produces an index into the device's documentation (all documentation resides *in* the device).

So, instead of a one-liner, the user is treated to a description of the problem and likely remedies (this is available in increasing level of detail -- no need to bother an experienced user with a verbose description of an error that he may already be familiar with).

The "unique tag" for each error "point" in the code gives me extra information (i.e., it was this *line* of code that signaled the error) about the cause which can further refine "exactly" the nature of the problem (or, at least the code's delusions!)

But, for all this to work, *lots* of stuff has to work! I.e., the "manual", the interpretive agent (expert system), the error signaling mechanism, etc.

So, if parts of this "reporting system" aren't operational, I fall back to cruder means of conveying information to the user. If all else fails, beep/blink codes (as they impose the least dependencies on the remaining system). I.e., I trade off the amount of assistance I can provide to the user for the guarantee of being able to "get the word out".