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:
Very similiar to my experiences with the 169.

I wish Atmel would document this, Vref is supposed to be analog related
only.

That I would not try to do. Crystal circuits are very sensitive. I
would just verify it indirectly, through internal counters/dividers.

15pF to 20pF sounds right. Any other signals/traces near the clock
circuit?

Same here. Programming sometimes work and sometimes don't.

Could be a software and/or compiler problem.

Then don't worry about the crystal lines.

Atmel's flash technology is less than perfect.

linnix wrote:

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

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.

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

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?

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:
Not the 128 in particular, but the newer fab processes might be
different.

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

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.

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

On 16 Apr 2006 16:00:41 -0700, "larwe" <zwsdotcom@gmail.com> wrote:

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.

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?

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.

larwe wrote:

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

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:

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 it's so weird.

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.

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

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:

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:

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.

I wanted to verify the waveform's amplitude and shape (check for
clipping, for instance).

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.

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.

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?

Yes.

err.. how? It's in C, you mean I should try to assemble it with Atmel's
assembler?

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

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:

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.

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?

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.

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

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

"larwe" <zwsdotcom@gmail.com> wrote in message
news:1145230800.506174.296170@i40g2000cwc.googlegr oups.com...
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:


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.googlegr oups.com:


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:

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...
set COPT fuse.
Alex.

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

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

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

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.

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


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