Crystal problems with 1284p

I am developing a system with 1284p and Jack's forked mighty-1284p project. I encountered some strange problems, some of which I first posted here:

http://forum.arduino.cc/index.php?topic=281670

Remaining issue is with crystals. I have two crystals, one is the small one that you can get anywhere such as here:

http://www.dipmicro.com/store/XC7-16000

They call it HC49US, which is what I recognize from all past purchases.

They do work. I have set up a 328p-pu bare minimal system with this crystal and I can upload code to it and watch led blink.

When I use this crystal on either 1284p-pu or p-mau, they seem to work only if I already loaded the blink code. I watched the digital pin on my scope and the 328p and 1284p seem to blink at the same rate.

But when I try to upload code with this crystal (I have a bag and tried 3 already), the IDE would fail and sometimes corrupts the bootloader. Then I remember the interference between crystal and serial pin someone mentioned with the DIP version of 1284P. I tested with and without serial port communication. The P-MAU just stopped working a while ago so I only tested on DIP (P-PU). As expected, if I even start serial port in the program, the code with blink_without_delay will only work for a few seconds. If I send something through serial port, that will immediately stop the program from running. If I used the larger crystal then it's fine. I can send anything to serial port and get it back with echo code serial.write(serial.read()).

I used a scope to look at the crystal oscillator output. For the larger crystal, it swings not rail to rail (maybe after amp it will be, inside the mcu) but is clean. I looked at the "output" pin or xtal2 pin:

The small crystal craps out when I connected my scope to it. The mcu would not start. I tried 328p and the same. I couldn't get a waveform.

Is it possible that the batch of crystals I got is simply bad? I got it from dipmicro like I have always done. I've run out of my previous batch of 200 so I can't do a comparison. I also tried a duemilanove and I couldn't get its crystal output. Maybe these small crystals are low power ones that only oscillate so weakly that the serial interference just corrupts their oscillation. Maybe the larger crystal I have is full swing crystal, any way to tell? It says NYMPH 33-03 90-11. There is nothing I could find online. The frequency is 16.000MHz though (see screen capture).

So my first question boils down to: for those that are using 1284p, where do you get your crystals and how do you make sure it's full swing? I got this crystal from a colleague. Luckily I ran out of the small crystals so I asked him for one and he gave me this giant one. I'll upload pictures when my phone charges up and stops refusing taking pictures.

Another question: the fuse setting fro the 1284p is for low-power crystals, if you read the boards.txt. I have not tried to mess with that yet. For those, especially CR who sells 1284p boards, what fuse settings do you use? I have LF=FF, HF=DE, EF=FD, just as the boards.txt says. Do you guys use some other values?

I just can't figure out why this 1284p exercise turned so badly. I thought it would be my solution to pin/SRAM/FLASH shortage and now it has cost me so much time and gives me doubt whether it's worth it. For those of you that say it's "SO EASY", share some experiences with fuses, crystals, etc. Please!

I use LF = F7, seems to work better. I had a board recently that I couldn't get running with LF = FF, changing to F7 resolved it.
Full Swing Crystal Oscillator
See 9.2 of the '1284P datasheet.

I get the thruhole crystals all over the place - dipmicro, taydaelectronics, digikey, mouser.
Not sure why this particular board had an issue, or where the crystal came from.

CR,

Thank you!

So F&= crystal oscillator full swing slow start up time, and you are using the small cap crystals like in the picture (dipmicro only has this smaller cap one)?

Here is the picture for my crystals:

I'll read more on the data sheet section you pointed out.

So for starters, "full swing ocrystal oscillator", does it mean the quartz enclosed in the metal cap or the quartz plus some circuitry inside the MCU.

If I select full-swing, do I need different crystals (like the big one in picture)?

CR,

LF=F7 seems to do it with the small crystal. I was able to upload sketch to the P-PU. I could also use the serial port without having the mcu reset. I'll try this with the P-MAU (it is currently not accepting any sketches).

So with the smaller crystal, I still couldn't see any oscillation on my scope. Maybe the two crystals are just different, with one able to oscillate at a larger amplitude than the other. I'll have to do some physics here (or just physically destroy the caps to peak inside).

I read chapter 9 on clock sources but I failed to deduce whether low-power oscillator is a device inside the MCU or the crystal external to it. Maybe by selecting full-swing, the inverting amplifier connected to the xtal1 has a larger gain to guarantee rail-to-rail swing. Then by selecting low-power, the inverting amplifier has a smaller gain. What do you think, CR?

0xF7 for the crystal on the right. I think they take up less real estate than SMD parts.
I use those, and more recently a smaller SMD variant,

on some of my boards.
I ordered it by accident, thought I was getting this

Luckily, it was wide enough to fit the same pads:

As to the crystal questions- both Low Power and Full Swing refer to external crystals.
Not enough in the datasheet to infer anything about gains.
Read AVR 042 and see if that helps with understanding operation.

atmel-AVR042-avr-hardware-design-considerations_application-note 7-2013.pdf (758 KB)

Thanks CR. The app note has some diagram indicating what's inside the MCU but doesn't mention difference between low-power and full-swing.

What capacitance values do you use on your crystals? I've been using 22pF.

I did more tests and more confusing results:

With the 1284P DIP version, I was unable to run it using one of the 3 identical smaller crystals, although they are all supposed to be the same. The blink just wouldn't start. All 3 crystals work fine on the 328p dip chip that is also running blink. All caps are 22pF. I also tried 47pF with the 1284P DIP version. Same thing. The same crystal that didn't start the chip still fails to start. The SMD chip is even worse. I can load it with blink using ICSP header and it blinks, except that it is very touchy. With the larger crystal it sometimes blinks but when I touch the crystal etc, it fails to continue. I have the SMD chip on an adapter from adafruit, which has another layout (for the MU version) on the bottom of the PCB with long traces from the xtal pins to pads on a smaller footprint. Maybe that bottom trace has too much stray capacitance or something to make it not work. But larger capacitance shouldn't kill the oscillation since the DIP version using 47pF caps still works with the smaller and larger crystal (now waveform on xtal2 goes to 3V and the nice sine wave is more distorted).

So maybe I should just go ahead and make some small PCB so I can solder everything together instead of using breadboards?! That blinking 328P is laughing at me now. I've never had any issues with crystals using 328P.

For least troubles, you definitely need to use the full-swing oscillator selection when "burning" the bootloader. I assume Jack has this fixed in his distribution, but don't know for sure. Otherwise, you risk having the infamous "RX0 Problem", which was talked about in one of the interminably long 1284 threads [47-pages, what?]. You will not find this problem discussed anywhere else, eg in the Atmel or Arduino notes, to my knowledge.

i was able to reproduce the flaky crystal phenomenon but only with early batches of 1284. full swing works and they probably made production changes to minimize it. but im convinced it was due more to poor circuit design and layout than atmel product deficiency. i had similar problems a long time ago with 16mhz version of 90s1200 and solved it with pcb guard rings, routing, and proper vcc bypass placement. i suspect several others experienced similar issues and that may be why atmel discontinued that part or just relabeled as 12mhz.

its also possible some rare batches of no-name crystals suffer from low activity but very rare these days. i still test for this this on large lots and its been many years since last instance. never on modern low profile parts.

So John,

Do you think that if I transfer my circuit to a printed board I will get some better result? The surface mount version is not working at all. For full swing oscillator, does the crystal have to be some specific type? I bet the cheap crystals are more likely to fail to oscillate. Weird that the failed crystal on 1284 works on 328. Maybe 328 is a more robust design?

BTW, early batches means which year week? I will check mine.

Dan,

I tried your suggestion. Same result. The surface mount is not accepting any sketch and icsp programmed blink usually fails to run. I wonder why it can be icsp programmed at all. Icsp doesnt work unless you have a crystal there, any one of them I used.

I will order some crystals from mouser and try again with breadboard or perf board before making pcb.

Something else I remembered. Right after I reprogrammed the low fuse from FF to F7 to use full swing Oscillator, using the smaller crystal would not work, not even after power cycle. I had to plug in the large crystal to start oscillation and then swap it out and put the smaller crystal in. I dont know why.

i was able to reproduce the flaky crystal phenomenon but only with early batches of 1284. full swing works and they probably made production changes to minimize it. but im convinced it was due more to poor circuit design and layout than atmel product deficiency.

I do believe both of these issues [early batches, poor ckt design] were investigated, and ultimately "rejected", as the cause of the RX0 problem, in that 47-page thread mentioned. After a dozen or so people tried everything a dozen or so people could think of, pito hit on the idea it was because the RX0 pin is adjacent to the OSCin pin, and there was cross-talk. To my knowledge, using full-swing oscillator fixed everyone's system who had the problem. We also checked fixes proposed by the gurus on the avrfreaks forum, but they were clueless as to the cause of the problem.

Do you recall in that thread anyone using breadboard, or smd to 0.1" pitch adapter boards or do they mostly have pcbs? Thanks.

I just use the Full Swing option now as I hate intermittent problems.
bobuinofullSwing.bootloader.low_fuses=0xf7

##############################################################

bobuinofullSwing.name=BobuinoFullSwing
bobuinofullSwing.upload.protocol=arduino
bobuinofullSwing.upload.maximum_size=130048
bobuinofullSwing.upload.speed=115200
bobuinofullSwing.bootloader.low_fuses=0xf7
bobuinofullSwing.bootloader.high_fuses=0xde
bobuinofullSwing.bootloader.extended_fuses=0xfd
bobuinofullSwing.bootloader.path=optiboot
bobuinofullSwing.bootloader.file=optiboot_atmega1284p.hex
bobuinofullSwing.bootloader.unlock_bits=0x3F
bobuinofullSwing.bootloader.lock_bits=0x0F
bobuinofullSwing.build.mcu=atmega1284p
bobuinofullSwing.build.f_cpu=16000000L
bobuinofullSwing.build.core=mighty
bobuinofullSwing.build.variant=bobuino

As I recall, different people were using every which manner of thing. However, in general, I'd never want to use a whiteboard myself, for anything, just asking for trouble.

oric_dan:
As I recall, different people were using every which manner of thing. However, in general, I'd never want to use a whiteboard myself, for anything, just asking for trouble.

I'll just make a small printed board for testing purpose to see if I can get the P-AU to work with a cheap crystal. Meanwhile, I'll get crystals from mouser I know that breadboards create problems with connections being flaky. I switched breadboards to hopefully rule out bad breadboards. Anyway, guessing I've not played with MCUs long enough to see problems until now.

LarryD,

That's what I'm using now after CR told me he's using F7 for low fuse. Thanks.

Thanks everyone especially CR for helping me out! Happy holidays! I might be able to report back in mid-Jan when I get some small PCB printed and tested.

liudr:
Remaining issue is with crystals. I have two crystals, one is the small one that you can get anywhere such as here:

16MHz Crystal HC49US - dipmicro electronics

I've used those crystals from Dip Micro and never had a problem, but I've not used them with a 1284P.

The small crystal craps out when I connected my scope to it. The mcu would not start. I tried 328p and the same. I couldn't get a waveform.

The scope's input impedance needs to be extremely high. Most scopes will load the oscillator too heavily and stop it or affect it otherwise.

liudr:
What capacitance values do you use on your crystals? I've been using 22pF.

Use the formula and calculate the proper value from the crystal's spec. Hint: Proper loading capacitor value for an 18pF crystal (assuming 5pF stray capacitance) is 27pf, not 22pF. Perhaps a small point, and 22pF will almost certainly work, but why not get it right. My experience with 27pF is that I usually end up within a few ppm of the crystal's specified frequency, so that is proof enough for me.

oric_dan:
For least troubles, you definitely need to use the full-swing oscillator selection when "burning" the bootloader. I assume Jack has this fixed in his distribution, but don't know for sure. Otherwise, you risk having the infamous "RX0 Problem", which was talked about in one of the interminably long 1284 threads [47-pages, what?].

Everything in the boards.txt file uses the low-power XO, but there is no harm in trying the full-swing XO.

I didn't go back and wade through the forum threads but my recollection is that I was not convinced that such a problem exists. However, I've only used the 1284P in the TQFP package. I've used two different crystals with it, and tried pretty hard to reproduce the problem and never saw a hint of it.

Still, I do have an open mind that it could exist with the DIP package; however, I will need to be convinced. This would require a reproducible situation using all top-shelf components. Even though I've had no issues with DIP Micro's crystals, they are certainly not beyond suspicion. I always have some top-shelf crystals on hand just for this reason. Between the time that I bought mine and you got yours, things could have changed. The ESR could be too high. AVRs are definitely sensitive to that. Same for the xtal in the larger package. Nice pic but a datasheet is always better.

You will not find this problem discussed anywhere else, eg in the Atmel or Arduino notes, to my knowledge.

There could be a reason for that.

liudr:
I'll just make a small printed board for testing purpose to see if I can get the P-AU to work with a cheap crystal.

FYI, this board works perfectly with the low-power XO and with either this Abracon crystal or with this Epson crystal.

In trying to reproduce the serial interference issue, my testing including running the board at 3.3V and using bootloaders with various baud rates up to 1M. No problems were found.

Note the Abracon crystal specifies 18pF load capacitance, so I use 27pF loading capacitors. The Epson crystal is 16pF, so 22pF is the correct value for its loading capacitors.

Well Jack, I don't want to go back and reread 47 pages of discussion, but seem to recall there were a number of non-noobees who had the RX0 problem. Bob and I, myself, never saw it on our own boards. It first showed up on the avrfreaks forum, but they never tracked down the 'apparent' reason. I have no desire to reprise 47 pages of argument, over again, so ... be happy if you don't see it ... yourself.

EDIT:
I always use low-profile xtals bought from mouser, digikey, or jameco, plus 22 pF caps, and my boards always work. I don't measure how many PPM accuracy, whatever, it's still light years better than the silly ceramic resonators they use on the stock arudnio boards. I also run my boards at both Vcc = 5V and also 3.3V, and they run fine at 16 Mhz, despite some people having a tizzy about mixing 3.3V and 16 MHz.

oric_dan:
Well Jack, I don't want to go back and reread 47 pages of discussion, but seem to recall there were a number of non-noobees who had the RX0 problem. Bob and I, myself, never saw it on our own boards. It first showed up on the avrfreaks forum, but they never tracked down the 'apparent' reason. I have no desire to reprise 47 pages of argument, over again, so ... be happy if you don't see it.

Merry Christmas, Dan! Neither do I care to dredge through all that either (but certainly the bulk of the 47 pages was about other things, this issue was a small sidebar). I hear what you're saying, but for exactly the reasons you listed (you and Bob didn't see it, AVR freaks came to no conclusion) there is ample reason to be skeptical. Unless someone comes up with something that at least one other person can reproduce, everything else is anecdotal, noobs or not.