MEGA8535 reset problems?

You are quite experienced, but I'll suggest the obvious anyway.

Add 100 Ohm resistors in series with your servo control lines so they can't drive the output pin crazy with noise.

Watch the length of leads going to LCD panels. Make sure the LCD panel enable is pulled not enabled at the LCD.

What's connected to your board right now?

I can't think of anything specific, other than the usual suspects, most of which you've already named. But maybe this document will mention something you haven't tried yet:

It's a 17 page PDF doc entitled: "AVR040: EMC Design Considerations". Most of the info is of a general nature, but there are a few AVR specifics.

-Brian

(Handling two with one post) Alan,

The servos were fine, the 754410 is causing the problem. I know that it isn't noise on Vdd, that line is clean and solid. I'm looking for ideas on particular susceptabilities of the AVR, the MEGA's especially since this board works fine with a 90s8535, which are hard to get now, I upgraded to a MEGA8535 and have been having headaches.

Brian,

Nice paper, I missed that one from the Atmel site - The reset line looks like a likely candidate for attention.

thanks all! DLC

Brian Dean wrote: : :> Has anyone else seen odd behavior in the MEGA chips, or this chip :> in specific? I'm getting ready to start hanging bypass caps off of :> every line, in duplicate, just to be sure! Hmm, maybe wrapping the :> board in foil, or the motor leads, or batter leads or,... I just :> love EMI voodoo chases! I wonder if it's those crappy servo motors, :> hmm...

: I can't think of anything specific, other than the usual suspects, : most of which you've already named. But maybe this document will : mention something you haven't tried yet:

:

: It's a 17 page PDF doc entitled: "AVR040: EMC Design Considerations". : Most of the info is of a general nature, but there are a few AVR : specifics.

: -Brian : -- : Brian Dean, snipped-for-privacy@bdmicro.com : BDMICRO - Maker of the MAVRIC ATmega128 Dev Board :

What methodology did you use to determine it was the bridge and not the servos? I assume these are standard R/C servos, so what is the 754410 used for?

-- Gordon Author: Constructing Robot Bases (Forthcoming) Robot Builder's Sourcebook, Robot Builder's Bonanza

Gordon McComb wrote: Gordon,

Here is my non scientific assertion: The servos drove the robot fine, with no resets. When I pulled the electronics from the servos to run them with PWM from the 754410, the board started going through resets and lala land occurances. One thing I will have to look into is the reset line runs right next to the 754410, which, even though it is heavily bypassed, may still be inducing noise into the system (heck at only 4KHz too!)

DLC

: Dennis Clark wrote: :> The servos were fine, the 754410 is causing the problem. I know that it :> isn't noise on Vdd, that line is clean and solid. I'm looking for ideas :> on particular susceptabilities of the AVR, the MEGA's especially since :> this board works fine with a 90s8535, which are hard to get now, I upgraded :> to a MEGA8535 and have been having headaches.

: What methodology did you use to determine it was the bridge and not the : servos? I assume these are standard R/C servos, so what is the 754410 : used for?

: -- Gordon : Author: Constructing Robot Bases (Forthcoming) : Robot Builder's Sourcebook, Robot Builder's Bonanza

Do you have a pullup resistor on the reset line? Also you have a bypass cap on the reset line as well? Are the motors powered off the same battery as the MCU? This is a big cause of lots of problems like this. If you run separate batteries for the MCU and the motors, does that help solve the problem? If it does that narrows down what the problem is etc.

============================================================================

*

============================================================================

Earl Bollinger wrote: Earl,

I have a pullup and a cap AND a DS1233 supervisor on the reset line. The motors are powered by the same battery (same as when they were servo controlled) and that line is well filtered and protected against momentary motor brownout - A circuit I use a lot and have good history with. Even when the motors are run from a separate battery I still have the reset issues occur.

I added the DS1233 supervisor to the reset line because the chip would not reliably turn on with a pullup and cap on the reset line. These reset problems I just didn't have when I was using a 90S8535 on the same board.

hmmm, dlc

: Do you have a pullup resistor on the reset line? Also you have a bypass : cap on the reset line as well? : Are the motors powered off the same battery as the MCU? : This is a big cause of lots of problems like this. If you run separate : batteries for the MCU and the motors, does that help solve the problem? : If it does that narrows down what the problem is etc.

:> Here is my non scientific assertion: :> The servos drove the robot fine, with no resets. When I pulled the :> electronics from the servos to run them with PWM from the 754410, the :> board started going through resets and lala land occurances. One thing :> I will have to look into is the reset line runs right next to the 754410, :> which, even though it is heavily bypassed, may still be inducing noise :> into the system (heck at only 4KHz too!) :>

:> DLC :>

:> : Dennis Clark wrote: :> :> The servos were fine, the 754410 is causing the problem. I know that : it :> :> isn't noise on Vdd, that line is clean and solid. I'm looking for : ideas :> :> on particular susceptabilities of the AVR, the MEGA's especially since :> :> this board works fine with a 90s8535, which are hard to get now, I : upgraded :> :> to a MEGA8535 and have been having headaches. :>

:> : What methodology did you use to determine it was the bridge and not the :> : servos? I assume these are standard R/C servos, so what is the 754410 :> : used for? :>

:> : -- Gordon :> : Author: Constructing Robot Bases (Forthcoming) :> : Robot Builder's Sourcebook, Robot Builder's Bonanza :>

:> -- :>

: ============================================================================ :> * Dennis Clark snipped-for-privacy@frii.com

: * :> * "Programming and Customizing the OOPic Microcontroller" Mcgraw-Hill 2003 : * :>

: ============================================================================

I tool a look at the MEGA8535 specs and have some questions for you. (note: I haven't dug through any errata)

What is your VCC voltage?

What brownout detection setting are you using? What does your power supply look like?

Have you tried taking a snapshot of the MCU Control and Status register when a reset occurs (latch its contents out to I/O pins, or if you have a debugger, breakpoint after a reset and look at it, etc.). It might help narrow down on the source of your reset.

Table 15 and Figures 166-168 and 194 are interesting.

Some microcontrollers will spec the maximum rise and fall times of the reset line. Atmel doesn't, so it's hard to say what it expects (it's worth a phone call to an application engineer). The DS1233 has a 5K pullup. What size cap have you added? What size external pullup are you using? If you're transitioning too slow you may have some strange results (i.e. different sections of the micro may or may not reset, or may not completely reset).

Another spec that's commonly given is if the micro needs a certain number of clock cycles before reset goes inactive. The Atmel spec states that external reset will work even in the absence of a clock. They do have some interesting power up delay settings for different oscillator configurations and power up scenarios. What are you using for the settings? What is your oscillator configuration?

With the built in power on reset and brownout detection, do you really need an external reset controller? Could you temporarily disconnect the reset line altogether (cut the trace), eliminating the question of crosstalk?

Sometimes the simplest problems are the hardest to debug...

--Jay

Jay Francis wrote: Jay,

Thanks for the commentary. For the sake of argument, I'll respond, heck, maybe someone will see something that I missed.

:> I have a pullup and a cap AND a DS1233 supervisor on the reset line

: I tool a look at the MEGA8535 specs and have some questions for you. (note: I : haven't dug through any errata)

: What is your VCC voltage?

4.98 V

: What brownout detection setting are you using? What does your power supply : look like?

The supervisor, I've turned BOD off in the chip.

: Have you tried taking a snapshot of the MCU Control and Status register when a : reset occurs (latch its contents out to I/O pins, or if you have a debugger, : breakpoint after a reset and look at it, etc.). It might help narrow down on : the source of your reset.

I've looked, but for the life of me I don't find a register that tells me that I just had a reset - or for what purpose it reset. The PIC has me spoiled there, it DOES have a register that tells that. I suppose that I could just spit something out at the beginning of the program, assuming a reset, I'll hold that thought in reserve, it is a bit of a pain to do that.

: Table 15 and Figures 166-168 and 194 are interesting.

Table 15 was my first study. However, my MEGA8535 doc stops at figure

130, where did you get yours?

: Some microcontrollers will spec the maximum rise and fall times of the reset : line. Atmel doesn't, so it's hard to say what it expects (it's worth a phone : call to an application engineer). The DS1233 has a 5K pullup. What size cap : have you added? What size external pullup are you using? If you're : transitioning too slow you may have some strange results (i.e. different : sections of the micro may or may not reset, or may not completely reset).

10K, .1uf, well in the spec for the chip, which is a ds1233-10, so 4.25 to about 4.5V is the trip point. I've put a scope on the 5V line and it is as clean as driven snow, no noise there at all.

: Another spec that's commonly given is if the micro needs a certain number of : clock cycles before reset goes inactive. The Atmel spec states that external : reset will work even in the absence of a clock. They do have some interesting : power up delay settings for different oscillator configurations and power up : scenarios. What are you using for the settings? What is your oscillator : configuration?

Slow power rampup, external resonator. Using a 16MHz resonator.

: With the built in power on reset and brownout detection, do you really need an : external reset controller? Could you temporarily disconnect the reset line : altogether (cut the trace), eliminating the question of crosstalk?

I found that it did not properly reset the board on power up, that is the reason that I added the supervisor. I'll try the trace cut again, but since I use the reset line for the ICSP, there is a limit to what I can cut out. There is a possibility (potentially high) that the two issues are related. As you noted, Atmel doesn't GIVE a spec on the reset/power issue so deciding what to use becomes a matter of picking what worked _last_ time!

: Sometimes the simplest problems are the hardest to debug...

No doubt. I may end up taking this one back "to the board" for a re-evaluation of the PCB design. Thanks, DLC

: --Jay

Hi Dennis,

I'm glad you responded. My intent was to help, I hope I didn't offend! Sometimes asking the obvious and/or basic questions leads to the solution.

They usually lead me to a "Homer Simpson" moment... Doh!!!

I'd like to respond somewhat out of order.

The revision in the lower right corner of each page is 2502D-AVR-09/03. On the web site they call it the "Preliminary Complete" document (315 pages, Updated

9/03).

I think this is a clue that something basic isn't quite right.

Are you using the MEGA8535 or the MEGA8535L? I'll assume the MEGA8535, since the L part has a maximum frequency of 8MHz, but let me know.

Do you have the CKOPT fuse programmed (page 24 of the datasheet)?

Note 3 for Table 15 is interesting. Maybe your part snuck through without being "production tested" for that parameter? You might want to try a DS1233-5 to tighten the reset tolerance to be in line with the 4.5V minimum VCC spec of the micro.

What if you went back to using the on-chip power on reset and brown out detection - but do not add any external components to the reset line (in a previous post you mentioned having an R/C circuit on the reset line)?

In the datasheet I have, page 38 shows the MCUCSR register.

Not to be too picky, but the DS1233 datasheet recommends between 100pf and

0.01uF when using a pushbutton switch. Do you have a switch connected?

The internal pullup is between 3.75K and 6.25K, so your 10K resistor brings the total resistance between 2.7K and 3.8K. Do you still have the problem with the cap and resistor removed?

Random questions:

What type of scope are you using to look at the VCC and reset lines?

What if you run the processor slower? (i.e. 8MHz, if it doesn't require a ton of software changes)

--Jay

Jay Francis wrote: : Hi Dennis, :> For the sake of argument, I'll respond, heck, :>maybe someone will see something that I missed.

: I'm glad you responded. My intent was to help, I hope I didn't offend! : Sometimes asking the obvious and/or basic questions leads to the solution. Anyone that is easily offended should stay off the 'net.

: They usually lead me to a "Homer Simpson" moment... Doh!!! :>my MEGA8535 doc stops at figure :>130, where did you get yours?

:

The revision in the lower right corner of each page is 2502D-AVR-09/03.

I must have gotten a very early preliminary one, I downloaded the new one and gots LOTS of new info that wasn't in the one that I had. Still, finding fuse settings in there is like searching for a needle in a haystack, or rather 4 parts of a needle in different places of the haystack...

:> I found that it did not properly reset the board on power up, that is the :>reason that I added the supervisor.

: I think this is a clue that something basic isn't quite right.

Indeed.

: Are you using the MEGA8535 or the MEGA8535L? I'll assume the MEGA8535, since : the L part has a maximum frequency of 8MHz, but let me know.

: Do you have the CKOPT fuse programmed (page 24 of the datasheet)?

I did not explicitly set this. I'll check on that one.

: Note 3 for Table 15 is interesting. Maybe your part snuck through without : being "production tested" for that parameter? You might want to try a DS1233-5 : to tighten the reset tolerance to be in line with the 4.5V minimum VCC spec of : the micro.

: What if you went back to using the on-chip power on reset and brown out : detection - but do not add any external components to the reset line (in a : previous post you mentioned having an R/C circuit on the reset line)?

:> I've looked, but for the life of me I don't find a register that tells :>me that I just had a reset

: In the datasheet I have, page 38 shows the MCUCSR register.

Yeah, I found that right after I posted. "Doh!"

:>10K, .1uf, well in the spec for the chip, which is a ds1233-10, so 4.25 to :>about 4.5V is the trip point.

: Not to be too picky, but the DS1233 datasheet recommends between 100pf and : 0.01uF when using a pushbutton switch. Do you have a switch connected?

: The internal pullup is between 3.75K and 6.25K, so your 10K resistor brings the : total resistance between 2.7K and 3.8K. Do you still have the problem with the : cap and resistor removed?

I'll try some more of these tests and checks. Some part swaps, etc. My standard RC for reset is 10K, .1uf - The DS1233 was "cockroached" on, that is why the older RC is still there, it seemed like it wasn't contraindicated as a bad combination.

: Random questions:

: What type of scope are you using to look at the VCC and reset lines?

25MHz analog scope.

: What if you run the processor slower? (i.e. 8MHz, if it doesn't require a ton : of software changes)

I noted some settings in the clock section were not recommended when running the clock near maximum settings, which I am - when all else fails, I'll try dropping the frequency.

: --Jay

You've given a wealth of insight here. I am an old hand at the PICs, but this is one of my early sortees into using Atmel as a controller, so I'm not yet hip to all of the caveats.

thanks, ============================================================================

• Dennis Clark snipped-for-privacy@frii.com
  formatting link
  *

• "Programming and Customizing the OOPic Microcontroller" Mcgraw-Hill 2003 * ============================================================================

I'm not to the level of super-AVR programmer, but I do know one thing: I always stay away from their brand new chips. Now, I'm not trying to dis Atmel, and I love AVR controllers. But every time I've been a pioneer on a new chip I've taken it up the backside. The issues all have work-arounds in the end, and in my experience, later iterations of the chips fix the egregious issues. You have to weigh the pros of using a new technology with the cons of the timesink of discovering the hidden gotchas of the chip.

It's all just very possible there is a quirk in this chip. Or the chip is okay, but the batch that you got sucks.

Some silly notes that I'm sure you've already thought about:

1. Have you tried a slower crystal? For the heck of it, what happens when you use a 4.0 or 8.0 MHz crystal?

1. I might have missed it, but did you add those 100-1K ohm (or so) resistors in-line between the AVR and the bridge? No matter what the docs say, the bridge may be trying to pull too much current from the AVR.

2. Are you using the ADC I/O for any of this (PA0 to PA7), even if you're not using ADC? If so, suggest you move to another port, at least for testing.

1. Connected with the above, if the bridge is on some port other than A, are you using ADC for any functions, like a Sharp distance judgement sensor? If so, try disabling that code to see what happens.

2. For the heck of it, can you breadboard a buffer between the AVR and the bridge?

1. Dumbass idea here, but can you put a dummy load on the bridge to simulate current draw without any EMI and/or RF? If the problem persists, it's the bridge (and maybe excessive current draw from it). That would definitely rule out EMI/RF as the causitive factor. I'm assuming you've got some honking resistors around your shop somewheres that aren't wire-wound.

2. Finally, you've ruled out that the bridge is operating to spec, and that it's not some wacky floor-sweeping part you picked up surplus making you suspect a perfectly good AVR controller. Now that would be a slapper!!

Anyway, when you get this worked out be sure to let us know what the problem is, so the rest of us can avoid it! We'll declare a national holiday in your honor.

-- Gordon Author: Constructing Robot Bases (Forthcoming) Robot Builder's Sourcebook, Robot Builder's Bonanza

To all my helpers, here is the summary of progress and what finally worked.

OK, I tried these things:

read and printed out reset reasons at every startup,

• Found that watchdog was the reset reason (OTL code)

took off motors and put dummy loads on,

• No board OTL problems (hmm)

rebuilt the reset circuit to most pessimistic docs pulled reset circuit minimal reset circuit Tried alternate reset/powerup fuses two battery packs (one for the motors) Dropped clock down to 8MHz Eliminated the reset supervisor

The winner was:... dropped frequency to 8MHz. After I did this the board was solid as a rock, no reset line supervisor was needed, nothing. Everything worked great. It seems clear to me that CFI is the reason for my problems and that at 16MHz the MEGA8535 is hyper sensitive to it. For the current board the solution is obvious, clock down. I'm loathe to lose any speed, but I console myself by thinking that even at 8MHz the chip is faster than a 32MHz PIC. Sigh. The next rev of the board will work on CFI issues to bullet proof the CPU and protect it from interference. Shorter Vdd lines and perhaps a choke on the power line into the CPU will do good, better ground plane guards around the crystal circuit and isolation of the motor power section come to mind. I'm obviously conducting radiated energy to CPU lines somewhere, more effort will go into finding out which ones. The board works fine by itself and poorly near DC motors.

Thanks for all the help guys, the pointers to AVR specifics and the correct Atmel design docs were a winner.

ta, DLC

Dennis - one last thing, maybe you tried this. Someone else mentioned the CKOPT fuse bit. Be sure that is programmed for running at the higher clock speed. It enables a full rail to rail clock swing which is necessary for higher speed clocking. Without it, the higher clock speeds are dodgy at best and plain don't work at all at worst.

When I ship my assembled and tested MAVRIC / MAVRIC-II boards, I pre-program the fuses for the board to run at 16 MHz external clock. The CKOPT fuse bit is one of the ones that I enable. It's there because at lower clock speeds, leaving it unprogrammed will result in less power consumption. But it's necessary at higher clocks.

Hoping that will work ...

Cheers,

-Brian

[snip] : Dennis - one last thing, maybe you tried this. Someone else mentioned : the CKOPT fuse bit. Be sure that is programmed for running at the : higher clock speed. It enables a full rail to rail clock swing which : is necessary for higher speed clocking. Without it, the higher clock : speeds are dodgy at best and plain don't work at all at worst.

Brian, I forgot to mention that - CKOPT was programmed indeed for high speed external crystal/resonator, and using the fuses optimized for slow rising power and resonator use. I had to get my STK500 up and running to do that - I do most of my programming on the AVR in Bascom or Codevision, I was using Bascom on this one and it has poorly defined fuse bits, so I had to get my trusty AVRstudio out to set those up.

This is the first board I've done with the AVR's using motor drivers on the board, it has been a real learning experience!

thanks, DLC

Hi Dennis,

Glad to hear you got something to work!

If you're still in the experimenting mood, have you tried a different MEGA8535? How about using an external 16MHz oscillator or crystal instead of the resonator? Maybe try a different resonator?

And one last silly question (I asked before, but I didn't see an answer) - it's not an "L" version part, is it?

Gordon had commented earlier on the difficulties of using new chips from Atmel. This is typical of using a new product from almost any vendor, although some are more thorough in their testing and documentation than others.

--Jay

Jay Francis wrote: Jay,

It is not an L part, unless it was mislabeled. ;) Since I'm using PLCC parts, getting one of those out of a socket intact, and not breaking the socket is just this side impossible, I don't have any special tools for that. I've not tried other resonators or crystals, the 14.yadayada comes to mind to get good UART dividers.

I'll post more as I learn more - Talk about an interesting design and test process!

thanks, dlc

: Hi Dennis,

: Glad to hear you got something to work!

: If you're still in the experimenting mood, have you tried a different MEGA8535? : How about using an external 16MHz oscillator or crystal instead of the : resonator? Maybe try a different resonator?

: And one last silly question (I asked before, but I didn't see an answer) - it's : not an "L" version part, is it?

: Gordon had commented earlier on the difficulties of using new chips from Atmel. : This is typical of using a new product from almost any vendor, although some : are more thorough in their testing and documentation than others.

: --Jay