Argh. ATmega128 users, please help?

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.

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 > - Code that works 100% fine on the old board misbehaves on the new

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

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.

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

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.

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

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

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

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.

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.

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

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

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.

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

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" wrote in news: snipped-for-privacy@i40g2000cwc.googlegroups.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

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

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/

Usually I can easily probe XTAL and even clock other devices from it if I set COPT fuse. Alex.

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.

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