Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Microcontroller failure modes?

Status
Not open for further replies.
T

treez

Guest
Newbie level 1
I am using a SAM3N00B microcontroller in an emergency light PCB.

We have to make provision for when the micro fails.

But when it fails, will the pins be..

1...High impedance
2...'stuck' logic high
3...'stuck' logic low
4...a combination of the above
?


SAM3N00B DATASHEET:
http://www.atmel.com/Images/doc11011.pdf
 

A watchdog doesn't help with microcontroller failure - only with a working microcontroller which has managed to get stuck with a software bug or where the function has otherwise been corrupted temporarily.

My information is probably out of date, but failure analysis used to consider any pin could be shorted to any pin and any component could be short or open. I seems to remember it being acceptable to only consider resistors going open not short circuit. This was back in the days when the standards were 'British Standards'. The European ones may be different.

Keith
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
Perhaps this is an over-simplified answer but as a micro can fail in almost any condition and even randomly produce varying signals, the most obvious solution would be a manual switch that electronically overrides the micro's output.

Brian.
 
  • Like
Reactions: treez

    T

    Points: 2
    Helpful Answer Positive Rating
Regarding hardware failure, I agree with Keith that case 4 should be considered.

But that's only part of the problem. There's also a possibility that the µP seems to service the outputs as expected (e.g. sending a watchdog trigger sequence) but is no longer acting on input conditions due to software faults or corrupted binary image. So software safety must be included in a failure analysis. There are different standards for software safety and respective compliance requirements in application specific standards.

For moderate requirements as probably applicable for emergency lights, repetive RAM and ROM integrity check (CRC) together with an external watchdog forcing a safe state (e.g. "light on") might be sufficient, or software safety is simply ignored in the regulations.
 
  • Like
Reactions: treez and tpetar

    tpetar

    Points: 2
    Helpful Answer Positive Rating
    T

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top