1. Home
  2. Embedded Programming
  3. Argh. ATmega128 users, please help?
  4. Page 2

Argh. ATmega128 users, please help?

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

--

Reply to
Frnak McKenney
Loading thread data ...

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)
Reply to
Stef

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

Reply to
larwe

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.

Reply to
larwe

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

Reply to
BobG

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.

Reply to
larwe

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

Reply to
Richard H.

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

Reply to
larwe

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

Reply to
BobG

avrfreaks.

Reply to
larwe

I put an 8MHz xtal on another board, and that brought the swing up to about 824mV. With a colorburst xtal, that went up to about 900mV. I figured this was probably safe to attempt another write operation.

Per a couple of application notes I read from programmer vendors, I put a 100pF cap between TCK and ground.

Next I tried writing 0x89 to the high fuse byte, and whomp! the swing when I put back the 16MHz xtal is from 760mV to 4.32V (3.56V) which is great. I was hoping that this would fix all my programming woes, but it doesn't.

I tried writing hfuse, lfuse, efuse individually, in that order. Side effects!!

Write hfuse = 0x89 -> changes efuse from 0xff to 0xfc Write lfuse = 0xff -> changes hfuse from 0x89 to 0x20 Write efuse = 0xff -> apparently no side effect.

Incidentally, I discovered that the undocumented bits in the extended fuse byte seem to have a meaning related to clocking! Specifically,

0xFC results in the chip running _incredibly_ slow; while (1) { LED = ^LED; } on 16MHz clock results in blinking at about 4Hz!
Reply to
larwe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.