32K crystal running slow...

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

Hi - I have an ATMEGA168PV-10AUR with an Abracon ABS25-32.768KHZ-6-1-T crystal attached. The crystal runs a bit slow - about 150 seconds/month slow without any capacitors on either line. It initially was about 250 seconds/month with a 10pf cap on each line. I tried swapping crystals and that did not change anything.

Reading the ATMEGA168 datasheet more carefully, I see this section:
"The Low-frequency Crystal Oscillator provides an internal load capacitance of typical 6 pF at each TOSC pin."

So that means it presents a load capacitance of 3pf (6pf || 6pf = 3pf) to the crystal. The crystal I'm using has a CL of 6pf, so it is still missing 3pf (ie 6pf - (6pf||6pf) = 3pf). So I should have used something like 4-5pf for my load capacitors ((5pf + stray) || (5pf + stray) = 3pf, if stray is 1pf). And yet without any load capacitance at all, I'm still slow. And we all know adding more capacitance will just slow it down further.

My traces (6 mil wide) are about 20mm long each. 62mil PCB (2 layers), so they should have less than a pf on each of them. They do spend about 10mm right next to my ground plane (same layer), with 6 mils between them and the ground plane. I do not have a formula for calculating how much capacitance that adds. Can't be much.

My current plan is to switch to an Abracon ABS25-32.768KHZ-1-T, which is a 12.5pf part. That should hopefully account for the extra capacitance that is messing with me. My only concern there is that it has a 50K ESR and the ATMEGA168 datasheet says that for a 12.5pf crystal you need your crystal to have an ESR of 30K or less. Thing is - Digi-Key doesn't stock a single 32K crystal that has an ESR of less than 50K.

Can anybody give me any ideas as to why this doesn't work? I am completely confused. Any feelings as to what bad things will happen due to my crystal's ESR being too high?

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

it might be that it will not become any better...
simple math:
1 mnth(30days)= 720Hours = 43200minutes = 2592000 seconds
1ppm of that figure is 2,592 seconds.
so 150 seconds is 58ppm.
ok, checked the datasheet it tells 20ppm basic tollerance+5ppm aging.....
pin 2 and 3 are left floating?
What happens if you put the 2x3pf on the xtal pins?
the behaviour is not linear, so with no caps you might be on one side of the parabole and with the 6pF you might be on the other side. You need to try a number of capacitors to see what for your specific design the best capacitor value is.

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

The capacitors are effectively in series, so you need a crystal with a 12 pF load capacitance.

Leon Heller G1HSM

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

nleahcim wrote:
- about 150 seconds/month slow without any capacitors on either line. It initially was about 250 seconds/month with a 10pf cap on each line.

That gives you a figure of 3.858ppm/pF, at that part of the curve.
That ppm/pF is not equal on both Xtal pins, that is the sum of both pins change.

You are ~58ppm too slow, or one part in 17280.

You can change the Divider to manage coarse trim, and then fine tune via caps from there.

Use a sample group of crystals, to derive an appx averaqe to trim to.

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

meslomp wrote:
it might be that it will not become any better...
simple math:
1 mnth(30days)= 720Hours = 43200minutes = 2592000 seconds
1ppm of that figure is 2,592 seconds.
so 150 seconds is 58ppm.
ok, checked the datasheet it tells 20ppm basic tollerance+5ppm aging.....
pin 2 and 3 are left floating?
What happens if you put the 2x3pf on the xtal pins?
the behaviour is not linear, so with no caps you might be on one side of the parabole and with the 6pF you might be on the other side. You need to try a number of capacitors to see what for your specific design the best capacitor value is.

The part I'm using is 10ppm. So you can see that it is wayyyyy off! I will try some 2.7pfs tonight (I have 2.7pf and 3.3pf). I do not expect it to yield positive results, but it is an easy test to run. Pins 2 and 3 are indeed floating. I previously tried 8pf and it sped it up by about 20s/month. I really think I need some negative capacitors or a CL crystal. I just don't know why!

I'm afraid that I do not buy your parabola theory - every reduction in capacitance has sped up the crystal (as should be expected). I just can't reduce the capacitance any further than zero.

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

Who-me wrote:
nleahcim wrote:
- about 150 seconds/month slow without any capacitors on either line. It initially was about 250 seconds/month with a 10pf cap on each line.

That gives you a figure of 3.858ppm/pF, at that part of the curve.
That ppm/pF is not equal on both Xtal pins, that is the sum of both pins change.

You are ~58ppm too slow, or one part in 17280.

You can change the Divider to manage coarse trim, and then fine tune via caps from there.

Use a sample group of crystals, to derive an appx averaqe to trim to.


What divider are you referring to?

I only am building two of these devices, so I do not mind hand tuning both. I just want it dead on.

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

Have you actually measured the frequency and with what?

Also, how are you using the frequency? Is it the main clock or just for the async timer?

If you are building for example a 1 Hz timer interrupt, make sure you don't have off-by-one errors in your calculations.

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

Jepael wrote:
Have you actually measured the frequency and with what?

Also, how are you using the frequency? Is it the main clock or just for the async timer?

If you are building for example a 1 Hz timer interrupt, make sure you don't have off-by-one errors in your calculations.


I am measuring the crystal frequency with a Witschi New Tech Handy II. Before I had access to this device I had observed that I was losing about a minute/week, and I had assumed that it was a software glitch. But this device looks at the actual crystal frequency (without loading it), so I am confident that the problem is with the crystal and not software.

The main clock is the internal oscillator - I'm just using the 32K for keeping my clock accurate.

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

nleahcim wrote:
Who-me wrote:

You are ~58ppm too slow, or one part in 17280.
You can change the Divider to manage coarse trim, and then fine tune via caps from there.

What divider are you referring to?

I only am building two of these devices, so I do not mind hand tuning both. I just want it dead on.

You need to divide the 32KHz to get your 1 second timebase, instead of divide by /128/256 to get to one second, you change the divider.

With a 16 bit reload timer, that is very simple in HW, however the 168 has a 2^N prescaler and 8 bit counter only, so some SW help is needed.

so you divide by (say) /256, for a 128Hz interrupt, and within that INT, run a SW counter, such that /256 changes sometimes to /255.
eg /32766 is going to move + 61ppm, covering most of the error.
Then we find : N=2;(128-N)*256+N*255 = 32766
so 126 times you divide by 256, and 2 times you divide by 255, for a total of 32766 cycles per second.
From 1s and below, you are clock-precise.

If you do not need 1s LSB, but are ok with 10s or 60s, then the swallow Sw can run less often, but follows the same idea.

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

Who-me wrote:
nleahcim wrote:
Who-me wrote:

You are ~58ppm too slow, or one part in 17280.
You can change the Divider to manage coarse trim, and then fine tune via caps from there.

What divider are you referring to?

I only am building two of these devices, so I do not mind hand tuning both. I just want it dead on.

You need to divide the 32KHz to get your 1 second timebase, instead of divide by /128/256 to get to one second, you change the divider.

With a 16 bit reload timer, that is very simple in HW, however the 168 has a 2^N prescaler and 8 bit counter only, so some SW help is needed.

so you divide by (say) /256, for a 128Hz interrupt, and within that INT, run a SW counter, such that /256 changes sometimes to /255.
eg /32766 is going to move + 61ppm, covering most of the error.
Then we find : N=2;(128-N)*256+N*255 = 32766
so 126 times you divide by 256, and 2 times you divide by 255, for a total of 32766 cycles per second.
From 1s and below, you are clock-precise.

If you do not need 1s LSB, but are ok with 10s or 60s, then the swallow Sw can run less often, but follows the same idea.


Oh, I understand your description now. What you suggest is certainly doable for me, but it seems like a workaround rather than a fix. Further, I wouldn't have a good means of testing the accuracy anymore. The best I could do is calculate out what seconds/month error I want (based on how I change the software) and then tune my crystal to that. Doable, but far from ideal IMHO.

I have ordered some 12.5pf crystals and I'm hoping they should fix things. They should be here next week at some point. I will report back if that was enough to fix the problem or if I'm going to have to do a software fix.

In the meantime, if anybody has any suggestions as to why this is happening - I'd love to hear them.

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

I'm a bit late to the game. But first, I'd go to a migration app note that has a discussion of watch crystals. E.g.
http://www.atmel.com/Images/doc8...

In particular the ESR guidelines.

I'd have to pull out a schematic to see which watch crystals we've used in a similar setup. Short answer is "we had no problems", but then again I don't remember testing for absolute accuracy. After all, when tweaking OSCCAL for UART comms the steps aren't that well defined anyway.

Side note: Are you positive you aren't "off by one" in counting the clock ticks?

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

theusch wrote:
I'm a bit late to the game. But first, I'd go to a migration app note that has a discussion of watch crystals. E.g.
http://www.atmel.com/Images/doc8...

In particular the ESR guidelines.

I'd have to pull out a schematic to see which watch crystals we've used in a similar setup. Short answer is "we had no problems", but then again I don't remember testing for absolute accuracy. After all, when tweaking OSCCAL for UART comms the steps aren't that well defined anyway.

Side note: Are you positive you aren't "off by one" in counting the clock ticks?


I am looking at the actual 32KHz signal coming off of the crystal, so it is very unlikely that it is a software glitch (ie off by one).

Thanks for the document - that has some very useful information in it. It also points out some potential crystals to use. None in the same package that I'm using, but oh well, I'll probably survive.

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

nleahcim wrote:

In the meantime, if anybody has any suggestions as to why this is happening - I'd love to hear them.

Crystals are tuned for a specific load value, and will have a XXX ppm/pF deviation slope from that.

One example
http://www.mouser.com/ds/2/3/ABS...

This targets STM32 parts, and defines 4pF +/-0.1pF for 20ppm initial tolerance, and then temperature can add up to -175ppm from that.

If you are unable to buy the exact crystal load, or it costs too much, or you want to improve over the YYppm factory tolerance, then software trim is not a 'workaround', it is a solution.

Many RTC chips use software trim, and you did say this
I only am building two of these devices, so I do not mind hand tuning both. I just want it dead on.

If you have a GPS 1pps source, you can calibrate/check to ~1ppm in 30 seconds, with a small SW routine.

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

Quote:
I am looking at the actual 32KHz signal coming off of the crystal, so it is very unlikely that it is a software glitch (ie off by one).

My thought on that statement.
1. Attaching a probe will often pull the frequency slightly.
2. I am not sure in which context you use the word glitch. The way that I calculate it based on your 150 seconds slow in about 30 days is about 3 seconds/day and that is slow by 1/30000 second/second. Which is very close to 1/32768 second/second.
I know that I have had a N+1 or (N-1) error quite often when using counters & timers.
So, I would still investigate that possibility. Perhaps show us the code to see how you have actually implemented the clock.
The other thing that you could perhaps do is to use a 32.768 KHz. TXCO. I know it pushes the cost up a little, but then as you said you are only building two and you dont mins spending time to get them spot on.
Time=Money!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

Who-me wrote:
nleahcim wrote:

In the meantime, if anybody has any suggestions as to why this is happening - I'd love to hear them.

Crystals are tuned for a specific load value, and will have a XXX ppm/pF deviation slope from that.

One example
http://www.mouser.com/ds/2/3/ABS...

This targets STM32 parts, and defines 4pF +/-0.1pF for 20ppm initial tolerance, and then temperature can add up to -175ppm from that.

If you are unable to buy the exact crystal load, or it costs too much, or you want to improve over the YYppm factory tolerance, then software trim is not a 'workaround', it is a solution.

Many RTC chips use software trim, and you did say this
I only am building two of these devices, so I do not mind hand tuning both. I just want it dead on.

If you have a GPS 1pps source, you can calibrate/check to ~1ppm in 30 seconds, with a small SW routine.


The point is that I believe I have properly loaded the crystal. But the crystal is not behaving like it is properly loaded. That is what I am confused by.

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

LDEVRIES wrote:
Quote:
I am looking at the actual 32KHz signal coming off of the crystal, so it is very unlikely that it is a software glitch (ie off by one).

My thought on that statement.
1. Attaching a probe will often pull the frequency slightly.
2. I am not sure in which context you use the word glitch. The way that I calculate it based on your 150 seconds slow in about 30 days is about 3 seconds/day and that is slow by 1/30000 second/second. Which is very close to 1/32768 second/second.
I know that I have had a N+1 or (N-1) error quite often when using counters & timers.
So, I would still investigate that possibility. Perhaps show us the code to see how you have actually implemented the clock.
The other thing that you could perhaps do is to use a 32.768 KHz. TXCO. I know it pushes the cost up a little, but then as you said you are only building two and you dont mins spending time to get them spot on.
Time=Money!

The probe is not actually electrically connected to my circuit. It has a huge coil that you put your crystal over and it picks up your 32KHz signal. Pretty cool piece of equipment. It is designed for testing watches. I am doubtful that it presents any measurable load to the crystal. This is verified by checking a known good system which measured to be about 1 s/month off (the smallest value the Witschi device can measure).

I understand your math, but please do understand that the crystal itself is measured to be off. Further, if I had a N+-1 sort of error it would be much more noticeable, as I use the timer to generate an interrupt 2048 times per second. So if I had an N+-1 error I'd be off by about 162000 seconds/month. The software glitch that I previously was looking for was that I was thinking my software could be locking up or losing time (ie not rolling over minutes properly or something), but I do not think either of those is the case here.

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

nleahcim wrote:

The point is that I believe I have properly loaded the crystal. But the crystal is not behaving like it is properly loaded. That is what I am confused by.

The crystal will be right (it is a much better judge of effective C than you are ;)

- At best one can only guess at the parasitic values, and then there is Miller-effect C.
So usually designs estimate low, and the Xtal runs slower than expected.

If you add the smallest C you have, you can derive a ppm/F slope,(per leg, if you want to be precise) and from that estimate the 'effective C' your circuit is presenting to the crystal in total.

I've seen some-ppm of variation caused by package alone, on HF crystals.

I've also seen 14MHz Murata 3 pin SMD resonators pushed down significantly, (almost 1%) purely by the on-chip-C.

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

Please let us know when you get to the bottom of it. I have soft spot for timing & crystals.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

Now we are getting down to sample variation...Does the same thing happen with more than one crystal (of the same type etc.)? Does the same thing happen with more than one AVR (of the same type etc.)? Does it happen with e.g. a PA AVR?

Are the boards squeaky-clean? No solder/flux/cleaner residue?

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

Go get a pf trimmer cap out of your local ham buddies junk box. Hook up the freq meter. Turn the trimmer until the freq is correct. Its Miller Time.

Imagecraft compiler user

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

All this trimming capacitor talk seems to defeat the purpose of the crystal. You can tune an LC to oscillate at any frequency you want, but it may not stay there.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

The xtal wont pull with temp like the LC

Imagecraft compiler user

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

bobgardner wrote:
Go get a pf trimmer cap out of your local ham buddies junk box. Hook up the freq meter. Turn the trimmer until the freq is correct. Its Miller Time.

Bob - the point is that even with no capacitors whatsoever the capacitor is behaving as if it has too much capacitance on it. So no amount of tuning is going to fix it.

I've ordered new parts and will be able to test them next week, hopefully.

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

theusch wrote:
Now we are getting down to sample variation...Does the same thing happen with more than one crystal (of the same type etc.)? Does the same thing happen with more than one AVR (of the same type etc.)? Does it happen with e.g. a PA AVR?

Are the boards squeaky-clean? No solder/flux/cleaner residue?


I have tried two different crystals of the same part number and I got nearly identical results. I have not tried different AVRs - I'd rather not desolder the one. The PCB is fairly clean - I can try cleaning it better but I think you'd agree that that is an unlikely culprit!

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

Quote:

but I think you'd agree that that is an unlikely culprit!


Not necessarily. We've seen stray capacitance problems before. A notable one is the signals on a multiplexed 7-seg LCD display driven by a '169. If the circuit board wasn't squeaky-clean there were problems. It boiled down to residue causing stray capacitance. Whether that applies to watch crystals I have no idea.

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

I suggest trying the xtals in a different circuit altogether, where you can control the C's.
Perhaps use that circuit to drive your AVR.

Attachment(s): 

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

OK - I got some 12pf crystals (Abracon ABS25-32.768KHz-1-T). First I tested it again without any load caps on my 6pf crystal, and measured it to be about 158 seconds/month slow. This was after giving it a very thorough cleaning. So this is not a case of a dirty PCB.

I then removed the 6pf crystal and installed a 12pf crystal. No caps. This measured to be 80 seconds/month fast! Progress!

Adding in 8.2pf caps on both sides of the crystal got me to 10 seconds/month slow. Getting closer.

Switching to 6.8pf caps on both sides gets the crystal to about 3 seconds/month slow. This is now respectable.

Bringing it down to 5.6pf caps on both sides gets the crystal to about 13 seconds/month fast.

Replacing just one cap with a 6.8pf gets it to 5 seconds/month fast.

Looks like I really need something like ~6.5pf on each side. But I don't have that so I'm sticking with 6.8pf. Plus my caps are +-0.5pf so who knows...

I still don't know why I have so much capacitance on these traces - but whatever - it seems to be working nicely now.

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

Sounds good.

The caps do not have to be exactly identical, so you can change just one, and the ppm/pF is usually not quite the same, so that gives some leeway on trim.

You can also add fractional pF with a short piece of ribbon cable, or a small shielding-cap, but you are likely below the Xtal variation already.

Try a few crystals from the ones you have just got.
(give them time to cool, or socket them)

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

A small trimmer cap. say 1.2-2.7 pF. should get you spot on (at a constant temperature anyway). You can get small clip on ovens which you could couple up to the crystal & then get it to less then 1 sec/month or better.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

Michael, you could try the old trick of twisting two lengths of insulated wire together to make an adjustable cap. Just trim the overall length with a pair of side cutters to adjust the capacitance.

Cheers,

Ross

Ross McKenzie ValuSoft Melbourne Australia