Snubber for bouncy power switch

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My current project uses an ATtiny85 and I'm finding that a bouncy power switch (usually just attaching wires to a power header) is enough to cause the EEPROM to get corrupted if the connector isn't plugged in really fast.  I found that turning on brownout protection level 1 (2.5V minimum, 2.7V typical, 2.9V maximum) prevents this from happening.  Still, I'm wondering if a simple RC snubber composed of a resistor and capacitor across the switch/header would help to prevent this trouble without incurring the extra power consumption for brownout protection.  The prototype uses a 9V battery going through a 78L05 regulator (please, no commentary about this).

 

How do I figure out the correct values for a simple RC snubber for this?  Everything I find with Google on the subject seems to start with the assumption that I'm dealing with mosfets, high-powered electric motors, and the like.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Why not just an electro across the supply?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rezrov wrote:
Everything I find with Google on the subject seems to start with the assumption that I'm dealing with mosfets, high-powered electric motors, and the like.

​I think that's because "snubber" is not the correct term for what you're looking for?

 

https://www.youtube.com/watch?v=...

 

A "snubber" is usually for absorbing energy from things like inductor back-emf  - that's not what's happening here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The added current from the BOD is not a concern when the power supply is a 9v battery with a linear regulator!!!

Use the BOD.

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

To add to Midwest Jim's comment:

 

1. The quiescent current of a 78L05 is 6ma at 25C.

 

2. BOD (at 5V) takes 20uA

 

Use the bloody BOD and get yourself a low-Iq regulator! There are many out there and you will save both grief and battery life.

 

West Coast Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The prototype uses a 9V battery going through a 78L05 regulator (please, no commentary about this).

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1)  What are your fuses set to?  Specifically, SUT.  I'd think 64ms would cover most switch bounce.  [but while the title and first line both say "switch", that is immediately followed by a description of plugging wires]

 

2)  In addition to SUT, I have a delay at the beginning of my apps following setting port directions.  As many milliseconds as the app can stand; typical 100ms to 200ms.  That lets everything settle out.  That should hold off any EEPROM operations.

 

3)  Without BOD the AVR will [try to] start as soon as the minimum V is reached.  (I forget; isn't that something like 0.7V? **)  Thus, depending on your clock source and speed, you will be running outside of the speed-voltage allowed envelope.

 

** -- No wonder I'm confused about "minimum V".  The datasheet description speaks of it as VPOT, but the tables use VPOA.  And newer chip revisions of that model line have a higher threshold.

 

4)  If this is a sleeping app, then your model has "sleeping BOD" feature.

 

5)  I agree with the analysis above on 9V.  While no commentary is allowed, what approach will be used in the final app?  Is battery life a primary concern?  Or not so much?

 

5a)  If this is really a bench prototype, then why worry a lot about glitches when attaching wires which is probably not a factor in a "real" unit?  That said, always use the BOD IMO/IME.  The only exceptions in the past were apps that needed to be most niggardly in power draw.  Nowadays with lower power draws all around including BOD, and sleeping BOD, it would be very rare not to use one.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is one more possible problem I'll mention for the record, in case you solve one problem and still see some erratic behavior.

 

Most ( ? all) AVR's are required to have a monotonically increasing V+ rail on power up.

If there is a "glitch" in the power up voltage, one can lock up the power-on, reset circuitry and the micro won't run properly.

 

If you have a small electro cap on the 78L05, then depending upon the current drawn by the micro, and the timing of the power "switch" bounce, you could easily have a glitch in the power rail which does not go all the way to 0 V, (or whatever...), to reset the circuitry.  A larger electrolytic cap in parallel to the 78L05's Cout cap solves this issue.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much capacitance do you have on your power supply?

You should at least have a 100nF decoupling cap for each IC on your board (or more if an ic has multiple power connections.

Tie a separate 100nF cap to each Vcc / GND combination close to the ic.

On the board there should also be a buffer capacitor.

If the voltage regulator is on the same board, 10uF or thereabouts should suffice.

If the voltage regulator is on another board I'd add a 470uF or bigger electrolytic capacitor.

 

Complete schematics and/or a photo of the pcb would help.

 

Rezrov wrote:
EEPROM to get corrupted if the connector isn't plugged in really fast.

Do not attempt to read/write to/from the EEPROM in the first few seconds after power up.

 

You can also monitor Vcc in software.

Basic idea is to use Vcc as reference for the ADC and then measure the voltage of the voltage reference with the ADC.

(Gosh, did I write that, is it clear?)

 

theusch wrote:
then why worry a lot about glitches when

Maybe because it's pretty annoying to work with glitching prototypes?

You'll never know if you keep getting annoyed by the same old known bug, or introduced new bugs later on with the same / similar symptoms.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com