When the prototype is working and a few pre-production prototypes are sold, the manufacturer then tries to add value and decrease the price over time.
We were involved with an ultra low-power data logger for the energy sector based on TI 430xx, in the prototype the uC used to manage all power management of peripherals including its own.
A button push brought it out from sleep mode. A dual line alphanumeric LCD gave health and status of the system, as the unit was supposed to be a hermetically sealed. A 9V lithium battery guaranteed for 9 years lifetime was used and one 5-volt regulator and an LDO for the uC were used.
After a few months, there was a consumer demand for switchable back-lit display, however after a few were released, I was asked to use a soft key to enable the back-lit display, and a timer would turn off the backlit after 40 seconds, to save power. We already had a small transistor in series with the back-lit power supply so connecting a port and doing the job was trivial.
Then the feedbacks began to come in. In most cases, as soon the backlit was lighted, the uC went into Reset or Watch Dog Reset (WDR). At this stage, the only way to do things is call the designer. Two samples were sent to me and I found out that the problem does occur. An analysis of the layout and an oscilloscope on the VCC proved that there was occasional glitch in the power supply at the output of the LDO. This should not have happened; the backlit is taken from 5Volts.
After further analysis, I found that the LDO input capacitor has been displaced nearly 2cm from the input and a pretty thin trace goes to the LDO input. Now this was a four-layer board – a small 1uF ceramic multilayer right on the LDO input pin to ground solves the problem but you cannot manufacture like that. There was no space to put in any thing without changing the PCB. So as to not to introduce a heart-attack to the manufacturer, I slept on the problem.
A push on the soft button turns on the backlit transistor –soaks the current very fast and the poor LDO, for a very small interval, was working beyond its specification.
The solution was to PWM the backlit transistor so that the surge current was less, and the added attraction of a 2 second to full back lit –no surges.
Software PWM was done –slowly- increasing progressive duty cycle within 1second and everything was fair. This is one of the many examples: When you are doing really low power devices you should be very careful about adding components, especially placement of capacitors. The capacitor on the LED backlit terminal was charging suddenly, had the LDO input trace been at least 12 mils or the capacitor right on place this should not happen.
Well, software saved the particular batch.
(Adip Dutta majored in Physics and Electronics from University of Calcutta. For 16 years he worked for R & D in the defense lab of DRDO. From 2000 to 2004 he worked for the iPOD SOC as Senior Architect. He founded- Fornax Research, a company targeted for rapid proto-typing in embedded systems. He holds a number of consultant positions for companies in US, Australia, Israel, Taiwan and India. His interests at present include teaching, energy conversion, energy harvesting and bringing technology to the underdeveloped sector).
Nice example of how a seemingly innocuous change can suddenly turn into a butt-biting alligator snapper. Good solution with software PWM. Someone (other than management) should have received a bonus for creative thinking.
I did the same thing on a project back in the 90's. In my case, the problem occurred during startup, turning on a daughter card with plenty of decoupling caps. Inrush to charge the caps dropped supply voltage enough to trigger the power monitor chip. That reset the system, which proceeded to turn on the daughter card, ... lather, rinse, repeat.
I didn't exactly PWM, but pretty close - a slightly different kind of duty cycle modulation with the same net effect.
It is always a software problem. Why? It is often easier to change software than anything else.
I've fixed many electronic and even mechanical defects in software. The oddest, perhaps, was fixing a lubrication defect in software.
The wrong lubricant was used to lubricate some bearings in some units. When the device got hot this caused the lube to be too thin and the mechanics would slide more freely than originally designed causing oscillation. When the lube cooled it got too thick and the operation was sluggish.
Solution: replace the PID loop parameters with two sets of parameters and look at oscillation to determine which set to use.
We all like to get Brownie points for fixing problems like this. Ultimately, though, this is only a Band-Aid. It fixes one manifestation of shoddy layout & analog design (perhaps even provably, though probably only empirically). But what when the next batch of LDOs actually oscillate rather than just fall out of regulation? Let's not send the message that it's OK to forget about how to do good hardware design because some smart software guy can always fix it up!
Funny thing though, sometimes in the defense industry it is cheaper to change hardware than software anytime you are working with critical systems. As it turns out the work necessary to re-certify system safety software takes a lot longer and costs a lot more money than to re-certify the hardware changes.
Thanks for your comments and suggestions,actually it was not for defense but private industry also my company was working as a design service provider. In fact the path PWM solution went on to use when the manufacturer sourced displays from different vendors and the LED back lit current varied a lot.
I agree, for a product a short time software patch may be used, but if there is really a hardware design problem, sooner it is rectified the better.
It's really mind-boggling to think of what my hourly rate would be if I were paid for the actual time that I spent troubleshooting a problem to get to a fix. The challenge is to avoid going down a rathole.