How do microcontrollers fail?

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:
https://www.electro-tech-online.com/custompdfs/2013/06/doc11011.pdf

Could be any of the above, depending on the cause of the failure

Flyback said:

I am using a SAM3N00B microcontroller in an emergency light PCB.

Click to expand...

Seems kind of overkill for an emergency light. Why not use something simple like a low pin count device.

Seems kind of overkill for an emergency light. Why not use something simple like a low pin count device

Click to expand...

Its only just big enough to be honest. you'd be amazed at the processing that has to go on in an ELU

Flyback said:

Its only just big enough to be honest. you'd be amazed at the processing that has to go on in an ELU

Click to expand...

Yes I would. As far as I know, power goes out, light goes on. What sort of processing is required?

As mentioned a microcontroller crash is an unpredictable state.

battery charging............all kinds of mixtures of events like youre doing a self test and the battery goes down to 5.3V and so its a failed battery, you then have to signal this,

or youre coming up to a self test, and then it goes into emergency, so you have to remember when you come out of emergency that you need to do a 24 hr full charge before you can do your self test...........then you get an open cct load in self test, so you have to remember that that self test never got doen, and must remember to restart the self test from scratch when the load gets back, but firs t you again then need the 24hr full charge......the list of it goes on and on

Is this a homework assignment or school project? Who specked out the design? Can you post a block diagram or schematic?

Based on what you described seems you could do that with any old off the self 8bit micro. Microchip used to make a PIC14000 that was pretty much designed for UPS's and battery charging and that thing is obsolete but was very reliable. I'm just gobsmacked that the design for an emergency light would max out a SAM3N according to you.

The SAM3N is more for running a feature phone or something that actually needs the processing power.

We are using virtually all the pins on it.
Also, i appreciate its a high end processor, but its very cheap on price.
We also have to do many calculations as in working out 10% current levels for emergency operation when the customer selects this.
Its not homework, this is real, and weve just had the first shipment of 1000 5-D-cell Nicd batteries for our first few customers.

If you can show me a 64 pin micro that can do multiplications and has a DAC on it and its cheaper than sam3n00b then i'm there....but i doubt you will

Flyback said:

If you can show me a 64 pin micro that can do multiplications and has a DAC on it and its cheaper than sam3n00b then i'm there....but i doubt you will

Click to expand...

The ATXmega series from atmel could do it (ATXMEGA64A3U). Same number of pins than sam3n00b, but more IO. Two 12bit DAC, 16x12bit ADC. It is 8/16 bit AVR, but I doubt you need the processing power of 32 bit processor. Well.. anyway, I don't think you should change your processor.. just answering to your "challenge"

I too got interested how it is possible that you need so many IO for an emergency light. But, it also sounds like the device is a lot more than simple emergency light. What kind of communication interfaces does it have to outside world?

Sounds like your software project is quite complicated. The device will most likely fail due to software bug, than the microcontroller failing electrically/physically.

it doesnt have comms to outside world.....other than dipswitchs which customer sets to give emergency lighting level............the customer removing the battery and replacing it also allows the cust to get an instant power level calculation.

Flyback said:

the customer removing the battery and replacing it also allows the cust to get an instant power level calculation.

Click to expand...

How? Does it have a display?

Flyback said:

battery charging............all kinds of mixtures of events like youre doing a self test and the battery goes down to 5.3V and so its a failed battery, you then have to signal this,

or youre coming up to a self test, and then it goes into emergency, so you have to remember when you come out of emergency that you need to do a 24 hr full charge before you can do your self test...........then you get an open cct load in self test, so you have to remember that that self test never got doen, and must remember to restart the self test from scratch when the load gets back, but firs t you again then need the 24hr full charge......the list of it goes on and on

Click to expand...

But all still very simple and basic, and easily done in a far simpler and smaller device.

I would separate the actual "emergency lighting" functionally, which needs to be extremely reliable, to its own (small) microcontroller and put all the diagnostics etc "less crucial" thing to another microcontroller. I don't think you should optimize too much for price in emergency devices. Here are some reasons why I would separate them.

- You can separate the "emergency" part of the code to its own project. Keep the code as simple as possible. This way it is easy to test, debug and proove that it is reliable. This will save you cost also.
- You will most likely modify the diagnostic software more frequently than the emergency part of the software. And the diagnostic software is propably more complicated than the actual emergency software. Keep them separated in two different microcontrollers and you can safely develop the diagnostics without the risk of breaking the emergency part and without the need of constantly test/debug/proove the reliablitiy of the emergency part of the software.
- The two microcontrollers could monitor each other for failure.
- The diagnostics microcontroller can backup the emergency microcontroller if it fails.

I would separate the actual "emergency lighting" functionally, which needs to be extremely reliable, to its own (small) microcontroller and put all the diagnostics etc "less crucial" thing to another microcontroller

Click to expand...

..now that would have been very nice to do.............but two micros on a PCB is much more expensive.......and im talking about production cost...because if youve got two micros, then youve gotta have trained staff who know which software to load into which micro..........and you inevitable need different programming fixtures, so that they dont program the right microcontroller with the wrong code.

Originally Posted by Flyback

the customer removing the battery and replacing it also allows the cust to get an instant power level calculation.
How? Does it have a display?

Click to expand...

.....................no i mean the micro will do a 10% calculation for the emergency current level........it repeats this and increases the level if it sees an increase in lamp current....but if it sees lamp current reduce, it wont reduce the 10% level, as the reduction could have been due to dimming....so if the customer really wants a reduction in 10% level, then they do this thing of removing and replacing the battery which resets the micro.....Alles Klaar?

But all still very simple and basic, and easily done in a far simpler and smaller device.

Click to expand...

Could you name one..?..id be surprised......the software spec which i wrote is humungous, all the events and interacting events is phenominal............it really us hods of software

In answer to your original question: test it. Zap the thing with ESD, spray it with liquid etc etc. Test all the common scenarios where it might go wrong and then some more. Investigate what protection mechanisms exist on the port pins, what input buffers and output drivers they use. I have skimmed the datasheet (and searched for 'esd', 'diode' and 'protection') and not found much, but it might be in a different document.

I am genuinely interested in why you need so many pins. Can you provide a rough breakdown of what they are being used for? e.g. "10 pins for DIP input, 2 for voltage measuring, 2 for the clock crystal".

Can you post a photo of your PCB? If this is going to be a commercial product you should consider getting a someone who knows what they're doing to look at the design before going into production. You'll also need electrical approval depending on the country.

I simply can't fathom how a simple thing like battery backed up emergency lighting device would need any real processing power or I/O. Can the DIP switch features be simplified or made automatic? After all how many light levels does it need and battery replacement and recalibration should be automatic IMO.

PS are you still using NiCads? Do they even last more than a few years?

Nicad is THE technology of the emergency light................miles cheaper than NiMH and more robust....emergency capable nimh's have to custom built, and cost much more......normal nimh just cant handle the constant trickle.
Theres an external eeprom which logs the sytem time so that it knows when to do the self testing....so thats a few pins gone...........the programmign and debugging connector needed its own (10) pins otherwsise one needs loads of components to isolate the programmer debugger.
External reference needed a pin.
4 ADC pins...overtemperature, Vin, Vout, Iout
One DAC
Overvoltage latch release..one pin
Short circuit output sense....
Mains on off sense
charger on off
Hardware wacthdog pulse
bias suply enable disable (wee booster converter)
Led driver enable
Led driver bias voltage for dimming
Hardware overrid for self testing
3 dipswich inputs
2 led indicator outputs
Software test switch
software test chipled
software debug pin (just via)
Lots of the pins are just Vdd
Lots of the pins are internal Vsupply (core voltage)
One 32.7684KHz crystl
board is only 4 layers, and you need to have a few spare pins so you can choose which one to use , being easiest to route back to

Flyback said:

Its only just big enough to be honest. you'd be amazed at the processing that has to go on in an ELU

Click to expand...

flyback.

You should assume that any 'safety critical' equipment that you design and build will fail, the condition you have to design for is 'what state does the 'controlled' process fail too.??

A critical system should be designed to 'fail safe'.

You have to decide what is the 'fail safe' requirement.

I would add, without intending to offend you, that you do not appear to have sufficient knowledge and experience to design a system/product that others may have to rely on in hazardous circumstances.

E.

Safety devices are expensive because they go through exhaustive testing. I don't like the fact that you are trying to cut cost in hardware/production (few ten cents here and there). Testing is the most expensive part of your design/production chain. When you pack all the functionality in one big microcontroller, you will have tremendous job testing and debugging the system. Design a quality product and the price will be what it will be.. safety products always cost money. And people will pay the price because they have to. Safety first.

I would add, without intending to offend you, that you do not appear to have sufficient knowledge and experience to design a system/product that others may have to rely on in hazardous circumstances.

Click to expand...

Totally agree with you....thing is, the expert design consultancies who claim to know what theyre doing, charge an absolute fortune. I don't.

Speaking of expert design consultancies.....its amazing how many of them take shortcuts without telling the client..........for example, one consultancy charged $40000 for a LED light which was in a tiny package and switching at 1MHz......the only reason they got it so small, was because they used 1206 sense resistors (in each led string) dissipating 225mW each...on pads that were abs min. The 225mW was with perfect equal sharing in the paralleled leds.........with unequal sharing, these 1206's would obviously dissipate more than 225mW.


The biggest cracker i saw was a company who designed a smps for a telecoms unit............were talking of a telco company youll know of..............i took one look at the feedback and coudl see something was amiss.....i told the gaffer, and he changed the opto to a same-part-number-different-manuf, and it oscillated so bad it put sidebands on the mob phone signal and was unusable......all 1000 proto units in the field had to be recalled.

Another cracker was a offline device with a reg in it consiting 2 off 5V zeners in parallel.....yes they didnt share.....yes they blew in the field....yes the custoemrs were angry.

The best had to be this software guy who programmed undertemperature shutdown into a device without telling anyone.......the temp sensor was very inaccurate and cheap......that nearly closed down the company concerned.

I went to one place and found 5 overvoltaged resistors in a small product which had just gone into production and was with customers (were talking alomost 240V on 0805 resistors. (duty one half).......i said i was leaving unless they ordered it be fixed...when i went into the car park after work.....my rear tyres had been let down, and the valves glued up.

I can list many more of the nice shortcuts that the expert consultancies take.