Go Down

Topic: What's problem with brown out ? (Read 5241 times) previous topic - next topic

jack wp

I have read many posts, and web pages, discussing brown out. But I don't think I have seen a clear description of what problems lurk there.

1. Is it that you are logging data, and your last few readings got lost?
2. Is it that the arduino will never start running again, without human help?
Or what.
If you have your board powered from the power grid, it is likely that it will lose power sometime. I guess that would be a brown out. Or is it just when the power drops low, but keeps running (that sounds like the real definition of a brown out)?

I tried a test today: I hooked a board up to a small solar panel, with a super cap. I shaded the panel till the board stopped running, then, when It got light again it started back working. I did this about a dozen times. Came back every time.
As best I can tell, my board (leonardo), has the brown out protection disabled.

Anyone have experience with this?



JChristensen

Just one quote from the datasheet, there may be more.

Quote
5.3.5 Preventing EEPROM Corruption
During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is
too low for the CPU and the EEPROM to operate properly. These issues are the same as for
board level systems using EEPROM, and the same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too low. First,
a regular write sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly,
the CPU itself can execute instructions incorrectly, if the supply voltage is too low.
EEPROM data corruption can easily be avoided by following this design recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can
be done by enabling the internal Brown-out Detector (BOD). If the detection level of the internal
BOD does not match the needed detection level, an external low VCC reset Protection circuit can
be used. If a reset occurs while a write operation is in progress, the write operation will be completed
provided that the power supply voltage is sufficient.


Also see section 8.0.5 which details the BOD fuse coding. If the Leonardo board ships with the fuse settings in the boards.txt file, its BOD would be set to 2.6V. Why do you think it's disabled, have you read the fuses out?


jack wp

Thanks Jack,
So that quote, sounds like a brownout problem if trying to write to EEPROM.

Quote
Why do you think it's disabled, have you read the fuses out?
No, I am not up to that yet. I have read on the internet, that "by default, the boards have the brownout disabled".

If you are not logging data into the EEPROM, does that mean brownout is not a problem?

JChristensen


Thanks Jack,
So that quote, sounds like a brownout problem if trying to write to EEPROM.


But also note that it says

Quote
Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage is too low.


Quote
I have read on the internet, that "by default, the boards have the brownout disabled".


Hmmm, that was definitely not the case for my Unos and Pro Minis, but I don't have a Leonardo. You wouldn't have a link to where it said that?

Quote
If you are not logging data into the EEPROM, does that mean brownout is not a problem?


No, for the reason stated above. I probably worry about these things more than other folks.

BTW, loved the line about welding in that other thread :D

jack wp

Quote
No, for the reason stated above. I probably worry about these things more than other folks.

You mean you worry about the program not running correctly? You think it will send signals to devices that will cause them to burn up?  Please elaborate.

JChristensen

#5
Aug 02, 2013, 01:07 am Last Edit: Aug 02, 2013, 01:09 am by Jack Christensen Reason: 1

You mean you worry about the program not running correctly?


Yes, the way I write code I need as little help from malfunctioning hardware as I can get ;)

Quote

You think it will send signals to devices that will cause them to burn up?  Please elaborate.


For the types of projects I work with, I'm not usually worried about things burning up or any other physical effects. But it all depends on the application. There could well be safety issues if the microcontroller is operating equipment, etc. For serious applications like that, I'd say that enabling the BOD is mandatory. Not because it's expected to happen but you never know. And there are a bunch of other things that should be done to ensure reliability and robustness. Enabling the watchdog timer is just one that comes to mind. I basically never do that. But I'm working on a project now where I probably should.

Here's some ad copy from Intel that went through my inbox today.

Quote
Embedded designers can't afford "the blue screen of death." Desktop operating systems can get rebooted every so often, but embedded systems--good ones, at least--often have to run for years without a single reboot or power cycle. Medical devices are one obvious example in which reliability is absolutely paramount. But industrial-automation systems, security systems, motion controllers, automotive systems, and most other embedded devices have to be just as reliable. And that means building on a reliable foundation.


jack wp

Ok, (reading between the lines), I think I understand more.
why do we not have more people on this thread. If you play poker, (Jacks or better), we just barely make it here. LOL

JChristensen


why do we not have more people on this thread. If you play poker, (Jacks or better), we just barely make it here. LOL


I know. People named Jack are usually great company, baha. Now Jack sometimes gets used as a nickname, so are you really a Jack, or a John or something else?

jack wp

Well, I don't let this out often, so keep it under your hat. My parents named me Jackie. Don't you ever call me that tho.  LOL

JChristensen


Well, I don't let this out often, so keep it under your hat. My parents named me Jackie. Don't you ever call me that tho.  LOL


My lips are sealed. I had an uncle Jack, whose name was really Isaac, but a lot of people called him Jackie too. Go figure. Anyhoo my name is really just Jack.

alnath

So we have a Jackie Brown out there  :smiley-zipper:   XD

Coding Badly

You mean you worry about the program not running correctly?


Correct.  There is a point where the processor is no longer guaranteed to correctly execute instructions.  There is also a point where SRAM is no longer guaranteed to retain data.

For what it's worth, that point is somewhere below 1.6V for the ATtiny85V I tested.

JChristensen


For what it's worth, that point is somewhere below 1.6V for the ATtiny85V I tested.


Interesting. I assume the voltage at which instructions are not correctly executed is a function of clock speed. What speed were you using? (Or were you testing SRAM data retention?)

jack wp

I placed a leonardo board in the garden, powered by a 6Volt (maximum 9 volt) small solar panel, with a 4 farad super capacitor. First I used the blink sketch on pin 13, but soon found the sun did not allow me to see the led. Then I put a buzzer on pin 9, same sketch just pins changed. As the clouds moved in and out, it worked, and stopped, then worked again. I see no problem, as long as there is power, this one will start back up, and run fine.
You think if I let it set over night, the results will be any different? I will try it tho.

Coding Badly

What speed were you using?


Excellent question.  One without an answer.  :smiley-eek-blue:  Probably 1 MHz.

Quote
(Or were you testing SRAM data retention?)


Execution.  I'm not patient enough to build an effective SRAM test.

(Got to remember to reply to your email tonight.  Argh.  Just can't get work beaten down.)

Go Up