Crystal Oscillator on Uno R4?

[dewhisna]

How are you guys getting away with using what appears to be a standard AT-cut crystal with the ATmega328PB on the Uno R4 board? Did you build those prior to the Microchip's change to get rid of the full-swing oscillator support? (https://hackaday.com/2016/05/03/atmel-removes-full-swing-crystal-oscillator/)

I've had trouble getting the new ATmega328PB to drive an AT-cut crystal -- the oscillator won't quite start, even after changing the loading caps to help it. In fact, there's a bug in the ATmega328PB itself that if the oscillator won't quite start and you switch the fuses to the external oscillator mode and then try to program the flash over ISP via the SPI pins to put a bootloader in the chip or something, it gets into a mode where it seems to switch back and forth between the internal oscillator and the external one that's still trying to start and it will mistime the flash write cycles and destroy the cells in the flash memory. I gave up on trying to use an AT-cut crystal after destroying several ATmega328PB chips that way.

You can use a ceramic resonator or a stand-alone oscillator module OK with it, though those are considerably more expensive than an AT-cut crystal. But the AT-cut crystal itself takes too much power to get them started oscillating and the ATmega328 processors will no longer drive them. The only way I know to use them is to have an external driver circuit with an inverter of your own that is full-swing and feed it in like a stand-alone oscillator input to the ATmega328PB, but that sort of defeats the point in part minimization.

I didn't see such an external driver circuit on your board and it at least looks like an AT-cut crystal on there, so I was wondering how you managed to make it drive it or if you were just using some of the early release ATmega328PB parts that still supported full-swing oscillator -- or using their special order version that they can provide that still has the full-swing oscillator (a nonstandard version of the chip that's special order at a premium cost)??

[elektor-labs]

The Atmel change note the Hackaday article refers to does not mention the ATmega328PB. It has never had a full swing crystal oscillator as is confirmed by the 10/2015 datasheet used for the design of the Uno R4. We never encountered any of the problems you mention, maybe we are just lucky?

[dewhisna]

My understanding, in talking with the support dept at Microchip, unless I misunderstood them, is that the early preproduction prototypes had full-swing and that an alternate version can still be ordered (just like the non-PB) that is full-swing, but yes, you are correct that the standard production ones were supposed to not have full-swing on any.

I'm still confused why you haven't seen any issues. I was also trying it with a 16MHz crystal and an all SMD circuit with the crystal located as physically close as possible to the chip and minimal trace length, etc. -- even using a SMD HC49/US package crystal, which is what yours appears to be. And I've seen other reports floating around the web where others have tried with similar issues and indicated that they could get it to work at up to 12MHz, but not higher. At yes, that's at 5V, as I know the lower voltages aren't rated/qualified for the higher speeds.

Microchip didn't seem too surprised when I reported the problems that can cause the flash memory programming timing issues, and declined my offer to send them a failed chip for analysis. Their response, instead, was to send some free samples to replace the ones that got fried.

I'm curious, are you using -AN suffix parts or -AU. I think the only difference is supposed to be temperature rating, but I'm suspicious. I am using -AU parts, by the way.

[elektor-labs]

We use -AU parts. I have also used the -MUR version when the -AU was difficult to get.

[dewhisna]

On different PCB layouts, right? Or did you find some clever way of offsetting the VQFN 0.5mm pitch part inside the TQFP 0.8mm pitch part footprint?

Do you have your schematic posted online? I haven't found it yet. What capacitance crystal and what size terminating capacitors did you use? And did you add any parallel resistor to the crystal to give it a path other than through the crystal? I've moved on to use ceramic resonators and such now, but I'm still curious as to how you managed to get a standard AT-cut crystal working correctly.

I'm assuming, of course, that you changed the fuse bits for on your parts to match your boards.txt. It appears to be correct in your boards file in source/avrpb/boards.txt. Well, except that the extended fuse should technically be 0xF5 instead of 0x05. The top four bits aren't used and there's a new CFD (clock failure detect) bit at bit position 3, which by default is disabled by programming to '0', that they added between the 2015 datasheet and 2017 datasheet. And if you haven't yet, you'll need to tweak the avrdude.conf file to make it not complain about the efuse settings. It should have something like the following on the m328pb entry:

    memory "efuse"
        size = 1;
        min_write_delay = 4500;
        max_write_delay = 4500;
        read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
               "x x x x x x x x o o o o o o o o";

        write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0",
                "x x x x x x x x x x x x i i i i";
    ;

You know... It makes me wonder if there is possibly an undocumented efuse bit or something that enables full-swing mode. I was setting efuse to 0xF5, to match the datasheet for the "unused" bits and never could get an AT-cut external crystal to work. And if you are setting yours to 0x05 to match your boards.txt file and it did work on yours, maybe it would be worth trying to see if it changes anything. I don't have any spare boards assembled at the moment to try -- if you do, can you try 0xF5 on efuse and see if it makes a difference?

[elektor-labs]

Yes, on a different footprint.

You can find the Elektor Uno R4 project here: https://www.elektormagazine.com/labs/elektorino-uno-r4-150790. This repository is for the firmware.

[dewhisna]

Looks like you're using 22pF caps. I was originally using 24pF. My crystal was rated for a 22pF load, but if you go through the calculations at places like http://ww1.microchip.com/downloads/en/AppNotes/00826a.pdf and https://blog.adafruit.com/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/, you come up with 24pF capacitors for it.

When that didn't work (the crystal wouldn't even start running at all), I did some more digging and found that those pins on the ATmega328PB were supposed to have an internal capacitance around 6pF of their own. So figuring them in parallel with mine meant I needed to drop to about 18pF instead. But, with that particular board layout, it was a pain to change them (due to their very close proximity to other parts), so wanting to only do one round of changes I wanted to give them a "fighting chance" of starting by reducing the load as much as possible, so I dropped them down to 12pF each.

That's when they got in the mode of almost starting, but not quite, and the chip acted like it was bouncing back and forth between the internal oscillator and the external. The result is that when I tried to program the bootloader in, it nuked the flash memory to where about a dozen bits in the bootloader area wouldn't take programming anymore. And that's when I gave up on getting a standard crystal to work.

Maybe 18pF would have worked like the 22pF in yours? But can it seriously be that critical to just get the oscillator started? Affecting the target frequency, yes, that's how you tune them, but just starting it? I've never had such problems with crystal circuits before -- but the others were all full-swing designs. What was your crystal's load capacitance rating? And what calculations did you use to arrive at 22pF?

I'm still curious if there's perhaps an undocumented bit setting in those "unused" bits of efuse that's allowing yours to work, as that's the only basic difference I can see between your setup and mine. I was using 0xF5 for efuse (extended fuse) and according to your boards.txt, you used 0x05. If you have a spare board to try setting it to 0xF5, please try it and see if it still works...

[elektor-labs]

I think you overthink things. I just put 22pF caps in because that is what the datasheet said was ok, and what I always use and what always works. No calculations whatsoever. Well, I have to admit that my favorite Arduino crystal (Multicomp MCRSD16000F183000RR from Farnell) has a load capacitance of 18pF ;-).

The famous efuse 0xF5 vs 0x05 is an avrdude thing and both values result in the same thing.

[dewhisna]

Which datasheet said 22pF? I assume you are referring to the crystal datasheet. But the value that a crystal datasheet lists is NOT the value you should use for the capacitor itself. It's the capacitance loading in your circuit as a whole, from which you can calculate the individual capacitor values from using the equations in the aforementioned links.

Now, as it turns out, when you take parasitic/stray capacitance into account, due to the range of the capacitance values involved, by coincidence, the value of the individual capacitors just happens to be really close to the loading value of crystal itself. But that's only coincidence. It really should be calculated.

I don't think I'm overthinking it. What I know is that I'm here looking at a circuit that really isn't any different than yours, but yet refuses to run with an external AT-cut crystal, and I'm trying to figure out why. I've never had such problems with crystal circuits in the last 36-years or so that I've been designing them. They've always just worked.

Due to this problem, this board and design with the standard crystal has now been relegated to only use the internal 8MHz oscillator, but I'd like to discover why so my future designs won't have issues.

On the efuse 0xF5 vs 0x05 -- it's not entirely the avrdude conf thing, as the ATmega328PB at least adds one more bit in efuse over the ATmega328P, at least it's in the newer 2017 datasheet and apparently a change between 2015 and 2017 as the 2015 datasheet for the ATmega328PB didn't list it. Presumably no other bits are different, but I'm digging in the dirt for differences trying to figure this crystal problem out.

[elektor-labs]

I must be a bit more clear. We always try to use our standard values for passives, and 22pF is in our list. It also happens to be in the acceptable range for the ATmega328PB, according to its datasheet. The crystal datasheet specifies 18pF for CL. So with 22pF caps and a bit of stray capacitance we should be pretty good. And since it worked first time and ever since, we didn't look any further.

P.S. Would you like to write an article about the subject for Elektor magazine?

[dewhisna]

Putting the datasheets of our two crystals side-by-side there are so few differences.
Yours is a Multicomp: http://www.farnell.com/datasheets/1801275.pdf
Mine is a Abracon: http://www.abracon.com/Resonators/abls.pdf

Same drive level, same equivalent series resistance (ESR), same load capacitance, etc. ... which only leaves me more confused.

Maybe I need to just design a quick "promini" style board with the same style crystal and try it again. Is it possible I just had a bad crystal on that board? Hmmm...

As for writing an article, maybe if I actually knew what was wrong with mine, but as it is, I couldn't even write a decent blog.

[dewhisna]

Thought I'd mention that Microchip just released an updated datasheet for the ATmega328PB. Looks like one of the things they tweaked was the capacitances on the crystal oscillator pins. I haven't yet crunched the numbers to see how things compare with my failed AT crystal attempts, especially since I've moved on to just using ceramic resonators (they seem to work just fine for both 16MHz and 20MHz), but thought others reading this tread would find the new datasheet helpful. Here's the link for the ECN with the new datasheet:
https://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=SYST-05SZJQ168

[dewhisna]

And once again, Microchip has updated the datasheet for the ATmega328PB. I haven't dug into it in extreme detail, but the release notes say they changed the packaging drawings and updated the errata. Not sure that it has any new detail related to this discussion, but regardless, I thought it would be helpful for those following this thread. Here's the ECN link:
https://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=SYST-22VBDZ673