Argh. ATmega128 users, please help?

On 16 Apr 2006 21:06:40 -0700, larwe <zwsdotcom@gmail.com> wrote:
> ... 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.

Perhaps not yet relevant, since you appear to have... um, "reproducible"
errors in boards on hand, but what is the "cost" (money, time, other
resources) of hand-carrying a board or three directly to your customer's
site and installing and testing them yourself?

The number of unplanned-for, unexpected, and destructive things that a
customer can do to softwre during its installation pales against the list
of ways a customer can... um, "introduce new variables" when installing
hardware. <grin?>  Being present, watching over your customer's shoulder
as they perform their own interpretation of your carefully-worded
instructions, can give you a whole new perspective on the installation
process.

But this is after you're getting reproducible _good_ results in your
own facility, of course.

Good luck.



Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)
--
   "When we are planning for posterity, we ought to remember that
    virtue is not hereditary." -- Thomas Paine / Common Sense
--

On 16 Apr 2006 16:40:00 -0700 in comp.arch.embedded, "larwe"
<zwsdotcom@gmail.com> wrote:

>
>linnix wrote:
>
[...]
>
>> > - 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.
>

FWLIW, I've used several AVRs of the past few years, and almost never
had any difficulty programming them (ISP w/STK-200).  These were 90S
4433 and 8515, and mega 16 and 32.  Never tried a mega128...  IIRC,
most people on the 128s have trouble selecting the correct programming
pins, and with correctly setting the m103c fuse, but if you're getting
it to work at all, you've probably got those right.

If you're using an STK-200 type programmer, you might try changing the
buffer.  That generally solved any programming problems we had.

Programming PICs with a JDM or HC08s with the ROM monitor -- now
_that_ was an adventure...

Regards,
                                        -=Dave

-- 
Change is inevitable, progress is not.

Hi,

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

I thought I'd posted the fuse values I'm using.. anyway, it's 0x997F
0xFF, and that sets CKOPT.

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

Sigh. I wish!

Frnak McKenney wrote:

> Perhaps not yet relevant, since you appear to have... um, "reproducible"
> errors in boards on hand, but what is the "cost" (money, time, other
> resources) of hand-carrying a board or three directly to your customer's
> site and installing and testing them yourself?

Substantial, really very large - a long air trip and at least two days.

There's really not much installation they can screw up. The board that
I got working here was working perfectly after the initial glitch
setting fuses. They unwrapped it, connected nothing but 12V DC (from a
known good PSU), and found that it didn't power up properly. Then they
connected the JTAG cable and read out the fuses... garbage.

> of ways a customer can... um, "introduce new variables" when installing
> hardware. <grin?>

Teehee. I've already collected a few stories like that out of this
project ;)

> But this is after you're getting reproducible _good_ results in your
> own facility, of course.

Right. At the moment I have a 100% failure rate!

Tim Wescott wrote:

> 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

I'll build this when I get home, thanks.

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

I don't have an eval board for the m128 (is there such a thing?). The
bypassing is very similar in layout and identical in terms of component
values, to the previous version of the board.

> Has the silicon rev changed with the date code?  Has the flash

I've asked Atmel if there is anything like this going on, but they
haven't replied - yet. (Ulf?)

The programming problem happens even with the very latest AVR Studio,
though.

larwe wrote:

> Tim Wescott wrote:

- snip -

>>Do you have the same number of bypass caps as the eval board, with
>>similar placement?
> 
> 
> I don't have an eval board for the m128 (is there such a thing?). The
> bypassing is very similar in layout and identical in terms of component
> values, to the previous version of the board.
> 
I saw the "old board, new board" comments and it somehow mutated into 
"eval board" -- I rarely use eval boards, so I wouldn't know about 
specific availability.

-- 

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

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

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

No, The JTAG clock is sampled by the main clock.
This is why you have the limitation: JTAG Clock < Main clock / 4

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



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB

Larwe - a one or two k resistor between the circuit and the probe tip will 
often answer that question.

Hul

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



> 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:
>>>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
>>
>>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
> 
> I thought I'd posted the fuse values I'm using.. anyway, it's 0x997F
> 0xFF, and that sets CKOPT.

Hi,

Well, I'll admit to not looking up the fuse table and mapping your 
values back to the parameters :-)  However...

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.

 From the datasheet p.38...
"When CKOPT is programmed, the Oscillator output will oscillate will a 
full rail-to-rail swing on the output. This mode is suitable when 
operating in a very noisy environment or when the output from XTAL2 
drives a second clock buffer. This mode has a wide frequency range.

"When CKOPT is unprogrammed, the Oscillator has a smaller output swing. 
  This reduces power consumption considerably."

HTH,
Richard

In comp.arch.embedded,
larwe <zwsdotcom@gmail.com> wrote:
> Ryan Weihl 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
>
> 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-
routed your ground to be sure of short connections, or do you rely on
the copper pour? A combination of via's, pads and traces can sometimes
cause very long, unexpected, breaks in a copper pour. If possible, set
your PCB package to show only the ground and then have a good look. 
I have even had a PCB package (a long time ago) that just reported all
pads in the pour connected when in fact there where floating islands.

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)

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)