Go Down

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

jack wp

Maybe for critical, (life or death) use a UPS ? What would that be, an extra $100, $500 ?,
But otherwise, no worry!


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

No worries, busy here too. In other news, just dusted off Tiny ISP, Tiny Tuner 2, TinyDebugKnockBang. I think I have a project for an ATtiny84A that needs to talk I2C to an RTC. Haven't done I2C on a Tiny before, so I thought I'd better have a way to verify that it's working and so TinyDebugKnockBang seemed like just the thing!


Why do you think it's disabled, have you read the fuses out?

bod is disabled from factory but enabled for "arduinoed" chips which can cause confusion. i agree bod should always be enabled even if only lowest voltage. its not perfect. if theres any spm or ee write code anywhere in the chip then scratching a wire (worst case) on the vcc pin WILL cause corruption. but in my experiments bod reduced the likelyhood by several orders of magnitude.

also note that, as hinted in that atmel doc, a large cap and diode on the power rail can protect the chip from accidental/uncontrolled shutdown (ie interrupted ee or flash write).


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?)

Yes, that's an issue - the default brown-out detection voltage for the Uno (2.7V) for instance is below the voltage at
which the chip will fail to clock properly with a 16MHz crystal, so its set wrongly.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Go Up