Does Embedded software ever hang like an operating system
- Thread starter Kittu20
- Start date
Sure, why not?
Computer code is written by humans (most of the time). Humans are known to make errors.
I've been trying to figure out for a long time what could be the reason for the embedded software to hang. I am trying to understand reasons because i heard about watchdog timer which is used to reset software.
I don't understand why watchdog time should be used in commercial products
MaxHeadRoom
- Joined Jul 18, 2013
- 26,708
In the industrial arena, watch-dog timers are used by the computerized process to advise the outboard mechanical/machine operations via an emergency stop in the event the processor is non-functional for some reason.
In most cases, the WD timer when running continually resets the alarm circuit, in the event of processor failure, no reset occurs and the machine shuts down
In most cases, the WD timer when running continually resets the alarm circuit, in the event of processor failure, no reset occurs and the machine shuts down
If there is interference in the region and a serial communication is interrupted and delivers an incomplete string of bits or a pulse of interference is read like an extra clock cycle. Or a motor encoder doesn't reach the destination and deliver the right number of pulse counts, the code could hang, just waiting for a blocked movement. There are lots of reasons to use a WDT. Depending on how the code is written, all kinds of issues can happen when interfacing with the real world.
DickCappels
- Joined Aug 21, 2008
- 9,632
A lot of firmware is sometimes comparatively simple, I think because complex operating systems are not used often, there are rarely many complicated tasks sharing resources, and at least at the assembly language level programming is clean and direct. Sort of :- )
Troubleshooting can get hairy and there are sometimes things like poorly managed interrupts routines running multiple instances poorly that can be a real headache and lead to the sort of disruptions you mentioned.
I once wrote firmware that, among other things operated a Polaroid filmback and every now and the when the filmback was supposed to process one piece of film after taking a picture and make the next piece available for exposure the controller would latch the motor control pin, emptying the entire filmpack onto the floor.
This was a firmware failure that was eventually tracked down to noise from the wire brushes sparking in the motor that would get into the microcontroller.
Troubleshooting can get hairy and there are sometimes things like poorly managed interrupts routines running multiple instances poorly that can be a real headache and lead to the sort of disruptions you mentioned.
I once wrote firmware that, among other things operated a Polaroid filmback and every now and the when the filmback was supposed to process one piece of film after taking a picture and make the next piece available for exposure the controller would latch the motor control pin, emptying the entire filmpack onto the floor.
This was a firmware failure that was eventually tracked down to noise from the wire brushes sparking in the motor that would get into the microcontroller.
Well designed embedded software programs rarely but sometimes do 'hang' (usually because of a detected hardware failure in the monitored and controlled machine) but usually the OS is still running so it's possible to easily read the logs of what happened and to restore operations quickly. We have server class machines running embedded software to control complex mechanical and physical sequences on processing machines that use large SQL databases for the state machine data (thousands of data points update per a 1ms state machine tick). There are a huge number of possible fault conditions that can cause critical conditions resulting usually in a sequenced and controlled stoppage of software functions.
drjohsmith
- Joined Dec 13, 2021
- 578
To miss quote above,
"to err is human"
The difference in "imbedded software" to say windows, is that there is a defined "safe state" / safety is thought about
its not to say that windows is not written "safe" its just that there are so many different bits of windows, by different companies compared to an imbedded system, that its never going to be "safe"
As you have mentioned,
a watchdog is a key part of an imbedded system,
this is a "stand alone" part, even if its on the same chip as the other bits,
it has the power of kicking the processor into a default state, quiet often a power on reset.
this kick can not be blocked by anything else.
The watchdog is itself kicked on a regular basis by some part of the system,
such that if the system "stops" , the watchdog is not kicked , and then the watchdog resets the system,
Its also normal for the watchdog to write into some status register that the OS reads at boot, to ascertain this is an "emergency" event or a normal power up, the OS then goes into a "simple" mode of operation,
sort of like windows does if it blue screens and you re boot, windows knows its not a good start and offers you a diagnostic mode, but this is not kicked by a watchdog, you are the watchdog pressing the reset button,
Watchdogs and recovery can be a very big part of a system
think a space craft, or a phone mast on top of a big mountain,
they will both be a real pain to visit to press the reset button,
I hope this is not for a school essay
BobaMosfet
- Joined Jul 1, 2009
- 2,069
Yes, it does. Should it? No, not if written properly. 'hangs', crashes, and other anomaly are due to bad code/design 90% of the time. Why anyone would find such things 'acceptable' is beyond me. The 'only' time an O/S should crash or hang is if some situation causes it to wind itself into a corner it can't work it's way out of because there is no design option available to prevent it without increasing hardware resources it can utilize. Or if it's being acted upon by an influence (such as EMF, or Radiation or, something forcibly altering it's design behavior).
DickCappels
- Joined Aug 21, 2008
- 9,632
I guess we are missing the definition of "Embedded". Windows has been embedded, keychain remote controls are "Embedded".
bassbindevil
- Joined Jan 23, 2014
- 687
My friend's outdoor xmas light timer switch got into a state where it appeared to work, but the setting functions were gibbled up: didn't display the current switch and mode status or allow selecting on and off times. That was possibly due to a corroded and intermittent connection to the backup battery. I would have thought that the code would run from ROM, but maybe it's loaded into RAM from a serial EEPROM and so could become corrupted by a power glitch.
