Design, design, design ;@}

Funnily enough I've just been tinkering with a design idea that 
intentionally induces brown out, which can be viewed by the micro, while 
the power supplied to it is quite safe. The budget is so tight that I 
have been forced to look at some unusual solutions, this being one 
possible option. Going to a bigger micro isn't on. My absolute cheapest 
hardware design is 10 cents over the original budget already, and that 
may be enough to kill the deal so I might end up with a brown out 
detector in a machine which relies on brown outs to operate correctly.

Al

yvon_hache wrote:
> 
> Brownout is important when the power source can be momentarily 
> disconnected or could have bouncing contacts such as changing 
> batteries like Kris mentioned below.  One glitch is enough to lockout 
> a microprocessor.  But, if the power supply is designed to eliminate 
> any of these "brownout" or "glitches" to the rest of
the circuit then 
> there is no need to check for it.
> 
> Yvon.
> 
> 
> --- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> 
>>Hi Bill and Al,
>>
>>I've done several apps where brownout protection was paramount, and

>>by the same token I've known an Oz based company that was exporting
>>critical industrial systems, such as Mains Water pollution 
> 
> (backflow) monitoring,
> 
>>where they were shipping F149 based designs without even as much as 
> 
> the use of the 
> 
>>watchdog, and their USA client was very happy, no problems.
>>I personally found it bizarre, but maybe they were using really 
> 
> sound HW design - dunno -
> 
>>...which would equally support Al's assertion.
>>(I only did the RF for them)
>>
>>My personal experience is that - ironically - brown out protection 
> 
> is very important
> 
>>on battery powered products, where eg. AA alkalines and the likes 
> 
> are replaced.
> 
>>The bounce in the battery holder seems to be unfriendly to an MCU 
> 
> w/o BOD.
> 
>>Finally, I think it's important to establish what "brown
out" means 
> 
> for each of us.
> 
>>For me brown out includes Vcc "sagging" fast, but then eg.
rise 
> 
> slower, but equally
> 
>>includes transients that go right through the regulator (the 
> 
> feedback in LDO isn't fast
> 
>>enough), and even ceramic (thru hole) bypass caps couldn't kill it 
> 
> enough.
> 
>>Transils seem the sure fire way.
>>Nowdays LDOs are much better by taking care wrt ESR on eg. SMT 
> 
> tantalum caps.
> 
>>(ie. ensuring an optimal ESR)
>>
>>Example : Around 1992 or so when the XC705P9 was introduced, I had 
> 
> nightmare 
> 
>>problems with its MCU clock getting a "cardiac arrest". The WD
was 
> 
> clocked from the Xtal, 
> 
>>so nodes would occasionally fail. This was used in large Emergency 
> 
> lighting monitoring networks,
> 
>>(up to 6-8 K nodes in one building) - and big FL battens where a 
> 
> chunky relay switched the FL 
> 
>>from mains-ballast to inverter (with local battery) on power loss, 
> 
> the relay contacts arced like the 
> 
>>4th of July. (I found that the manufacturer's inverter would rise 
> 
> to a 600-800 V, before having
> 
>>the FL (relay) connected, thus the gas hadn't fired yet - after all

> 
> it will fire at 90 Volts or so IIRC)
> 
>>Certain fall/rise Vcc sequences would kill the MCU clock...
>>This was catastrophic, as they'd sometimes happily freeze on the 
> 
> RS485 while in TX @#$%!!!
> 
>>(killing a subnet)
>>Anyhow, eventually I convinced them to use Motorola zero crossing 
> 
> detect optos with a TRIAC.
> 
>>Shortly after I redesigned it on PIC16C71, and the network nodes 
> 
> NEVER failed again.
> 
>>Back then I loved PICs, and their superior QA, finally someone put 
> 
> the WD on an RC clock !!!
> 
>>We'd run 3000 in one go, and NONE would fail in programming (OTP), 
> 
> and average
> 
>>_one_ would fail (out of 3 K) after wave soldering....
>>
>>Basically, I think Al and Bill both equally make a good point.
>>
>>-- Kris
>>
>>
>>
>>>Sorry Al, I definitely should have inserted a <grin> or two in
my
>>>message.  Though your dogged support for assembly language is 
> 
> legendary,
> 
>>>your experience with both the MSP and with low power, embedded 
> 
> systems
> 
>>>design is equally impressive.  And unlike many (myself included), 
> 
> you
> 
>>>always seem ready to help those who are able to post a reasonable 
> 
> question.
> 
>>>I had to ponder your response.  It is not really something I had 
> 
> consider
> 
>>>recently.  And yes, I must admit there are probably many designs 
> 
> in which
> 
>>>recovering from a brownout may not be required.  However, there 
> 
> are systems
> 
>>>in which it is necessary.  In one instance, the design was for an 
> 
> inductively
> 
>>>coupled and powered interface device that allowed non-contact 
> 
> reading of
> 
>>>water meters.  The reader would output a 32-40KHz "tone" 
> 
> into/onto 1/2
> 
>>>of a pot-core transformer.  The device had the other half of the 
> 
> transformer
> 
>>>as its input and power supply.  The reader would on/off modulate 
> 
> the tone
> 
>>>to send data to the device.  The device would send back data by 
> 
> modulating
> 
>>>the transformer when the reader was silent.  All the while the 
> 
> device was
> 
>>>rectifying the output of the transformer and using it for its 
> 
> power source.
> 
>>>The problem came when the reader/device transformer coupling (it 
> 
> was positioned
> 
>>>by the person doing the meter reading) was either insufficient or 
> 
> dropped out
> 
>>>while the device was in operation.  The reading could be retaken 
> 
> but recovering
> 
>>>from the brownout was necessary.
>>>
>>>-Bill
>>>
>>>On Fri, 22 Oct 2004 20:35:15 +0930, onestone wrote:
>>>
>>>
>>>
>>>>Am I really that bad?
>>>
>>>>Why might I expect brownout to occur in the first place? If I 
> 
> have no 
> 
>>>>sound reason to expect it then I have no need to compensate for 
> 
> it. I do 
> 
>>>>monitor my supplies constantly, and do a lot of power 
> 
> management, but in 
> 
>>>>all of the testing I've done I've never experienced
brown out 
> 
> once.
> 
>>>>Al
>>>
>>>>Bill Knight wrote:
>>>
>>>>>Al
>>>>>  OK, I know I'm opening myself up for a
"learning" 
> 
> experience, but
> 
>>>>>here goes anyway: What do you use for brownout detection and

> 
> recovery?
> 
>>>>>-Bill Knight
>>>>>R O SoftWare
>>>>>
>>>>>
>>>>>On Tue, 19 Oct 2004 17:24:12 +0930, onestone wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I don't use one, and have never had the need.
Cheapest option 
> 
> around.
> 
>>>>>
>>>>>>;?}
>>>>>
>>>>>
>>>>>>Al
>>>
>>><<<<  snip >>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>>
>>>
>>>
>>>      
>>>           
>>>     
>>>     
>>>
>>>
>>>------------------------------
> 
> --------------
> 
>>>Yahoo! Groups Links
>>>
>>>  a.. To visit your group on the web, go to:
>>>  http://groups.yahoo.com/group/msp430/
>>>    
>>>  b.. .
>>>    
>>>  c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of 
> 
> Service. 
> 
>>>
>>
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
>