Argh. ATmega128 users, please help?

larwe wrote:
> Jim Granville wrote:
>>With a uC near the upper freq limit, the Vcc becomes critical, and
>>with lower F, you have wider vcc tolerance.
> 
> 
> The uC runs off a 5V reg supply, which is very solid and accurate... I
> don't think it's a Vcc issue.
> 
> Thanks for the suggestions..

  I'll clarify the Vcc comment : When you run a uC at the max F, it has
the least tolerance of Vcc dips, and sometimes you can find the brownout
has a 'dead band' between BOD On, and the Spec for Valid CPU operation.
  So, it's not so much how the 5V behaves in regulation, but what it
does getting there, and how the Osc starts / BOD activates etc.
  That said, you also describe errant fuse states, and I don't think
even a completely lost uC, can repgm the config fuses.... ?
  A lost IAP capable uC can certainly mess with the CODE space.
[That's where the code checksum comes in ..]
-jg

larwe wrote:

> I've got to the point in a project where I am questioning all my
> assumptions and basically losing hair apace. My circuit is based around
> an ATmega128, running at 16MHz off an ext xtal. The prototype board
> worked 100% fine after I tied VREF to +5V; apparently the JTAG
> interface isn't happy unless VREF is present. My "final" board - with
> no substantial change from the old circuit - is behaving really weirdly
> and I can't understand it.
> 
> My main question is: do you normally see this micro stop when you
> attempt to probe the xtal lines with a scope? Do I have too much load
> capacitance on these lines? (I've got about 15pF on both sides of the
> xtal. When I put a probe on either line, the micro stops; I don't see
> any oscillation on the scope, either).

Lewin,

Do you realize the Mega128 has two drive voltages for the XTAL out, and 
the default fuse (CKOPT) is for the lower voltage?  (Docs on this point 
are oddly buried in prose instead of clearly in a table.)  Perhaps 
something about your newer board / MCU lot is too marginal, and probing 
the XTAL is enough to stall it?

This had me scratching my head once, wondering why I was seeing such a 
weak signal on the XTAL leads.  But probing XTAL wasn't a problem.

Hopefully this is your silver bullet for the XTAL... and that the root 
cause of your other ills is just an unstable clock.

Cheers,
Richard

On 16 Apr 2006 21:06:40 -0700, "larwe" <zwsdotcom@gmail.com> wrote:

>Hi,
>
>dmm wrote:
>
>> >attempt to probe the xtal lines with a scope? Do I have too much load
>>
>> It's likely that your cro probe has too much capacitance, and is loading down
>> the xtal lines. If you want to view the amplitude of the xtal signals, use a
>
>I can believe this, but does that normally happen on this particular
>uC, or does it indicate that my current design is right on the hairy
>edge as far as load capacitance? I've not seen this happen before, not
>on a micro anyway. Bringing in a regular probe might alter the
>oscillator a bit but it doesn't normally STOP it.

A x1 100MHz cro probe may have a capacitance as high as 90pF. A x10
probe may be about 10-15pF. The 90pF extra loading will likely stop the oscillator
at the Xin pin, and possibly at the Xout pin. Check what loading your probe
has by connecting it to a 555 timer using the probe's capacitance as part
of the timing element. Monitor pin 3 of the 555 with a frequency counter.
You can then work out the true probe capacitance using the values of the
resistors used and the 555 formula.
You can then substitute the capacitance of the probe across Xin by
soldering in the equivalent value of capacitance and see if the clock stops.

>> input capacitance and are typically fairly expensive. If you only want to
>> verify the operating frequency, create a small loop at one end of a piece
>
>I wanted to verify the waveform's amplitude and shape (check for
>clipping, for instance).

A FET probe is probably best for this, or at least a low capacitance x10 probe
if you've got one. Could you check it at work using one of the cros in your lunch break?

>> Check that all the legs of the components are soldered to their respective
>> pads, and that there aren't any shorts between adjacent pads. Was the
>
>I've checked the relevant parts of the board and gone all over the
>micro. Also tried disconnecting a "gate" (0 ohm Rs) that feeds the I2C
>devices, and manually wiring SDA and SCL to just one of the I2C chips,
>no change in behavior. Note that the prepro run was 50 boards, of which
>20-some have been tested now. The customer didn't get any of them
>working. I got the one he sent me working after some initial difficulty
>programming the fuses (which I foolishly ignored...) but when I sent it
>back to him, it didn't work in his environment. Something really weird
>is going on.

Have you checked the bus capacitance? According to the 2000 spec (ver 2.1)
for a bus speed of 400KHz the maximum bus capacitance is 400pF.
Many multimeters have capacitance checkers on board.

>> Did you check for possible differences between micros by swapping
>> the '128's between the development board and the production board?
>
>That I haven't done yet; I've not got the equipment to do that nicely.
>I will have to remove the "bad" micro destructively off the new board
>and solder in one of my stock of old micros.
>
>> >- Code that works 100% fine on the old board misbehaves on the new
>> >board - specifically I've got some I2C stuff that works OK if I inline
>> >it, but doesn't do anything if I put it inside a subroutine (!). I
>>
>> Have you looked at the code generated when you have the I2C() function
>> inserted into the source? As a first guess I'd suspect the function interface.
>
>I've poked into the asm but haven't seen anything obviously wrong. The
>thing is, why does it work perfectly on board A, but the exact same
>binary doesn't work on board B?

I'd look at the bus capacitance first. Do you have any pullups on the SCL and SDA
lines?

>> BTW, the '128 has the TWI which is similar to the I2C. Are you using this?
>
>Yes.
>
>> Have you checked your code using AVR Studio as opposed to gcc?
>
>err.. how? It's in C, you mean I should try to assemble it with Atmel's
>assembler?

Yes. Perhaps there's some differences in the binary code generated in AVR Studio 
and GCC.

>> Someone has submitted to the website http://www.avrfreaks.net a project
>
>I'll have a look at that, but I think I'm fighting a hardware problem
>here - all my I2C I/O stuff worked fine on the old board and the wiring
>is identical.

"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1145230800.506174.296170@i40g2000cwc.googlegroups.com...
>
> linnix wrote:
>
>> > My main question is: do you normally see this micro stop when you
>> > attempt to probe the xtal lines with a scope?
>>
>> That I would not try to do.  Crystal circuits are very sensitive.  I
>> would just verify it indirectly, through internal counters/dividers.
>
> Erk. But I wanted to check the amplitude of the xtal drive. It hasn't
> been a problem on other AVR ckts (or other micros) I've built. I was
> wondering if there is something magical about the m128.

I've seen this behaviour with a 32kHz RTC XTAL. It was actually working 
fine, but any attempt to probe the XTAL lines would stop the clock.

Re your other problems: is your VCC coming up cleanly? Is the reset 
generator allowing enough delay after VCC is established? I've known micros 
do very odd things when only partially reset. (I'm sure you know this, but 
hey...)

Steve
http://www.fivetrees.com 

larwe wrote:

> My main question is: do you normally see this micro stop when you
> attempt to probe the xtal lines with a scope? Do I have too much load
> capacitance on these lines? (I've got about 15pF on both sides of the
> xtal. When I put a probe on either line, the micro stops; I don't see
> any oscillation on the scope, either).
> 
> Here's what I'm seeing, FWIW:
> 
> - Difficulty programming. Fuses are supposed to be 0x997f 0xff but most
> of the time the 0x99 gets spontaneously reset to 0x20. Even when the
> fuses and program write verify OK, the board doesn't always power up
> correctly. Bear in mind that all the micro-related stuff is
> electrically unchanged from the old design, which does work. The only
> thing that really changed is layout.
> 
> - Code that works 100% fine on the old board misbehaves on the new
> board - specifically I've got some I2C stuff that works OK if I inline
> it, but doesn't do anything if I put it inside a subroutine (!). I
> can't believe this is timing-related, because I've got long (multi-ms)
> delays inside this code, a call/ret is negligible by comparison.
> 
> - I know the clock is running at the right speed, because I put a
> strobe in a timer ISR and it is dead on the money.
> 
> - A board I programmed successfully here in NY was DOA when it arrived
> back at the customer. When he tried to read back the fuses, they were
> totally bogus values.


I tend to have 27pF on both Xtal connections.
XTAL_1 is the input, XTAL_2 is the output of
the oscillator, meaning you should probe XTAL_2.
I never had problems with direct XTAL measurements.

I have 100nF directly on all Vcc connections to GND.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

"linnix" <me@linnix.info-for.us> wrote in
news:1145230263.634321.253010@i40g2000cwc.googlegroups.com: 

> 
> larwe wrote:
>> I've got to the point in a project where I am questioning all my
>> assumptions and basically losing hair apace.
> 
> Very similiar to my experiences with the 169.
> 
>> My circuit is based around
>> an ATmega128, running at 16MHz off an ext xtal. The prototype board
>> worked 100% fine after I tied VREF to +5V; apparently the JTAG
>> interface isn't happy unless VREF is present.
> 
> I wish Atmel would document this, Vref is supposed to be analog
> related only.
> 
>> My "final" board - with
>> no substantial change from the old circuit - is behaving really
>> weirdly and I can't understand it.
>>
>> My main question is: do you normally see this micro stop when you
>> attempt to probe the xtal lines with a scope?
> 
> That I would not try to do.  Crystal circuits are very sensitive.  I
> would just verify it indirectly, through internal counters/dividers.
> 
>> Do I have too much load
>> capacitance on these lines? (I've got about 15pF on both sides of the
>> xtal. When I put a probe on either line, the micro stops; I don't see
>> any oscillation on the scope, either).
> 
> 15pF to 20pF sounds right.  Any other signals/traces near the clock
> circuit?
> 
>>
>>
>>
>> Here's what I'm seeing, FWIW:
>>
>> - Difficulty programming. Fuses are supposed to be 0x997f 0xff but
>> most of the time the 0x99 gets spontaneously reset to 0x20. Even when
>> the fuses and program write verify OK, the board doesn't always power
>> up correctly. Bear in mind that all the micro-related stuff is
>> electrically unchanged from the old design, which does work. The only
>> thing that really changed is layout.
> 
> Same here.  Programming sometimes work and sometimes don't.
> 
>>
>> - Code that works 100% fine on the old board misbehaves on the new
>> board - specifically I've got some I2C stuff that works OK if I
>> inline it, but doesn't do anything if I put it inside a subroutine
>> (!). I can't believe this is timing-related, because I've got long
>> (multi-ms) delays inside this code, a call/ret is negligible by
>> comparison. 
> 
> Could be a software and/or compiler problem.
> 
>>
>> - I know the clock is running at the right speed, because I put a
>> strobe in a timer ISR and it is dead on the money.
> 
> Then don't worry about the crystal lines.
> 
>>
>> - A board I programmed successfully here in NY was DOA when it
>> arrived back at the customer. When he tried to read back the fuses,
>> they were totally bogus values.
> 
> Atmel's flash technology is less than perfect.
> 
> 


The strangest things can happen when a Vcc or gnd pin is missed or not
connected on a multi-gnd/vcc device. It would explain much of your
strange behaviour. (and that of your pcb too:-) 

Always pays to recheck every power pin.

-Andrew M

larwe wrote:

> I've got to the point in a project where I am questioning all my
> assumptions and basically losing hair apace. My circuit is based around
> an ATmega128, running at 16MHz off an ext xtal. The prototype board
> worked 100% fine after I tied VREF to +5V; apparently the JTAG
> interface isn't happy unless VREF is present. My "final" board - with
> no substantial change from the old circuit - is behaving really weirdly
> and I can't understand it.
> 
> My main question is: do you normally see this micro stop when you
> attempt to probe the xtal lines with a scope? Do I have too much load
> capacitance on these lines? (I've got about 15pF on both sides of the
> xtal. When I put a probe on either line, the micro stops; I don't see
> any oscillation on the scope, either).
> 
> 
> 
> Here's what I'm seeing, FWIW:
> 
> - Difficulty programming. Fuses are supposed to be 0x997f 0xff but most
> of the time the 0x99 gets spontaneously reset to 0x20. Even when the
> fuses and program write verify OK, the board doesn't always power up
> correctly. Bear in mind that all the micro-related stuff is
> electrically unchanged from the old design, which does work. The only
> thing that really changed is layout.
> 
> - Code that works 100% fine on the old board misbehaves on the new
> board - specifically I've got some I2C stuff that works OK if I inline
> it, but doesn't do anything if I put it inside a subroutine (!). I
> can't believe this is timing-related, because I've got long (multi-ms)
> delays inside this code, a call/ret is negligible by comparison.
> 
> - I know the clock is running at the right speed, because I put a
> strobe in a timer ISR and it is dead on the money.
> 
> - A board I programmed successfully here in NY was DOA when it arrived
> back at the customer. When he tried to read back the fuses, they were
> totally bogus values.
> 
I grew up with way-cheap o scopes, so I learned this trick:  Try 150pF 
caps to ground, with 18pF caps to the crystal.  If you probe across the 
150pF caps that makes a roughly 10:1 AC voltage divider (you can go more 
aggressive than that, of course).  Usually this stops any marginal 
crystal problems.

If you suspect the crystal oscillator you can always play around with 
the cap values, to see how close to the edge you are.  Better, get out 
your freeze spray and a heat gun to check operation over temperature.

Do you have the same number of bypass caps as the eval board, with 
similar placement?

Has the silicon rev changed with the date code?  Has the flash 
programming algorithm changed with the silicon rev?  TI made a habit of 
pulling the rug out from underneath customers' feet with flash 
programming on the early versions of the '2812 -- perhaps Atmel felt 
left out of the joke?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Rene Tschaggelar" <none@none.net> wrote in message 
news:44435fd2$1_3@news.bluewin.ch...
> larwe wrote:
>
>> My main question is: do you normally see this micro stop when you
>> attempt to probe the xtal lines with a scope? Do I have too much load
>> capacitance on these lines? (I've got about 15pF on both sides of the
>> xtal. When I put a probe on either line, the micro stops; I don't see
>> any oscillation on the scope, either).
>>
>> Here's what I'm seeing, FWIW:
>>
>> - Difficulty programming. Fuses are supposed to be 0x997f 0xff but most
>> of the time the 0x99 gets spontaneously reset to 0x20. Even when the
>> fuses and program write verify OK, the board doesn't always power up
>> correctly. Bear in mind that all the micro-related stuff is
>> electrically unchanged from the old design, which does work. The only
>> thing that really changed is layout.
>>
>> - Code that works 100% fine on the old board misbehaves on the new
>> board - specifically I've got some I2C stuff that works OK if I inline
>> it, but doesn't do anything if I put it inside a subroutine (!). I
>> can't believe this is timing-related, because I've got long (multi-ms)
>> delays inside this code, a call/ret is negligible by comparison.
>>
>> - I know the clock is running at the right speed, because I put a
>> strobe in a timer ISR and it is dead on the money.
>>
>> - A board I programmed successfully here in NY was DOA when it arrived
>> back at the customer. When he tried to read back the fuses, they were
>> totally bogus values.
>
>
> I tend to have 27pF on both Xtal connections.
> XTAL_1 is the input, XTAL_2 is the output of
> the oscillator, meaning you should probe XTAL_2.
> I never had problems with direct XTAL measurements.
>
> I have 100nF directly on all Vcc connections to GND.
>
> Rene
> -- 
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
> & commercial newsgroups - http://www.talkto.net
Usually I can easily probe XTAL and even clock other devices from it if I 
set COPT fuse.
Alex. 

Jim Granville wrote:
> larwe wrote:
> > Jim Granville wrote:
> >>With a uC near the upper freq limit, the Vcc becomes critical, and
> >>with lower F, you have wider vcc tolerance.
> >
> >
> > The uC runs off a 5V reg supply, which is very solid and accurate... I
> > don't think it's a Vcc issue.
> >
> > Thanks for the suggestions..
>
>   I'll clarify the Vcc comment : When you run a uC at the max F, it has
> the least tolerance of Vcc dips,

The 128 can run at 16MHz between 2.7V and 5V Vcc.  Vref should have a
low-passed filter for cleaner voltage source.

> and sometimes you can find the brownout
> has a 'dead band' between BOD On, and the Spec for Valid CPU operation.
>   So, it's not so much how the 5V behaves in regulation, but what it
> does getting there, and how the Osc starts / BOD activates etc.

Jtag has it's own clock, so it should not rely on the Osc.

>   That said, you also describe errant fuse states, and I don't think
> even a completely lost uC, can repgm the config fuses.... ?

Jtag should be able to repgm most, except for the Jtag enable/disable
bit of course.

>   A lost IAP capable uC can certainly mess with the CODE space.

That would be a very poorly designed uC and unacceptable embedded
device.  Flash codes and config bits are not supposed to change even
with unstable power source, as long as the chip is not in the mid of a
programming cycle.


> [That's where the code checksum comes in ..]
> -jg

On Sun, 16 Apr 2006 22:47:04 -0700, "Richard H." <rh86@no.spam> wrote:


>Do you realize the Mega128 has two drive voltages for the XTAL out, and 
>the default fuse (CKOPT) is for the lower voltage?  (Docs on this point 
>are oddly buried in prose instead of clearly in a table.)  Perhaps 
>something about your newer board / MCU lot is too marginal, and probing 
>the XTAL is enough to stall it?
>
>This had me scratching my head once, wondering why I was seeing such a 
>weak signal on the XTAL leads.  But probing XTAL wasn't a problem.
>
>Hopefully this is your silver bullet for the XTAL... and that the root 
>cause of your other ills is just an unstable clock.

There have been a couple of threads in the Yahoo group "AVR-Chat" on the subject
and this would certainly seem to be a problem. One respected contributor (Dave
VanHorn) posted:-
"You definitely want the CKOPT fuse checked, in the studio programmer.
Otherwise, you have selected "vittoz" mode oscillator, which has low
amplitude, and can cause odd timing results, wrong baud rates, and
all sorts of other grief, unless you know exactly what you are doing,
and pay a LOT of attention to oscillator design."



Geo