Weird reset behavior

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

I have a gizmo that is based around an ATMEGA16.  And there's a particular pot that if I twist it, it can cause the AVR to reset... sometimes.  The behavior is a bit weird.  The pot has about 1.7V across it.  I was assuming there was some sort of (intermittent) short between it and the reset line, but, I couldn't find anything obvious either through visual inspection or electrically.  It also doesn't really make much sense... because it fails when I INCREASE the voltage on the wiper... So if I was somehow shorting the wiper to reset, why wouldn't it fail when the wiper was closer to ground. 
 

But I decided to try probing other stuff.  The RESET pin only goes to a JTAG connector which is right next to the AVR.  I tried probing the RESET line with my multimeter (Fluke 88 -- specs say 10M input impedance and < 100pF cap).  When I touched my probe to the reset line, the chip reset.  And it was reading ~ 4.75V.  Interestingly, VCC is about 5.04V.  So if Fluke is to be trusted that means that the AVR is pulling the RESET line up with 650k, and the capacitance in the probe was enough to pull the RESET line down long enough to reset.  This all strikes me as a bit... weird.
 

Is the RESET line really that weakly pulled up that a reset can be triggered so easily or is this a defective part?

Last Edited: Fri. Mar 20, 2020 - 06:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happens when you fit a 10k pull up resistor to the reset pin as recommended by Microchip?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

That's an excellent question.  I didn't design the circuit, but I can find no evidence of a pull up resistor.  When I look through the datasheet...  (Datasheet) page 38/Figure 15 seems to show a pull-up resistor but they make it look internal and I don't see any text suggesting you need a pull-up resistor.  That said, it seems quite possible a pull-up resistor would fix this problem.  Are you saying this is normal behavior that the reset pin is essentially floating?  Can you cite the documentation that recommends the pull-up?

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

See AVR042 for a recommended design.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

They do mention there is an internal pull-up but don't say what it is.  But interesting that they recommend an RC filter on the line.  Which of course is a pain to retrofit.... Although it's possible I could stick some 0603 or 0805s on the under side of the board (it's all through-hole).  Looks like I could even do both R (on the MCU) and C (on the ISP/JTAG connector).  Fun fun...

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

hpmaxim wrote:

I didn't design the circuit,...

 

Perhaps you ought to point the designer to that document to avoid issues like this in the future wink

 

There's also this topic of mine...

 

https://www.avrfreaks.net/forum/...

 

 

...which pulls together some best practice.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

So...  I put a 10k between VCC and RESET (quite convenient that the pins are next to one another).  I can no longer reset it with my multimeter, but it still sometimes resets in actual operation.  However... it does seem more resistant in actual operation than without the resistor.  I guess I'll try adding a cap.  100nF seems like a lot though.

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

hpmaxim wrote:

I have a gizmo that is based around an ATMEGA16.  And there's a particular pot that if I twist it, it can cause the AVR to reset... sometimes.  The behavior is a bit weird.  The pot has about 1.7V across it.  I was assuming there was some sort of (intermittent) short between it and the reset line,...

 

What about if the pot is somehow shorting the power rails together?

 

Do you have a schematic you can post?

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

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

Why would you post after post that a pot is causing a mystery AVR reset and say NOTHING about where or what the pot is connected to?  Is is even connected to the AVR at all?

 

Why haven't you at least shown a schematic?

 

A voltage at mid-rail can draw "excessive" current on a digital pin, so if powering from a rather weak coin cell, that might collapse things.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Mar 20, 2020 - 08:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a software engineer rather than an electronics engineer I tend to suspect software rather than hardware problems (though naturally we always blame the electronic engineers anyway - just because it's expected!)

 

Difficult to know if you have a software problem without seeing the software though!

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

I'm not entirely sure I understand what you mean when you say

 

hpmaxim wrote:

The pot has about 1.7V across it.

 

Presumably the whole point of the pot is that the voltage across it varies.  I imagine one end is hooked to Vcc, and the other to ground.  What is the value of the pot?  It could be part of a voltage divider.

 

What does the output of the pot drive?  Does it simply go directly into the AVR ADC, or through a buffer amp along the way?

 

In which case, yes, it could be a bad pot that sometimes shorts both ends together, which would cause some interesting spikes on the power supply.

 

That you have improved things by improving your /reset circuitry makes me also suspect your power supply.  Throw a 220uF electrolytic cap across it as well, close to the AVR.

 

What else does the AVR do?  If driving stepper motors with PWM bridges, that'll cause funky resets now and then too (ask me how I know!  ;-)  S.

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

I have a gizmo

Need more info.

 

Commercial gizmo?

Schematic available?

Did it ever work correctly?

What is the device, what is it connected to, what is its power supply?

 

If, as you suspect, the pot is the culprit, then re-programming a simple blink-the-LED program ought to also fail if you mess with the pot.

That would help, but not confirm, a hardware problem.

 

On a side note, I thought the external Reset\ pull-up resistor was optional.

Perhaps a reasonable, low cost, addition for operation in a noisy environment, but generally not actually required for operation.

 

JC  

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


hpmaxim wrote:
They do mention there is an internal pull-up but don't say what it is.
You didn't look very hard:

 

hpmaxim wrote:
100nF seems like a lot though.
Why?

"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."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

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

"Fast.  Cheap.  Good.  Pick two."

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

 

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

So, I just figured I'd make some additional comments:

 

First: the wiper of the pot is connected to one of the A/D converters. 

Second, I now know what's going on.  Software on the uC is resetting it, deliberately as a result of feedback that is "out of range" on an H-bridge.  It turns out that a power transistor which is supposed to turn on, is stuck off, because the pin that is driving it has an 18 ohm short to ground (inside the AVR).  As in, with the uC out of the circuit, that pin shows 18 ohms to ground, while others are reading 2.9Mohms to ground.  Soooo... fried uC!  The pot was causing the problem because it impacted the output of the uC to the H-bridge.

Last Edited: Tue. Mar 24, 2020 - 03:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hpmaxim wrote:
Software on the uC is resetting it,
clawson wrote:
Difficult to know if you have a software problem without seeing the software though!

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

I'd say that if you have software you know you have a software problem!  Sangel

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

I didn't say I had a software problem, I said I had a hardware problem.  There is 18 ohms to ground on the output pin of the uC (with it de-energized and out of the circuit) all other pins on that bus have 2.9M ohms.  What I said was the software was deliberately resetting itself because the H-bridge feedback was off, because... the output pin was shorted to ground.

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

software was deliberately resetting itself

What exactly are you talking about?---that means little.   

 

Soooo... fried uC! 

What fried it?  Show the latest schematic

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

The pin was connected to a 100k pull-down resistor and 10k resistor which went to the gate of a power transistor.  I have no idea what fried it... ESD perhaps?  Unless there is a short on the board I'm unaware of (which you sure as heck aren't going to find in the schematic), I'm going to say it was ESD.  Seriously...

As for "what exactly am I talking about"... it's not relevant.  The software contains code that checks a sense resistor that is in series with power transistors, if it senses a value it doesn't like, it can force a reset.  I had previously assumed the reset was coming from the reset pin (which was connected only to an unused programming header).  That wasn't the problem.

I only posted because I know it can be frustrating when someone posts a question, and then either disappears or says something goofy like: "Figured out the problem, thanks..."  As far as I can tell, the problem was caused by a dead output pin on the uC which caused a chain of events which caused the software to initiate a reset. I should be getting a replacement part on Thursday and will then be able to determine if the problem is solved.

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

Post the whole schematic...giving out little bits of info here & there is not going to get to the issue

Pot issues? connected whre? Multimeter?  reset?  18 ohms? fried pin?

 

code that checks a sense resistor that is in series with power transistors,

Wired how?  Resistor to gnd (hopefully)? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Brian, I'd like to thank you for providing useful information.  Pointing me to AVR042 was helpful and I learned something from that, including about a deficiency in the design.  Which hopefully is corrected.
Joeymorin, thanks for digging up the reset pull-up value.

All the rest of you (mainly avrcandies), seriously...  I'm not sure why the snarky comments.  I haven't posted the schematics, and I'm not going to post the schematics for a variety of reasons.  I'm an electrical engineer, who used to work for Atmel (my work did not revolve around AVR though)  I'm not a complete idiot.

I do not know what fried the microcontroller.  But there is no doubt in my mind that it's fried.  And there's nothing on the schematic which would cause it to be fried.  Like I said, it's connected to the gate of a power transistor through a 10k resistor, and its connected to ground with a 100k resistor.  That's it.  Two resistors are touching the pin and that is all.  The 10k should protect the uC from the power transistor and a 100k pull-down is certainly not going to hurt anything.  So perhaps there is a short on the board that I'm unaware of, but that could be anything.  I was trying to be polite by explaining the problem with the uC instead of just running off after I found the problem.  I'll even let you know if a new part fixes the problem or if it develops the same short...  That said, It's hard for me to imagine that you could fry the part by driving into anything that was between 5V and 0V.  If it was exposed to something > 5.5V the ESD clamps would pull the rail up and the damage could occur on virtually any of the pins or, more likely, internally.... which means the short could be virtually anywhere.  The rail appeared to be 5V though (although I didn't look at it on a scope).

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

Like I said, it's connected to the gate of a power transistor through a 10k resistor, and its connected to ground with a 100k resistor.

You never mention if it ever worked in the first place...was all well, then kapoof?    Maybe it was just the slip of a screwdriver or wire strand floating around.  With 10k, yes, it should be rather robust.

If your sense resistor is not grounded anywhere, that can provide a path for high voltages into the AVR--but you don't mention how it is configured (high side, low sider, or other).  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Mar 24, 2020 - 11:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies, the sense resistor is < 1 ohm and is connected to ground.  I don't know if the problem has always been present, hadn't used it enough to see the behavior prior to noticing the behavior.

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

So I got the new part... It fixed the problem with the pin, but I am still having the reset problem.  I am increasingly believing this is a software issue.

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

 It fixed the problem with the pin

So are you saying all of your board functions are now working completely fine, other than the  mystery reset?   Is the reset like once a day or once a minute?  Also, there is a difference between the chip hardware resetting & your program simply starting over---so you can try and figure out which type is happening (there is register info to tell this).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

So I figured I'd add a bit... I've come up with a solution (or rather two solutions, one or both may have been necessary) and a theory as to what was wrong.

 

Solutions:
1) I switched from an ATMEGA16A to an ATMEGA16L (yes, older MCU).  I switched because I had a MEGA16L and had bricked the MEGA16A improperly attempting to do solution #2 (which likely was what fixed it).

2) I switched from an external 8MHz crystal oscillator to the 8MHZ internal RC oscillator.

 

My best guess at this point is that the massive amounts of current slugging through the H-bridge into an inductive load had the potential to wreak havoc on the crystal and I was getting spurious clocks, perhaps too fast for the MCU to handle which resulted in corrupting registers.
 

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

That sounds a bit unlikely....a crystal is pretty hardy...why would you have that much noise right there---and why would it end up in the little xtal and not the rest of your circuit causing  parallel troubles?   If you used a true oscillator module that  requires 5V power, it would make more sense, if there were not enough filter caps & the osc got reset....but likely so would the micro.    Does the H-bridge share the 5V supply?   How many uf are  you using on the rails? A schematic answers these questions.

How is cross-conduction handled (prevented)?

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Let's put it this way:

 

1) ATMEGA16A vs ATMEGA16L have different behaviors
2) The crystal oscillator is not functioning as expected.

 

Those are the two possibilities.  Switching to the L part along or changing to the internal RC oscillator fixed the problem.  Period.

The H-bridge and uC are powered off of separate linear regulators which have more than adequate bypass capacitance on them.  The uC has 100nF between ground and VCC (and an additional 100nF to AVCC/AREF) They do have a common ground.  So it's possible that there is some ground bounce/inductive kick which is messing with the power supply.  I was assuming if there was a problem it was some sort of parasitic mutual inductance between the H-bridge and something on the uC side.  

There is of course, another possibility...  something is wrong with the oscillator circuit.  However... it's a bit odd that the problems always seem to show up only when the H-bridge is cranked up.  The oscillator is just a 8MHz crystal across XTAL1 and XTAL2 with a pair of 18pF caps on it.  All parts are through-hole parts, which I inherently don't trust in terms of parasitics.

This was the crystal that was used:

https://www.digikey.com/product-detail/en/abracon-llc/ABL2-8.000MHZ-D3W-I-T/535-14340-1-ND/8582101

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

Could be a layout thing, since you will have xtal caps going to gnd.  If gnd is bouncing terribly, maybe then it would mess up the xtal osc.  The xtal itself should be fairly immune to picking up/reacting  to EMI, especially if you have short wiring to the AVR.    Are you sure you don't have bridge cross conduction?  Even the slightest is like driving a freight train straight into your circuitry, just 20 nanoseconds will wreak havoc! 

 

One thing, is that merely probing with such high current pulsations, can cause them to be picked up/injected wherever you probe, thereby creating misleading clues to chase around.

 

In a high-noise situation 100nf, is rather minimal, but you mention there is plenty at the supply itself.   How about the wiring...don't use 24 gauge for high current hookups! 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

I'll reiterate, I didn't design the circuit nor do I have sourcecode for the firmware, however, at this point, I tend to think it's not software.   There are definitely deficiencies in the design of the circuit, but it is reasonable.

 

The problem occurs whether I'm probing around or not, so that is a red-herring.  The H-bridge is powered off the output of a 7812, which has tons of capacitance on it.  The H-bridge is on the same circuit board as everything else, so there are no wires except the main power wires, which are either 16 or 18 gauge.  There is a 28 gauge ribbon cable (which is significantly longer than it needs to be) which runs into the uC, and could be the source of coupling from the H-bridge.  The traces for the xtal circuitry is about as good as you are going to get given that it's through-hole parts.  Again, layout is decent, but not great.  It could be improved substantially with surface mount parts, or a 4 layer board.  However, I still find it somewhat surprising that there's this much problem.  I never did try probing the XTAL line, it would be curious to see what it looks like (although I realize the probe capacitance would be way too high).

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

When you were using a crystal on the m16A, did you have CKOPT programmed to enable full-swing mode for the oscillator?  This gives the oscillator a rail-to-rail output, much more stable in a noisy environment.  Without it, the oscillator operates in a low-power mode, with more susceptibility to upsets.

 

The m16L also has 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."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

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

"Fast.  Cheap.  Good.  Pick two."

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

 

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

hpmaxim wrote:

I'll reiterate, I didn't design the circuit nor do I have sourcecode for the firmware, however, at this point, I tend to think it's not software.   There are definitely deficiencies in the design of the circuit, but it is reasonable.

 

If it doesn't work, it's not reasonable.

 

It might be rude, but I'm going to refer you once again to the last remark in post #11.  The "ask me how I know" came about because I had H-bridges on the same board as the uC, and got wonderful spurious resets, despite massive capacitance on the separate H-bridge power, until I whacked up the traces and fed the lines (power and ground) all the way back to the power supply some distance away separately.  

 

Previously, there'd been one 'power cable' to the board and had their common point at the connector.  Fortunately, I had spare pins on the 0.156" power connector.

 

At this point, I'm starting to wonder if it might be a better idea for you to start over with your own software and your own board, instead of trying to hack up a mess that someone else made.

 

 S.

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

joeymorin, CKOPT was unprogrammed (not full swing), the fuses were set at High = 0xDC/ Low= 0xFF (Low is now 0xE4)

Scrounge, the unit has a linear regulator on the board which has a load capacitance of 2000uF.  It then goes through a 12V regulator and a 5V regulator (in parallel not series).  The 5V regulator has 10uF, the 12V regulator (the one with the H-bridge) has 1000uF.  I think joey was actually on to something.  It wasn't just resets, it was glitchy behavior in general which makes me suspect a clock issue.

UPDATE: I can now confirm that fuse settings 0xCC/0xFF seems to yield stable behavior (same as 0xDC/0xE4)

Last Edited: Sat. Mar 28, 2020 - 01:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Put 220uF on the 5V rail.  S.