Getting an accurate clock with a crystal

[PCChazter]

Sorry for not updating, I have been busy, and have been trying to test some of the suggestions here before replying. I have taken another F28027, and put it on a launchpad dev board that I had with a burnt chip on it (replacing the chip), and put a crystal that was giving me error on my board onto the dev board (I have tested a few crystals now). I then created a new copy of my code, and only copied the relevant code that gets the chip initialized, and has my clock code on it.

I did not put any capacitors on the crystal, my thoughts on this was to let it run off of just the stray capacitance, and it should run fast. Please correct me if this is not correct.

I don't know how much exactly it is off, as I have not run it long enough, but over a half hour it is about 40 seconds slow...dunno what that is all about.

I have pretty much come to the conclusion that I'm going to have to use a dedicated clock chip, but I would still like to know what is going wrong. I could be damaging the crystal when installing it, but on the last crystal I have tested, I made sure to put my hot air to 260ºC, it was set at 300ºC, and I have read that anything over 260 risks chance of damage. It could be the particular MCU I am using sucks at using a crystal, keeping in mind I have now tried 2 of them. It could be residual flux is causing a huge amount of stray capacitance, I have noticed that when removing the crystals and MCU there has been flux underneath, regardless of how much I clean it with iso and qtips. Any other ideas?

Just a guess but I wonder if latency in the ISR could effect this? Like I wonder if the timer reload is somehow dependent on the ISR completing? Or the timer reload time is somehow a factor?

So if you change the timer so instead of going off every 1ms it goes off every 5ms does this change the error? 20 hours - 7.2 x 10^6 triggers - only need a small time error per timeout to get 20s error.

Tom

I have changed my code to trigger the interrupt from 1s to 10s, and have added a delay in the ISR of 1s, so I should see it be off by 1s*(however many seconds it has run/10s) if this is the case.

Have you tried using timer 0 or 1?

I believe timer 2 is the only one that can use the crystal

If you need accurate RTC timing you can invest in one DS3231 TCXO RTC chip. That thing is guaranteed to stay within 3 seconds per year. And if you need a faster accurate clock you can trim the internal RC oscillator against this chip (effectively a digital feedback PLL.)

Or if you want to, your micro can be clocked off an atomic clock's 10MHz output.

I am thinking I will need to end up using a dedicated clock chip.

The next best place to look for what is going wrong is compare the "drive strength" of the chip, to the same on the crystal, driving the crystal with too much power can cause gross calibration issues, essentially the crystal is swinging too hard and detuning itself somewhat. if the drive strength is too high, you may need to add a series resistor to reduce the drive strength.

The datasheet for the MCU says it is a 1.8V crystal input/output, I don't see anything on the crystal.

Despite its claims of Real time, Background, and Unobtrusive, are you sure the debugger doesn't stop the internal clocks for a few cycles every time it reads the internal registers.

I have turned off everything that I can tell that relates to debugging, I will see how it does.

I think the new layout would be worse, all those long tracks and especially gnd would have quite a bit of inductance.

Edit: Something like this appears to have the shortest 12MHz tracks.

Is it a good idea to run that trace under the XTAL? A few pages I have found have mentioned to have a separated ground plane under the XTAL, I have also seen an example close to what I have on page 7 of this pdf: http://www.cypress.com/file/221431/download. Also, I've seen a few people on other forums suggesting others to have the capacitor ground only attached to your main ground net at 1 point to reduce interference. What do you think of this? Perhaps a mixture of what you have there and what I've read with a separate ground plane on the top layer, or is what I'm reading irrelevant or incorrect?

[rs20]

When you say "dedicated clock chip", just be aware that that's a vague term that could mean one of at least two different things:

• A real-time clock chip (e.g. this) -- a device that counts time itself, and you can ask it for the time over SPI
• A crystal oscillator (e.g. FOX924), a quartz crystal, load capacitors and oscillator all in a single package, which outputs (say) 20 MHz which you can then input into your microcontroller. Eliminates concerns about stray capacitance, etc, because that's all internal to the package.

Not sure what you had in mind, but be sure to consider both.

Also, it's unfortunate that we can't even elucidate whether your crystal is oscillating at the wrong frequency, or whether your code is not dividing as you expected. It'd be really good to figure this out -- even if you don't have a frequency counter, you should be able to statically clock your CPU and at least check that a timer output is toggling after precisely N clocks as you expected.

[pigrew]

260 C may still be too hot if you are using a hot air gun without a controlled thermal profile. I'd try using lead based solder at a lower temperature like 220 C, preferably with a preheater. Above 250C should only be needed for lead-free solder.

For the new layout, the bottom grounds don't have a direct path to the chip's ground. They meander around too much. I would add a few ground vias around the crystal. Look at the example layouts of evaluation boards for inspiration.

Also, don't be afraid to rotate the crystal 30 or 45 degrees, it may make the tracks more direct, though it's probably unnecessary.

Maybe just live with the frequency inaccuracy, and scale your time constants accordingly?

-Nathan

[PCChazter]

So first off, never assume that your reference is correct. Turns out the clock on the computer I was using is fast, so no matter what I did, my MCU always seemed slow.

With that out of the way, I used a serial terminal program on a different computer that allows for time stamps and logging, and started to graph my time offsets. Turns out there is a bit of ISR latency as suggested in this post:

Just a guess but I wonder if latency in the ISR could effect this? Like I wonder if the timer reload is somehow dependent on the ISR completing? Or the timer reload time is somehow a factor?

So if you change the timer so instead of going off every 1ms it goes off every 5ms does this change the error? 20 hours - 7.2 x 10^6 triggers - only need a small time error per timeout to get 20s error.

Tom

It changes it very slightly, which is why I couldn't see it before (as well as the computer clock being fast), but the terminal I am using logs ms as well, so when I graph it, I can see it. If I change it to a 20s period, it is fast, change it to 1 or 2 s, and it is slow. I'm guessing it is like you say, and the process to reload the timer takes more than 1 clock cycle, which is why a longer period seems better. Which is weird because the way that it is described in the datasheet, it made it seem like it should not add latency. I could adjust the period to overcome this, as I want a 1s interval.

Another thing I tried was to use the dedicated PWM module on the chip (still part of the MCU, just not directly tied to the CPU) instead of the timer. Unfortunately the prescaler is not as configurable as the timer, so I have to make it count in ms intervals, then my ISR adds 1s to my clock time variable every 1000ms. I also noticed the same latency on the PWM on anything under 5ms, but I'm guessing this could be partially because of my ISR taking too long to send the information over SCI, as well as any overhead latency it has.

260 C may still be too hot if you are using a hot air gun without a controlled thermal profile. I'd try using lead based solder at a lower temperature like 220 C, preferably with a preheater. Above 250C should only be needed for lead-free solder.

I have no idea how controlled the temperature on my hot air is, it's a cheap china made one. I use leaded solder, so I will try 220º next time, as long as I don't have to wait 10 minutes for my solder to flow :p. I do not have a preheater though...

For the new layout, the bottom grounds don't have a direct path to the chip's ground. They meander around too much. I would add a few ground vias around the crystal. Look at the example layouts of evaluation boards for inspiration.

I see what you mean with meandering, didn't notice that when I posted it. I did do some research on layout, but they don't all follow the same rules, which is why I seeked out advice on my problem.

Also, don't be afraid to rotate the crystal 30 or 45 degrees, it may make the tracks more direct, though it's probably unnecessary.

I will give this a try and see if it's more direct. I didn't see the spot for Kicad to rotate manually, but I see it now.

Maybe just live with the frequency inaccuracy, and scale your time constants accordingly?

I think this is what I'm going to do, and have the dedicated chip as an added option on my board.

When you say "dedicated clock chip", just be aware that that's a vague term that could mean one of at least two different things:

• A real-time clock chip (e.g. this) -- a device that counts time itself, and you can ask it for the time over SPI
• A crystal oscillator (e.g. FOX924), a quartz crystal, load capacitors and oscillator all in a single package, which outputs (say) 20 MHz which you can then input into your microcontroller. Eliminates concerns about stray capacitance, etc, because that's all internal to the package.

Not sure what you had in mind, but be sure to consider both.

Sorry, I meant dedicated RTC chip, with everything including the clock counter packaged in one.

Also, it's unfortunate that we can't even elucidate whether your crystal is oscillating at the wrong frequency, or whether your code is not dividing as you expected. It'd be really good to figure this out -- even if you don't have a frequency counter, you should be able to statically clock your CPU and at least check that a timer output is toggling after precisely N clocks as you expected.

I'm still not sure my crystal is oscillating at the right frequency, but do think the MCU has some overhead that is altering my clock readings. I could do what you suggest there, I still might, but for now I think I'm going to settle with that, and do some software trimming.

[StillTrying]

The reloading of the PreScaler/divider with (11999 +1) and reloading of the timer with 1000, is all done in hardware so Interrupt latency shouldn't have anything to do with it.
But,
"I'm guessing this could be partially because of my ISR taking too long to send the information over SCI, as well as any overhead latency it has."

Sounds like a bad idea!

If you made the PreScaler 11,999,999, then timer2 would become a 1 second countdown timer all in hardware, which could be read anytime and not be effected by any interrupts, read it inverted '~' for a 1 second up counter.

1 second per hour is 277ppm.

Edit. PreScaler is only 16 bit, so largest useful divider could be 59,999 giving 5ms 200Hz ticks to the 32 bit timer2.

[Bendba]

This is also something that I considered at first. The prescaler for the timer is exactly the way you describe, so I have it set to 11999 instead of 12000 to get 1ms timer intervals, which is then counted down from 1000 on the timer so that my interrupt triggers (or should trigger!) every 1 second.

Hi,
Here is my uneducated opinion, I could be wrong.
Your timer preload of 1000 sounds wrong to me, if you want to count 1000. Your timer interrupt would be on zero, which means you've counted to 1001, not 1000. Same reason you had to load your first time with 11,999 instead of 12,000.
Plus the software handle of the interrupt, even if it only takes a few cycles.
Why not seeing your timer at 11,999,999 (+- a correction value if needed) instead?

[StillTrying]

Your timer preload of 1000 sounds wrong to me, if you want to count 1000. Your timer interrupt would be on zero, which means you've counted to 1001, not 1000. Same reason you had to load your first time with 11,999 instead of 12,000.

The data sheet says the timer is reloaded with 1000 when it reaches 0, so it should count down
3, 2, 1, 1000, 999.
If there was 1 extra ms in every second, the seconds count would be slow by 3.6 seconds per hour.

[Bendba]

Unless your oscillator is running too fast, especially with the low cap values used. If you count a little too much but too fast, at the end, you could only be going a very little bit too slow.


But if the timer has an immediate hardware reset, that's not the problem. But then I don't know why you would have needed to set your prescaler at 11,999 instead of 12,000. That would be because your crystal is about 83ppm too fast, which is not within the specs stated at the start.


Note: I just noticed the mention of the timer prescaler being a 16 bit timer so, yes, gotta be done in two steps

[StillTrying]

It's on page 62 of sprufn3d.pdf  http://www.ti.com/lit/ug/sprufn3d/sprufn3d.pdf

The general operation of the CPU-timer is as follows:
The 32-bit counter register TIMH:TIM is loaded with the value in the period register PRDH:PRD. The counter decrements once every (TPR[TDDRH:TDDR]+1) SYSCLKOUT cycles, where TDDRH:TDDR is the timer divider. When the counter reaches 0, a timer interrupt output signal generates an interrupt pulse.

[Dr. Frank]

You have a 277ppm error, that seems to be too big an error as to be located in the XTAL circuit.
Usually, you can't trim an XTAL so far off.

This 277ppm deviation corresponds to about additional 3 clock counts, i.e. 12003 instead of 12000 divider counts.
These give -250ppm and -27ppm, caused by the XTAL itself.

So I assume, that your interrupt routine may have these 3 hidden clock delays.


Embedded controllers usually have very bad oscillators, like a simple logic inverter, which requires this 1M series resistor.
The driving level is often far too high, which doesn't give a reasonable accuracy, like these specified +/-15ppm. This latter value might be achieved easily in a proper 'analogue' oscillator circuit, like Colpitts, or similar.

So for your digital oscillator, you shouldn't have too high expectations, but about 30..50ppm frequency accuracy should be achievable, when using proper capacitors.

For mass production, automotive business, these capacitors were first chosen to give a good oscillation margin. (start up behavior).

Afterwards, the XTAL will be produced in such a manner to meet the proper center frequency for the given controller.
This 'pairing' of XTAL and controller is usually done at the XTAL manufacturer, who determines the resonance capacitors C1, C2, and the XTAL grinding parameters.
The manufacturers of the XTAL, or of the controller often recommend proper parts and values in their specs.
Kyocera is quite bad in this aspect, as even the XTAL cut is not specified (is it an AT-cut type??)

In manufacturing, you then have about +/- 20ppm or more deviation, due to XTAL and oscillator exemplar variations.

So the software accounts for variable correction factors, which are determined by an external frequency counter at the EOL testing.
There's no other way to achieve <= 10ppm accuracy, or about 1sec/day, which is required by many automotive customers for the cars clock.

The software should have a trimming range of several hundred ppm, and a resolution of 1ppm.
That means, that you correct the clock by single counts every Nth interrupt, with sufficiently long correction counters.


For your problem, you really need a precise counter, to decide, whether the fault is in the software, i.e. my supposed 3 counts, or if something is completely wrong with your XTAL circuit.

The fine tuning, down to these +/-15ppm has also to be accomplished with a frequency counter.

PS: Overheating of an XTAL usually causes a total failure, but very probably no such deviation of the resonant frequency.
Remember, latter is determined tightly by the thickness of the Quarz disc, which will not change at all by heating.

Frank

[Dr. Frank]

As your clock is always slow, it just came to my mind, that other interrupts in your system may delay your timer or counter updates, or maybe skip increments from time to time.

It is important for such programmed clocks, that the timer reloads itself, w/o your 1ms interrupt.
Then, your timer and counter interrupts should have highest priority, so that any other interrupt, or system events can't disturb your timing routines.

Frank

[PCChazter]

Oh man, so much valuable information, thanks you guys! I think I finally have something livable! When I first read through the documents for the registers, I had understood that as soon as the counter gets to 0 it resets, but turns out it takes an extra clock cycle to do this, so I should be treating it the same as the prescaler and subtracting one. It also didn't help that unbeknownst to me, the computer clock I was trying to measure it against to was fast, and I think it slowly got faster over time. So no matter what I did at first it seemed as though I was not improving it  .


So I have changed the prescaler to 11 (from 11999), changed the period to 999999 us (instead of 1000ms), and put 10pF caps on the crystal. Changing the prescaler made a huge difference, because now an error of 1 clock cycle on the counter is equivalent to 1us instead of 1ms, then changing the period to 999999 gave me my base line, which I then did some software adjustment to get it looking good. In the end, the period (with the adjustments) is 1000030. Look below to see a graph of the MCU time minus my computer time over 7 hours.

I will continue to try to improve my system, but for now it is livable. I will probably end up using the dedicated RTC that was suggested (or similar), and use some of the layout suggestions given here. I will still use my crystal timer RTC as a lower accuracy clock, but make the dedicated RTC an option for where higher accuracy on the clock is desired.

Even though I may have solved my problem with the help of this post, I still have some questions.

Embedded controllers usually have very bad oscillators, like a simple logic inverter, which requires this 1M series resistor.
The driving level is often far too high, which doesn't give a reasonable accuracy, like these specified +/-15ppm. This latter value might be achieved easily in a proper 'analogue' oscillator circuit, like Colpitts, or similar.

Your post was helpful in coming to terms with a crystal clock worse than the stated 15ppm, thanks. I am not sure what kind of oscillator circuit this MCU has, the only thing I can find is it uses the internal 1.8V regulator meant for the "CPU and logic digital power". Should I put this 1M resistor in place, even though there is no mention about it in the datasheet, and would it increase my likelihood of getting a more accurate and repeatable clock?

"I'm guessing this could be partially because of my ISR taking too long to send the information over SCI, as well as any overhead latency it has."

Sounds like a bad idea!

Just to clarify, I tried using a PWM interrupt every 1ms to see if that was any better, and have added a serial output of 10 characters at 9600baud into my ISR every 1000ms so I can log it using a serial terminal on my computer. So total time taken to send characters =  10 characters * (10 bits * (1 / 9600)) = 10.4ms. If my interrupt is every 1ms, and it can't override the interrupt while it's busy sending, it would miss 10 interrupts every 1000ms. The PWM would still keep on ticking, but the CPU wouldn't count those ticks cause it was already busy. This has no effect on my timer2 interrupt, because that ISR triggers every second, not every ms, so the ISR can complete before the next one triggers. Either way, I went back to using timer2, so this is irrelevant.

So on my own dev board I just looked at the Timer LED flash example and CPU timer examples and by slight reconfiguration of those it was posible to have it flash a LED based on the CPU timer interrupt.
I could accurately measure the frequency / jitter though I did not since it seems to me that the timer does not really need to be RESET in the ISR, it is an automatically reloading timer so the RATE of the interrupts should be accurate to the tolerances of the crystal oscillator.  The JITTER of the interrupt timing of my LED flash will indeed vary with the interrupt latency of the device but that is not a cumulative error since as far as I can see the CPU doesn't have to restart the timer so it is always running and therefore the interrupt latency is not an error source in the interrupt rate (long term).

I am not reloading the timer in my ISR. Do you have any idea how much jitter can be expected? I graphed my MCU RTC readings against the timestamp in my serial terminal after getting my MCU trimmed in software, and this is what I got:

close up of first 10 minutes on same graph:

I imagine some of this weird jitter is related to using the clock on my computer as a reference, but I was still curious as to what could be related to the ISR jitter.