Argh. ATmega128 users, please help?

Stef 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.
> >
> But there are also traces on the solder side I presume? Have you pre-

Yes, but none in the area of the xtal. It's pressed up close against
the side of the micro, and it happens that there are no other traces
running on that side of the board in the area. Certainly nothing runs
underneath it.

> routed your ground to be sure of short connections, or do you rely on
> the copper pour?

The general algorithm I followed to lay out this board was:

* place components with mechanical interference considerations
* place regulator and amplifier on big ground islands (thermal
considerations)
* place other major components to minimize total trace length
* route power (+12, +5, +3.3, Vref) and ground
* place ground pour where I felt it was needed, and put a keepout
around the polygon so the autorouter won't play games with me.
* place bypass caps, etc
* hand-route some of the critical stuff (this xtal, for instance),
stuff that's really easy (bus from chip A to chip B, physically
adjacent) and stuff that the autorouter wouldn't be able to guess
properly (bypass caps, for instance)
* autoroute the remainder of the lines

> And then there is other weird stuff like someone dropped a hair on the
> film, causing some PCB's to have a short. (happened just a few weeks ago)

Argh, I don't even want to think about this!!

Richard H. wrote:

> If fuse high byte = 0x99, that means CKOPT is the default - unprogrammed
> (i.e., counter-intuitively, set to 1).  CKOPT=1 has a maximum supported
> clock frequency of 8MHz.

WHACK!
WHACK!
WHACK!

(in advance)

I read this datasheet backwards, forwards, upside-down, and in the
original Norwegian with Swedish subtitles (well, no, not really). I
didn't glean this information from my readings. Unfortunately I can't
test it until I get back home, so I will be on tenterhooks all day.

I will buy a new keyboard on the way home so that if this turns out to
be the problem, I can break the old one with my head.

Thank you for pointing this out!

larwe wrote:

> > If fuse high byte = 0x99, that means CKOPT is the default - unprogrammed
>

> Thank you for pointing this out!

Hmm. Well, I'm tired so I'm going to bed... but this wasn't it. In
fact, programming that fuse has killed the board, I can't talk to it
over JTAG any more :(

larwe wrote:
> assumptions and basically losing hair apace. My circuit is based around
> an ATmega128, running at 16MHz off an ext xtal. The prototype board

Well, hmm. I took a look on a scope at work and I'm seeing oscillation
at exactly the right frequency, with a 554mV p-p amplitude (462mV to
1.016V). That's with the 997F fuse settings.

AVR Studio's fuse dialog is designed to cause confusion regarding the
CKOPT setting.

Larwe... this question is asked fairly often on avrfreaks.net.....
please come read some messages there....

BobG wrote:
> Larwe... this question is asked fairly often on avrfreaks.net.....
> please come read some messages there....

I spent several hours searching through the forums here. I didn't find
anything that seemed even vaguely relevant. Plenty of people asking
about problems with programming, but mostly centered around difficulty
talking to the programmer.

larwe wrote:
> larwe wrote:
> 
>>assumptions and basically losing hair apace. My circuit is based around
>>an ATmega128, running at 16MHz off an ext xtal. The prototype board
> 
> Well, hmm. I took a look on a scope at work and I'm seeing oscillation
> at exactly the right frequency, with a 554mV p-p amplitude (462mV to
> 1.016V). That's with the 997F fuse settings.
> 
> AVR Studio's fuse dialog is designed to cause confusion regarding the
> CKOPT setting.

Hmmm... maybe the UI is wrong?  I'll be a broken record and point out 
that this scope reading means CKOPT is set to a value that does not 
support >8MHz operation.  The CKOPT value that supports 16MHz would 
yield a rail-to-rail swing on the xtal.

(FWIW, on a Mega128L @ 3.3v & 8MHz, IIRC the low-power osc mode was like 
a 1.5v swing.)

Now, no knowing why changing CKOPT didn't fix your other ailments. 
Perhaps it caused some damage?

Richard

Richard H. wrote:

> that this scope reading means CKOPT is set to a value that does not
> support >8MHz operation.  The CKOPT value that supports 16MHz would
> yield a rail-to-rail swing on the xtal.

Oh yes, I realize this.

> Now, no knowing why changing CKOPT didn't fix your other ailments.
> Perhaps it caused some damage?

I think the problem is that when I tried to set CKOPT correctly, it
wiped the other fuses. At the bottom of all this, I think the
underlying problem is that JTAG programming is really unreliable on
these new parts.

I asked the customer to change the setting on CKOPT, and he said the
values read back didn't match what I would expect (89FF FF).

larwe:
I spent several hours searching through the forums here.
=============================================
By 'here' do you mean comp arch embedded?, or do you mean 'there'
(avrfreaks.net)?

BobG wrote:

> I spent several hours searching through the forums here.
> =============================================
> By 'here' do you mean comp arch embedded?, or do you mean 'there'
> (avrfreaks.net)?

avrfreaks.