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

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:

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:


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

Sigh. I wish!

Frnak McKenney wrote:

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.

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

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

Tim Wescott wrote:

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

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

- snip -

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

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



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

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

Stef wrote:

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.

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

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

Richard H. wrote:

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:

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

Oh yes, I realize this.

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:

avrfreaks.