ATmega128RFA1 crystal and fuse problem

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wired up an ATmega128RFA1 according to the application circuit in the datasheet (page 493). Everything worked fine until I set the SUT_CKSEL fuse to:
Tranceiver Oscillator: Start-up time: 16 CK + ms

. . . then it stopped responding . . .

Lowering the ISP frequency to any speed doesn't help.

CKDIV8 and CKOUT are unchecked, and I haven't programmed the device yet.

I have a 16MHz crystal (mouser #815-ABM10-16-E20-T) with two 10pF caps (mouser says its a 20pF crystal, but the crystal datasheet says use 10pF). If I've read page 494 of the manual correctly, then the 16MHz crystal is the transceiver crystal.

note: The trace length between both ends of the crystal to the ATmega aren't equal on my board. One is 30% (0.09 inches) longer . . . could that break it?

What am I doing wrong?

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You did read the fuses before modifying and writing them?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dak664 wrote:
You did read the fuses before modifying and writing them?

Yeap.

I unprogrammed the CKDIV8 fuse successfully first, and read the fuses again without a problem.

But then when I did the crystal fuse, my world ended :(

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

societyofrobots wrote:

I have a 16MHz crystal (mouser #815-ABM10-16-E20-T) with two 10pF caps (mouser says its a 20pF crystal, but the crystal datasheet says use 10pF). If I've read page 494 of the manual correctly, then the 16MHz crystal is the transceiver crystal.

note: The trace length between both ends of the crystal to the ATmega aren't equal on my board. One is 30% (0.09 inches) longer . . . could that break it?

What am I doing wrong?

Mouser says it is a 10pF crystal, datasheet does not say anything, because part number is incomplete.

For a 10pF crystal, you should use two 20pF capacitors. Or actually a bit less, as also IO pins have approximately 5pF of capacitance per pin.

But, that should not cause it to fail, and neither the trace length. Otherwise, I don't know anything about those RF AVRs.

What if you tried another crystal, they may break too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> . . . then it stopped responding . . .

Responding to what, ISP? Did you note down the hex fuse
values when programming? (Just for reference, they give
a complete and unambiguous description of the actual settings.)

Any chance to use JTAG to read/reprogram them?

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jepael
You might be right . . . I'll replace the xtal when I have time . . . busy busy busy!

I looked at the board under a 50x scope and didn't see any solder shorts across the ATmega pins.

dl8dtl wrote:
> . . . then it stopped responding . . .

Responding to what, ISP?


yeap

dl8dtl wrote:

Did you note down the hex fuse
values when programming? (Just for reference, they give
a complete and unambiguous description of the actual settings.)

nope . . . but I'll pay more attention to it from now on!

dl8dtl wrote:

Any chance to use JTAG to read/reprogram them?

I had disabled/unprogrammed the JTAG fuse before I even made the clock fuse change . . . and I don't own a JTAG device . . . :oops:

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I had disabled/unprogrammed the JTAG fuse before I even made the clock fuse change

Ick. Always a bad idea. If you want to free up the JTAG pins for
other purposes, set the JTD bit in MCUCSR at run-time (you have to set
it twice in sequence in order to take effect). The only fuse to take
care of is the OCDEN fuse, which should be unprogrammed unless you are
debugging. If it remains programmed, the main clock will never stop,
so the device consumes more power than necessary.

JTAG has the advantage of being self-clocked, so you don't have to
have a running oscillator on the controller. An AVR Dragon is not a
huge investment, and would offer you at least a JTAG device "just in
case".

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And the AVR Dragon can also re-write fuses on a bricked ATmega, right?

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> And the AVR Dragon can also re-write fuses on a bricked ATmega, right?

Well, it depends on what you consider "bricked". If you have burned the chip
inside, it won't help. ;-) If you have just disabled the oscillator, *and*
the device is JTAG capable (i.e. has a JTAG interface which has not been "fused
off"), it will help, yes. If you have a device that has the RSTDSBL fuse set,
it can only be reprogrammed through high-voltage programming. The AVR Dragon
could even handle this, but HV programming is usually not an option for devices
soldered into a target system. (Actually, serial HV programming might have a
chance even for that, but for parallel HV programming, it's very unlikely that
all the IO lines in the target circuitry are in a state where you could
successfully hook them up onto an HV programmer.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

re-write fuses on a bricked ATmega

[NB: Discussion following does not apply [perhaps] to Toyotas.]

My vehicles, whether automobile or truck or tractor, have a shift lever to select a gear. The transmissions may be automatic or manual. The selection may be forward or reverse, plus some "specials" (start, park, neutral).

Yes, it is not difficult for me to "brick" my automobile parked head-first in my garage. I simply select a forward gear instead of a reverse gear, release the brake and press the accelerator. How often doe this happen? Never any such "bricking", AFAICR. Have I selected the incorrect gear on occasion? Certainly. But proceeding with due caution the symptom is quickly detected at the start of movement; the movement is aborted; and the situation corrected.

So why would people essentially throw random "gear selections" at an AVR without due diligence? And apparently do it on a repeated basis as there have often been reports of virtual walls of these bricks?

In daily AVR project development over the last ten years, hundreds of production apps and many thousands of ISP cycles, I need very few fingers to count bricks. If it were that easy, why don't we hear about it from our board houses and big customers that ISP well into 5 figures of units each year, done by shop personnel? It just doesn't happen. The ISP sequence includes a flash image and EEPROM image and a "project" with fuse settings. They are always applied in the same full sequence, repeatedly and reliably.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If there was a moral in that story, you lost me :P

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been puzzled about the same thing, and have written similar responses, though not quite as eloquent as the one above. I also have automobile, truck, tractor, and other powered thingies. Never bricked one under startup conditions.

Ditto, AVRs. Well, maybe one... or two, but in hundreds, if not thousands, of download events (and all lab bench environment). It was understandable when there was greater confusion about what "programmed" means in the data sheet. But, with the fuse calculators that are part of almost every programming interface, it seems so easy to do it right!

NB - This little musing is NOT aimed at "societyofrobots" but the seemingly endless stream of "help, I can't program my AVR" or "help, bad signature", or, more often just "HELP ME!' (sorry, that's another, somewhat independent complaint).

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
So why would people essentially throw random "gear selections" at an AVR without due diligence? And apparently do it on a repeated basis as there have often been reports of virtual walls of these bricks?
Spoiled kids thinking this is consumer electronics? Thinking they are an "engineer" because they successfully managed to insert the latest computer game into their Xbox? Thinking reading, especially a datasheet, is for old farts?

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you guys are getting a bit off topic . . .

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If there was a moral in that story, you lost me

If you can't see any moral, then I'm not nearly as eloquent as Jim opined. [But I never claimed to be.]

The moral is that there isn't any reason to have bricks -- plural -- in nearly any case.

[We had a through-hole assembly shop make a batch of controllers; several hundred. A diode was inserted backwards on every board. When power was applied in the test rig, each board promptly fried and it failed the test. they ran EVERY BOARD of the batch through the test rig and dutifully marked EACH ONE as failing the test, with they same symptom/result. They did indeed end up with a pile of bricks--plural. A lot of thought certainly went into that operation. I'd speculate that in a "normal" run, maybe 1 of 100 or probably less had a testing exception. Doncha think after the first few...?]

Yes, I always like to have at least two prototypes with the spare(s) being a sanity check when things don't make sense. And I run the risk of then blowing all of my "batch" due to the same problem. If you have a single bricked Tiny that costs a dollar or so then it is probably most effective to just toss it and move on. A $10+ as is mentioned here--a bit more effort is expended.

Given the "RF" in the chip name, I'd guess a crystal is essential. So you indeed have to work in this area until you get your clocking right. While one can do nasty fuse stuff like disabling both SPIEN and JTAGEN but that is hard to do. So about the only other bricking (no RSTDISBL on this model) is selecting an inappropriate clock source. I can't think of a situation/combination not recoverable by either the 1MHz injection, or ISPing reeeeaaalll sllllow.

You >>do<< do a Read Signature at the start of each ISP session, don't you? That's like letting the clutch out real slow on the manure shuttle loader in case the wrong direction was selected with the shift lever.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Given the "RF" in the chip name, I'd guess a crystal is essential.

Quote:

I have a 16MHz crystal (mouser #815-ABM10-16-E20-T) with two 10pF caps (mouser says its a 20pF crystal, but the crystal datasheet says use 10pF). If I've read page 494 of the manual correctly, then the 16MHz crystal is the transceiver crystal.

Hmmmm--when I was looking at fuse bits for this model, it has a
Quote:
11.7 Transceiver Crystal Oscillator
The integrated crystal oscillator for the radio transceiver generates a low-jitter 16MHz clock frequency.

I'd think most would use the integrated crystal at the same speed rather than fitting another? But the pertinent point is that there are more clock options now than internal/external/crystal; we have the CKSEL and SUT combinations for the integrated. Perhaps jump-starting doesn't cure all combinations?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Without looking at the specs, I would bet that the transceiver oscillator is separate from the CPU clock. CPU clocks are notorious for having "jitter" that is really bad for RF performance (it is like frequency modulating a signal that should not be frequency modulated).

I also predict that this will cause a lot of questions since it sounds like the crystal is integrated. Instead, it is ONLY the "oscillator" (that is, the active circuit) with the crystal being external, just like the existing CPU crystal oscillators.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> The integrated crystal oscillator

Yes, the *oscillator* is integrated, but the crystal isn't. ;-)

The 16 MHz crystal is indeed required for RF operation. If only
used for RF operation, it can be turned off easily while the RF
frontend does not need it. The AVR CPU can be clocked by either
that crystal oscillator, or by one of the RC oscillators (16 MHz
one or 128 kHz one), based on some fuse setting. I normally wouldn't
recommend using the crystal oscillator as an AVR clock for power
consumption reasons though: even if/when the AVR core falls asleep,
a crystal oscillator needs much more time to startup than a RC
oscillator, which is just "dead time" wasting energy.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still no luck.

I changed out the crystal, didn't work. I changed the 10pF load caps to 12pF, didn't work.

So I soldered up an entirely new circuit and changed all the fuses I wanted except the crystal fuse. Everything worked fine, programmed fine, etc. Except it was 1/16th too slow - makes sense as it was using the internal oscillator. But then when I change the clock fuse to use the external crystal, as I did before, it bricked up again . . .

Anyone used this chip and got it to work?

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have a scope, check the crystal to see if it is doing anything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mquantz wrote:
If you have a scope, check the crystal to see if it is doing anything.

ummmmm is that possible? I'd assume the capacitance of the scope would mess things up?

Anyway, I won't have access to an oscope until Tuesday, so I measured it with my UT60A-CN multimeter. It didn't detect anything for either the 16MHz crystal nor the 32KHz crystal.

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good call on the capacitance. My probes add 23 pF which would still probably be enough to stop the oscillations.

You probably wouldn't see anything on the 32.768kHz unless you configure it through timer 2. I think those pins are GPIO until set for the crystal in the timer 2 registers.

Furthermore, since you are not using the 16MHz crystal for the system clock in this case, you will have similar results until the transceiver wakes up from sleep and transitions to the trx_off state.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@mquantz Good point. I remember reading that from the datasheet, now that you mention it.

I included an image of the PCB layout for the crystal. See anything wrong? The grid scale is set to 0.005 inches per square.

(Those who are clever will notice that the corner notch is in the wrong location for the crystal, so I rotated my crystal by 90 degrees before soldering to match up the grounds.)

Attachment(s): 

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't see any problems with it, but I suggest re-posting with the tNames layer disabled.

It's the seasoned guys who often provide the most help, and anything you can do to help them will help you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I might be on to something. Check table 34.8.6 on page 510.

Crystal frequency 16 MHz - typical
Load capacitance 8pF min 14 pF max
Static capacitance 7 pF max
Series resistance 100 ohm max

Your crystal's series resistance was listed to be 150 ohms max. I have no idea what it would operate at normally. Can that be measured with a multimeter?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mquantz wrote:

Series resistance 100 ohm max

Your crystal's series resistance was listed to be 150 ohms max. I have no idea what it would operate at normally. Can that be measured with a multimeter?


I tried measuring it . . . between both grounds it was less than 0.1 ohms, and any other pin combination resulted in maxed out resistance. I don't think thats what we're looking for . . .

Anyone else think it could be this?

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The capacitance and the equivalent series resistance are the only sources for error I can see (besides, of course, an ID10T error like a bad solder joint).

Your frequency tolerance is different from my crystal, but both are within the range for the maximum possible data rate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I figured it out.

Whoever made the datasheet for the crystal deserves his [profanity here] ripped off lol

The datasheet pinout for the crystal is wrong. The notch is actually on pin 3, an active pin. But the datasheet says the notch is on ground.

How'd I figure that out? The pinout seemed funny since the beginning, since 'TOP VIEW' in the datasheet was actually a bottom view of the part. So I said what the heck, why not try it . . .

sigh!

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad to hear you solved the issue. Do the PCBs need to be adjusted, or can you just rotate the crystal?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On my prototype, I don't need to change a thing! I just rotated the crystal 90 degrees back to the way it should have been.

But . . . I made the adjustment in my second PCB prototype design, so I just spent the last 30 minutes reverting it back to the way I had it originally.

blaaaahhhhh

Now on to test the rest of the prototype . . .

How do YOU make a robot?
http://www.societyofrobots.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Furthermore, since you are not using the 16MHz crystal
> for the system clock in this case, you will have similar
> results until the transceiver wakes up from sleep and
> transitions to the trx_off state.

Note that, at power-up, the transceiver automatically enters
TRX_OFF state, so the 16 MHz crystal is supposed to start up.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.