Argh. ATmega128 users, please help?

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.

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.

linnix wrote:

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

I'm glad someone else found this problem. I thought I was going mad.
You know, I'm not even sure how I came to the discovery any more. Maybe
I dropped solder on the circuit accidentally ;)

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

> > capacitance on these lines? (I've got about 15pF on both sides of the
>
> 15pF to 20pF sounds right.  Any other signals/traces near the clock
> circuit?

The xtal is <5mm from the IC. Traces run directly from the IC to the
xtal pins, and thence to the caps. Nothing runs under the xtal on the
component side of the board. There is groundplane on the solder side of
the board.

There are some signals running to adjacent pins on the micro, but
there's nothing I can do about that (and they were the same signals on
the previous spin of the board).

> > - Difficulty programming. Fuses are supposed to be 0x997f 0xff but most
>
> Same here.  Programming sometimes work and sometimes don't.

Why, why, why?? I have other h/w on the SPI interface otherwise I would
try ISP instead of JTAG. And why does it work OK on my older boards
(all that I built)? The only difference I can see is that the protos
were built with older chips (date code 0447I) and the finals were built
with date code 0609.

Was I supposed to put my own pullups/pulldowns/whatever on the JTAG
lines?

> > - 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
>
> Could be a software and/or compiler problem.

I believe there is some compiler issue - not sure what it is though -
but for this particular case... it's the same HEX file. Works OK on
board A. Fails on board B. What gives?!!

larwe wrote:
> linnix wrote:
>
> > > 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
>
> I'm glad someone else found this problem. I thought I was going mad.
> You know, I'm not even sure how I came to the discovery any more. Maybe
> I dropped solder on the circuit accidentally ;)
>
> > > 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.

Not the 128 in particular, but the newer fab processes might be
different.

>
> > > capacitance on these lines? (I've got about 15pF on both sides of the
> >
> > 15pF to 20pF sounds right.  Any other signals/traces near the clock
> > circuit?
>
> The xtal is <5mm from the IC. Traces run directly from the IC to the
> xtal pins, and thence to the caps. Nothing runs under the xtal on the
> component side of the board. There is groundplane on the solder side of
> the board.
>
> There are some signals running to adjacent pins on the micro, but
> there's nothing I can do about that (and they were the same signals on
> the previous spin of the board).
>
> > > - Difficulty programming. Fuses are supposed to be 0x997f 0xff but most
> >
> > Same here.  Programming sometimes work and sometimes don't.
>
> Why, why, why?? I have other h/w on the SPI interface otherwise I would
> try ISP instead of JTAG.

If you can't Jtag, isp probably won't work either.  Parallel
programming might be
better, if only to verify the problem.

> And why does it work OK on my older boards
> (all that I built)? The only difference I can see is that the protos
> were built with older chips (date code 0447I) and the finals were built
> with date code 0609.

Perhaps Atmel is still testing on their newer fabs.  Are you able to
try some older chips for your new board?  Your purchasing department
need to have a serious talk with Atmel.

Actually, my problems were with the boot loader.  Jtag seems to be
better, at least for the 169.  Even with the Atmel Jtag tool, sometimes
it take a couple of tries.

>
> Was I supposed to put my own pullups/pulldowns/whatever on the JTAG
> lines?

No, the Jtag tool should detect the target and adjust them if
necessary.

>
> > > - 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
> >
> > Could be a software and/or compiler problem.
>
> I believe there is some compiler issue - not sure what it is though -
> but for this particular case... it's the same HEX file. Works OK on
> board A. Fails on board B. What gives?!!

On 16 Apr 2006 16:00:41 -0700, "larwe" <zwsdotcom@gmail.com> 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).

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 
FET based probe. They have very high input impedance, and very low
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 
of coax, and connect the other end to your frequency counter then wave 
the loop around the xtal oscillator circuit. This has the advantage that the 
loop doesn't load the oscillator significantly.

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

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 
board 100% checked for continuity and short circuits before being loaded?
Did you check for possible differences between micros by swapping
the '128's between the development board and the production board?

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

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.
BTW, the '128 has the TWI which is similar to the I2C. Are you using this?
Have you checked your code using AVR Studio as opposed to gcc?
Someone has submitted to the website http://www.avrfreaks.net a project
"I2C Routines in GCC" early last year. The zip file is about 2.3K. I can't say
if it works, but it's there if you'd like to check it.

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

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.

Do you have a good ground on the board? Not just a few traces but a
flooded ground plane! was mostly our design problem with new boards
ew

-- 

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

Most Xtal Osc's have a sensitive side[IP] and not so sensistive 
side[OP]. AC coupling can help probe on the IP side.
Normally scope probe attach will (slightly) disturb the frequency,
and also make the phase sub-optimal, but it is rare to see it stop dead.

> Why, why, why?? I have other h/w on the SPI interface otherwise I would
> try ISP instead of JTAG. And why does it work OK on my older boards
> (all that I built)? The only difference I can see is that the protos
> were built with older chips (date code 0447I) and the finals were built
> with date code 0609.

> I believe there is some compiler issue - not sure what it is though -
> but for this particular case... it's the same HEX file. Works OK on
> board A. Fails on board B. What gives?!!

Clearly, there is some difference :)

Can you easily swap uC / Xtals ?

Try a lower F crystal, and see if that affects anything ?
With a uC near the upper freq limit, the Vcc becomes critical, and
with lower F, you have wider vcc tolerance.
A little series R on Xtal OP can help the phase margins.


Another thing to try in cases like this, is a CODE checksum ( but
I think most uC cannot read the fuses, so you have to just hope there...)

-jg

Jim Granville wrote:

> Most Xtal Osc's have a sensitive side[IP] and not so sensistive
> side[OP]. AC coupling can help probe on the IP side.
> Normally scope probe attach will (slightly) disturb the frequency,
> and also make the phase sub-optimal, but it is rare to see it stop dead.

This was just a quick-look thing - I wanted to check the amplitude. But
when I touch the probe to the xtal, the thing dies completely. Not what
I would expect at all.

> > but for this particular case... it's the same HEX file. Works OK on
> > board A. Fails on board B. What gives?!!
>
> Clearly, there is some difference :)

But it's so weird.

> Can you easily swap uC / Xtals ?

xtal is easy (however I think they are from the same batch - Digi-Key
stock. I think the reason there was such a big discrepancy in date code
between the micros is that the CM who made the prepro run used T&R
parts, and I used cut tape - Digi-Key's probably got a box full of
cut-tape parts dating back ages).

Micro not so easy, as I don't have hot air rework equipment. I can do
it, but it ain't gonna happen tonight. I did post a support question to
Atmel to see if they can tell me about any differences that happened
between these dates.

> Try a lower F crystal, and see if that affects anything ?

I'm about to go to bed, but I'll try this tomorrow.

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

Hi Ryan,

Ryan Weihl 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
> >
> > - Difficulty programming. Fuses are supposed to be 0x997f 0xff but
> > most of the time the 0x99 gets spontaneously reset to 0x20. Even when
>
> Do you have a good ground on the board? Not just a few traces but a
> flooded ground plane! was mostly our design problem with new boards

This is a two-layer board. The area in question has shortest possible
traces to xtal and from xtal to caps, and a solid ground on the other
end of the caps. The solder side of the board is solid copper pour.

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.

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

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

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

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

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