Atmega328pb is getting hanged after weeks or months.

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

We have made a product by using Atmega328pb. 

Peripherals used:

All timers

UART

Almost all GPIO

EEPROM

 

Software Atmel Studio 7

 

Suppose we have produced 10000 devices. and all devices is ON 24*7.

But the problem is out of 10000 devices few devices like 5-10 devices is getting hanged(no response or random behavior) randomly and when I am restarting the device  it starts working normally or very few gets permanent damage.

What would be the root cause like code issue, hardware issue, power supply issue?

And How can I resolve this issue.

Please help me out.

Thanks in Advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

imrana326 wrote:
What would be the root cause like code issue, hardware issue, power supply issue?

 

Could be all three. How about lightning or static discharge?

 

How to resolve it? What testing have you done? 

 

Unfortunately, you've given us little information to help you much further.

 

Do not underestimate how difficult this problem is to solve - what evidence have you collected?

 

I'm frequently called upon to fix these sorts of problems:

1. review the hardware - does it have adequate protection for the expected environment it will be deployed in?

2. review the software - does it have reset detection? watchdog? buffer overflows? stack usage?

3. of the devices that have a hard failure - have you determined what exactly failed? Is this common to all the failed devices?

4. Has adequate EMC testing been performed?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could be an electrical transient, bad solder joint (probably not, but never say never).  Could be a stack overrun.  Could be a program bug or counter overflow.  An impossible logical condition that never should happen, due to bad decision tree, or faulty state assignment (stuck state).  It could be an infinite number of things  (division by zero, timer wraparound due to missed input, lost IRQ's, limit cycle logic, a deadlock, etc) ...so you need to start investigating.  Providing no clues here gives you few solid leads to investigate there.

 

You need to provide a description of the system, what it does normally & how it was configured when failing.  What do you mean by random behavior?

 

or very few gets permanent damage.

flames ? smoke?  burned out chips?  What do you mean by this?  

 

Are you making SSD's , by chance?

https://www.bleepingcomputer.com/news/hardware/hp-warns-that-some-ssd-drives-will-fail-at-32-768-hours-of-use/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Jan 22, 2020 - 07:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the stuff on the left side about the same?

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Maybe you should introduce watch dog into your code.

 

Anyways in my experience you should check:

- is the brown out detection set to the proper level? For example when I was using BOD 2.7V and when I hot plugged Text OLED display, the atmega stopped working, with BOD 4.2V it works (power drop causes reset but it works)

- full swing oscillator prevents many issues (like if you have serial lines next to xtal pins, it can cause clock failure or high noise environment). Bad news is there is no full swing oscillator option in PB version.

 

 

Computers don't make errors - What they do they do on purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

imrana326 wrote:
What would be the root cause like code issue, ...
Most likely though there's a plethora of possible causes that are multiplied by the possible effects.

imrana326 wrote:
hardware issue,
Less likely though still probable

imrana326 wrote:
power supply issue?
of hardware issues that may be the simplest to diagnose (hypothesis, design of experiment, implement experiment, perform experiment, evaluate experiment's results, repeat until issues are resolved)

imrana326 wrote:
And How can I resolve this issue.

  • Source code peer reviews
  • Regression tests (unit tests, integration tests, preferably both kinds are automated, Atmel Studio's AVR simulator aids this)
  • Pass the source code through a linter(s)
  • Add assertions
  • Static code analysis is one of the best practices though a static analyzer has a steep price with some cost (though of value for is effective after one gets over the learning curve, some trials are zero price)
  • Atmel Studio and stack overflow detection (does debugWIRE OCD have enough data address comparators?)
  • Hardware peer reviews (AVR040, AVR042)
  • Most power supplies are conditionally stable; replace with an unconditionally stable power supply, experiment
  • Wall warts are a personal bane

 

P.S.

imrana326 wrote:
Almost all GPIO
An entire spare AVR port eases use of a logic analyzer though a few bits are still of use.

 


Adding Automatic Debugging to Firmware for Embedded Systems

Jack Ganssle's "Reason #4" on why embedded software projects run into trouble | AVR Freaks

8 tips for squashing bugs using ASSERT in C | EDN

Static Analysis v. Assertions | The Embedded Muse 380

Firmware Update v18.03 | Barr Group

[3/4 page]

The State of Embedded Systems Safety

Atmel Studio 7 - Stack Overflow Detection Using Data Breakpoint

AN_1619 AVR040: EMC Design Considerations

AVR042: AVR Hardware Design Considerations

Troubleshooting real-time software issues using a logic analyzer - Embedded.com

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The pragmatist in me says, for a < 0.1% failure rate in a non-safety-critical device: don't fret, just replace them. The cost of investigation isn't justified.

 

Or, is there a well-defined, non-zero cost associated with failure that might be reduced by solving the problem ?

 

Have you defined an acceptable failure rate (MTBF, MTTR, etc) as part of the project's non-functional requirements ? Are you meeting this target ?

 

I assume you're not making pacemakers or autopilots ;)

 

 

Last Edited: Wed. Jan 22, 2020 - 03:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The first question I would ask is what BOD level is being used?

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

imrana326 wrote:
We have made a product by using Atmega328pb. 

...

... power supply issue?

clock issue? (power and clock for a digital device then the device should start)

  • PB megaAVR have CFD
  • Later model AVR have increased ΔtCLCL (XMEGA, unified memory AVR)

Excessive di/dt under a MCU may cause an upset (clock, program counter, etc)

ATmega328PB - 8-bit AVR Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

KIIV_cz wrote:
Maybe you should introduce watch dog into your code.
That's a start; Jack Ganssle has an article on complete, precise, and correct watchdogs.

A principle of avionics is watchdogs are external to the MCU/MPU/AP; likewise with mechtronics.

Internal hardware watchdog, software watchdog, external hardware watchdog

KIIV_cz wrote:
Bad news is there is no full swing oscillator option in PB version.
Good news is there's no full swing high frequency crystal oscillator in PB megaAVR (reduced current therefore reduced power) though the set of crystals is reduced in size (reduced load capacitance, reduced range of ESR)

 


IIRC :

Great Watchdogs

 

ATmega324PB Xplained Pro

https://a.pololu-files.com/picture/0J8488.1200.jpg?bdbaf40a3cdebec848c4888ca8729910 via Pololu - A-Star 328PB Micro

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
The cost of investigation isn't justified.
The ones of Japan have a few (several?) concepts of improvement and quality that are in one word.

One of the many results of their work and effort is the beloved Toyota light truck.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
The pragmatist in me says, for a < 0.1% failure rate in a non-safety-critical device: don't fret, just replace them. The cost of investigation isn't justified.

 

One needs to learn from mistakes. Ignoring a problem is just digging a hole for yourself. Once the problem is understood, then you can decide on the financial cost.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

The ones of Japan have a few (several?) concepts of improvement and quality that are in one word.

Deming

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Ah, this Thread brings back memories nightmares!

 

I still recall a GPS project, plotted position on "map", GLCD display, etc.

It would crash, never predictable.  Could run for days without a problem, then suddenly it would crash.

I was soooo sure it was a hardware issue.

I tore up the breadboards and re-laid it out several times.

Then, on the chance it could be an old, (well worn!), breadboard with an intermittent contact I bought a new multi-board breadboard.

And I finally broke down and bought a logic analyzer.

And I spent hours and hours, over several months, debugging that project.

 

And then I found it!

 

In thousands of lines of code there was one line where if one of the many ISR's fired, there was a non-atomic access and the data was corrupted.

 

Fixed it in minutes, after months of headaches and lost sleep.

 

I'm over it now wink

 

JC

 

Edit: Typo

 

 

Last Edited: Thu. Jan 23, 2020 - 02:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
In thousands of lines of code there was one line where if one of the many ISR's fired, there was a non-atomic access and the data was corrupted.
Such is a part of a C coding standard :

CON43-C. Do not allow data races in multithreaded code - SEI CERT C Coding Standard - Confluence

with one linter for CON43-C :

[3/4 page]

Automated Detection

...

CodeSonar

...

 

P.S.

DocJC wrote:
I still recall a GPS project, plotted position on "map", GLCD display, etc.
In BASIC?

If yes there are BASIC linters though for Visual BASIC; maybe not a match for that project.

 


SonarCFamily for C | C static code analysis | SonarSource (C linter)

Visual Studio extension | SonarLint

https://gallery.microchip.com/packages?q=lint

Microchip Gallery | CppCheck Integrator (Beta) 1.0.0.9 (Atmel Studio 6, C and C++ linter)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

KIIV_cz wrote:
Maybe you should introduce watch dog into your code.
That's a start; Jack Ganssle has an article on complete, precise, and correct watchdogs.

A principle of avionics is watchdogs are external to the MCU/MPU/AP; likewise with mechtronics.

Internal hardware watchdog, software watchdog, external hardware watchdog

KIIV_cz wrote:
Bad news is there is no full swing oscillator option in PB version.
Good news is there's no full swing high frequency crystal oscillator in PB megaAVR (reduced current therefore reduced power) though the set of crystals is reduced in size (reduced load capacitance, reduced range of ESR)

 


IIRC :

Great Watchdogs

 

ATmega324PB Xplained Pro

https://a.pololu-files.com/picture/0J8488.1200.jpg?bdbaf40a3cdebec848c4888ca8729910 via Pololu - A-Star 328PB Micro

 

 

That was my first thought... the crystal oscillator. Not only is the full swing option removed, it also seems like the 328pb oscillator is even less reliable than an older AVR without full swing.

Does anyone know WHY full swing has been removed?

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

obdevel wrote:
The pragmatist in me says, for a < 0.1% failure rate in a non-safety-critical device: don't fret, just replace them. The cost of investigation isn't justified.

 

One needs to learn from mistakes. Ignoring a problem is just digging a hole for yourself.

 

I respectfully disagree, in certain circumstances. We don't know the commercial context of the OP's question.

It may be that labour is cheap, or it may cost $100s per hour. The cost of failure may be $5 per unit or it may risk losing a $1,000,000 customer.

 

>> Once the problem is understood, then you can decide on the financial cost.

 

That's back-to-front. You can't commit to an open-ended investment of engineering time to identify and solve a problem, and then look back to see how much it cost you.

 

It may be worth investing e.g. a week of an engineer's time, after which you stop throwing good money after bad. No product is perfect and sometime 'good enough' is good enough. Engineering resources are finite and the OP's time may be better spent on other activities.

 

Or maybe the OP's employer should invest that time and effort in better engineering, testing and quality management processes, so it happen less frequently in the future.

 

I guess I see too many bright, young engineers who have little or no commercial or management skills, and I'm trying to widen the discussion.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Krupski wrote:
Does anyone know WHY full swing has been removed?
Not me though that's more than a PB megaAVR characteristic.

18pF Crystals May Not Oscillate with Energy Saving MCUs | Abracon LLC

[third paragraph]

In particular, these advancements in silicon geometry have decreased amplifier/inverter’s transconductance, gm , in the crystal oscillator loop. The results are power starved oscillation circuits that are marginally functional. These circuits run the risk of failing to startup due to total capacitive loading, changes in temperature & bias levels, etc.

[bottom of left column]

It is evident from equation (1) [gain margin] that as the gm decreases, it is imperative to simultaneously reduce ESR, CL and CO.

[bottom of next to last paragraph]

It is widely accepted that the gain margin needs to be greater than (5) for robust oscillations, when accounting for board parasitics, part-to- part variation, operating temperature range and other unforeseen problems that could cause oscillation to cease.

Some USB UART have a clock output signal; similar was done for the ATmega328PB Xplained Mini

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are the ones that fail in different environments from the ones that keep going?

 

A simple, though perhaps slow technique is to replace all the ones that fail

and check whether they have a higher failure rate than the great majority.

 

In the interest of customer service, I expect replacements will include watchdog code.

Ideally the watchdog reset would record its occurrence and then tell the user that the

device is still working, but an event the manufacturer should know about has occurred.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
In the interest of customer service, I expect replacements will include watchdog code.
An internal watchdog can be disabled via latch-up; if current is limited enough then the AVR will not be destroyed.

An external watchdog can cycle the AVR's VCC to cease the latch-up and restart.

AVR don't have a specified ESD though very likely have a significant CDM capability; some AVR have a stated maximum injection current (one way to latch-up)

Most supervisor IC have stated ESD capabilities and may have a stated latch-up (current that the supervisor survives latch-up); some supervisors contain a watchdog.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

In BASIC?

 

If yes there are BASIC linters though for Visual BASIC; maybe not a match for that project.

 

Not to go too far off topic, but...

 

How cool.

I didn't realize there was a Linter for VB.

I have another VB program that runs 24/7, relatively mission critical, and it runs on its own, stand-alone, Win10 PC.

Yet every once in a while the program exits, and nothing is running behind the screen blanker.

Yet it doesn't seem to happen on my main PC on which I developed the code, where it can run for days on end without difficulty.

I'd like to attribute it to forced Win10 updates and reboots, etc., (which I know I now have control over), but I think the problem is more likely of my own doing.

 

Perhaps I'll track down the VB Linter and see if it can identify any issues that I can resolve.

 

I doubt there is a Linter for Bascom, unfortunately.

The compiler itself is pretty good at spotting some oddities, but it isn't a full Linter.

 

As I was Googling about to see what existed for a VB Linter I came across this Wiki Page on HeisenBugs, which also (briefly) discusses BohrBugs, MandelBugs, HindenBugs, and SchrodinBugs.

 

If I hadn't personally created a few of these odd bugs over the years I would have thought it was an April Fool's Day joke.

Sadly, such bugs are often far from a laughing matter.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You've not described the equipment in anything like enough detail for us to provide anything more than wild guesses.

 

My wild guess however is EMC/ESD.

Did your product and any associated equipment pass EMC susceptibility testing to the required test levels and scope ?

 

In my experience, anything but a solid pass in that respect will always come back to bite you, once you hit the sort of volumes you have mentioned.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

DocJC wrote:
As I was Googling about to see what existed for a VB Linter I came across this Wiki Page on HeisenBugs, which also (briefly) discusses BohrBugs, MandelBugs, HindenBugs, and SchrodinBugs.
I'm going to steal those...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
skeeve wrote:

In the interest of customer service, I expect replacements will include watchdog code.

An internal watchdog can be disabled via latch-up; if current is limited enough then the AVR will not be destroyed.

In principle, hardware problems can do pretty much anything.

Programming the right fuse will ensure that bad code does not disable the internal watchdog.

An external watchdog would require a hardware change

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
I came across this Wiki Page on HeisenBugs

 

That is a good find.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

latch-up; if current is limited enough then the AVR will not be destroyed.

 

I don't think latch-up destroys devices nowadays, that was back when CMOS was new. My understanding (which may be wrong) is that the "trench"  industry-standard technique also helps to limit the destructive current.

 

https://en.wikipedia.org/wiki/La...

 

So in my world, all I need to do is power cycle the AVR for long enough to clear the latch. I think it is about the same as reverse-recovery time.

 

https://en.wikipedia.org/wiki/Di...

 

 

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your post on the use of a logic analyzer; another instance of the effectiveness of such even when having to mow threw [sic?] through the data (to create information (failure from fault) to create knowledge) (the defect from fault)

DocJC wrote:
Yet every once in a while the program exits, and nothing is running behind the screen blanker.
There might be a tool in the Windows 10 SDK that can be between the app and blanker such that can obtain at least an exit code.

If the Win32 app is going through a dll to a sys (driver) then maybe Windows 10 DDK.

Easier - does VB have assertions?

fyi, Windows 10 IoT Core significantly reduces Windows 10's footprint though only have one window for the operator; Windows 10 IoT Core is one of the replacements for the Embedded instances of previous Windows.

 

more on-topic :

a former co-worker had a similar issue with an app on an RTOS where a mid-app was inserted to gather and filter data to gain insight on the app.

wrt Microchip products, Percepio Trace; don't recall if that's available for AVR, maybe for AVR32 UC3, though definitely for SAM.

DocJC wrote:
Perhaps I'll track down the VB Linter and see if it can identify any issues that I can resolve.
SonarSource for one and, IIRC, Microsoft (Visual Studio)

DocJC wrote:
I doubt there is a Linter for Bascom, unfortunately.
Sometimes one can do most of the work and effort on a PC, Mac, workstation, or server where one's tool box is larger then port to embedded.

DocJC wrote:
The compiler itself is pretty good at spotting some oddities, but it isn't a full Linter.
yea

A linter is orthogonal to a compiler.

The two ideally have different front-end implementations (more than one way to parse a computer language)

DocJC wrote:
Sadly, such bugs are often far from a laughing matter.
Concur

 


Windows 10 SDK - Windows app development

Overview of Windows 10 IoT Core - Windows IoT | Microsoft Docs

https://microchipdeveloper.com/search:site?q=percepio

Code Analyzers | SonarSource (two instances of VB) (edit2 : linters)

Visual Studio extension | SonarLint

Microsoft Code Analysis 2017 - Visual Studio Marketplace

though was hoping for an in-built in Visual Studio similar to /analyze (Code analysis) | Microsoft Docs (C++)

Valgrind Home due to a post by one, who is not Mr. Ganssle, in Hardware and software tools for embedded developers | Static Analysis and Metrics Tools (Jack Ganssle)

 

edit3 : C# and VB :

NuGet Gallery | Microsoft.CodeAnalysis 3.4.0

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Jan 24, 2020 - 04:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Krupski wrote:
it also seems like the 328pb oscillator is even less reliable

 

The low power oscillator drives the crystal softly. Think of it as pushing a pendulum with a soft touch. The pendulum is specified (or certified) to swing at a known sinusoidal frequency (+/- some ppm). If I kick (overdrive) the pendulum, it will not have a sinusoidal swing and not operate in the specification. The m32[48]pb has a clock fail fuse that may, in theory (needs verified), set the hardware to run on an internal oscillator while waiting for the pendulum to start swinging.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I appreciate the links!

 

It is going to take me a while to read through them.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A first pass evaluation of EMC/EMI/ESD/EFT can be on one's bench.

Once confident, one is into a rural basement, with feed horns and all, for a trial run before the formal testing.

 

Douglas has updated his EFT demonstration with test equipment that appears to be significantly less expensive than in his demonstration of 11 years ago (his first video)

2: Finding PCB Layout Defects with the Fischer EFT Pulser - YouTube (2m25s)

via https://www.youtube.com/user/dougcsmith/videos?view=0&sort=dd&flow=grid

High Frequency Measurements Site Index by Douglas C. Smith

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
evaluate CMOS for Latch-Up

 

Microchip is saying that the new AVR128DA will be recommended for safety-critical applications. Might that mean that they have a recipe that prevents CMOS latch-up? I am also wondering if the "must not be used within any Life Support System without the specific written consent" requirement is a clue about latch-up?

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am also wondering if the "must not be used within any Life Support System without the specific written consent" requirement is a clue about latch-up?

 

That line has been pretty standard in the fine print for as long as I can remember.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ron_sutherland wrote:
Might that mean that they have a recipe that prevents CMOS latch-up?
By what means latch-up?

  • excessive injection current
  • dVCC/dt is too large
  • excessive ionizing radiation

Some AVR have specified limits on injection current and dVCC/dt.

common - external steering diodes, R-TVS-R-AVR (and other ways), zener diode to unload AVR's VCC shunt, recommended VCC capacitance

ron_sutherland wrote:
I am also wondering if the "must not be used within any Life Support System without the specific written consent" requirement is a clue about latch-up?
CYA

MCU are somewhat complex wrt HDL, transistor sizing, and layout.

(I goofed similar on a chip from MOSIS, simulation showed no issue)

Effective executives, directors, and upper managers do complete, precise, and correct risk analysis and risk evaluation.

An example of such given parts from manufacturers and distributors :

Reliability Technology for Submarine Repeaters (Fujitsu)

Liability roosts

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some of the ones who hands-on observe and correct for software and hardware defects that lead to faults that lead to failures :

  • pilots
  • physicians

Planes and pacemakers must exist.

Planes, Trains & Automobiles (1987) - IMDb

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just don't get buried with your nuclear  pacemaker...I wonder if you are allowed through the airport/customs? 

 

In the late 60's and early 70's, the idea of bringing nuclear batteries into the pacing industry was first introduced and ultimately pursued as by 1973, several pacemaker manufacturers had introduced nuclear models. The thought-process behind these nuclear pacemakers came down to longevity. They provided young patients the opportunity to have one pacemaker last their entire life. These nuclear pacemakers also proved cost-effective in comparison to the lithium battery powered pacemakers of today  ......

 

One of those people is a woman who had a nuclear pacemaker—the Numec NU-5—implanted in 1973, says the device was still functioning adequately 34 years later, in 2007. A normal pacemaker would’ve required replacement four or five times in that time. In fact, according to Dr. Victor Parsonnet in an interview with Reuters, even after 88 years, when half the plutonium would’ve decayed, the batteries would still have enough power. For comparison, lithium pacemakers last 10 to 15 years.

Due to the extremely long battery life, nuclear pacemakers tended to outlive their users, and couldn’t be buried with them due to radiation exposure risks. Should you encounter a radioactive pacemaker (whether within yourself or a family member or friend) contact Los Alamos’ Laboratory’s 

 

https://www.medicaldesignandoutsourcing.com/medtech-memoirs-the-plutonium-powered-pacemaker/

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Jan 26, 2020 - 01:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Just don't get buried with your nuclear  pacemaker...I wonder if you are allowed through the airport/customs? 

 

 

I wonder how the 'six million dollar man' fared?  "Is it atomic?" "Yes sir, very atomic!"