1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Error/Beep/Blink codes

Discussion in 'Embedded' started by D Yuniskis, May 2, 2011.

  1. D Yuniskis

    Arlet Ottens Guest

    My last motherboard had a BIOS that would use speech output to tell me
    what was going on.
    Arlet Ottens, May 5, 2011
    1. Advertisements

  2. 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.
    robertwessel2, May 5, 2011
    1. Advertisements

  3. D Yuniskis

    D Yuniskis Guest

    Hi Robert,

    On 5/5/2011 12:08 AM, wrote:

    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

    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.
    D Yuniskis, May 5, 2011
  4. D Yuniskis

    upsidedown Guest

    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.
    upsidedown, May 5, 2011
  5. 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 Clubley, May 5, 2011
  6. 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.
    1 Lucky Texan, May 5, 2011
  7. D Yuniskis

    D Yuniskis Guest

    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

    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
    <any number of other things>

    (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


    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.
    D Yuniskis, May 5, 2011
  8. D Yuniskis

    Thad Smith Guest

    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 Smith, May 13, 2011
  9. [ 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, May 14, 2011
  10. D Yuniskis

    D Yuniskis Guest

    Hi Albert,

    On 5/14/2011 7:22 AM, Albert van der Horst wrote:

    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".
    D Yuniskis, May 14, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.