Xmega clock accuracy problems

Log in or register to post comments
Go To Last Post
12 posts / 0 new
Author
Message
davidgrm
davidgrm's picture
Level: Hangaround
Joined: Wed. Dec 3, 2003
Posts: 133 View posts
Location: Cape Town
#1
Posted by davidgrm: Thu. Sep 19, 2013 - 05:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xmega = 64A3U-AU

I posted about this problem before: http://8515.avrfreaks.net/index....
I thought I had everything figured out but I was wrong.
I have done many tests to ensure that the autocalibration is working and that its source is the external crystal.

I have tried adjusting DFLL comp registers, DFLL Cal registers and also the value in the PER register. Nothing seems to help. I have spent hours, no make that days fighting with this. I am using the 1 second pulse from a GPS module. I have then run it and checked which register settings give me the most accurate time.For example it ran for 24 minutes and went out by about 16ms which was fine for my application. I then used that value in the comp register and ran it and compared the time with 2 stop watches. After about 30 minutes it was more than a second out. The external watch crystal has a fairly constant frequency of 32770. The DFLL seems to cause the 32Mhz to drift over time. All suggestions are welcome

Tags:

AVR Microcontrollers, AVR XMEGA
Top
GTKNarwhal
GTKNarwhal's picture
Level: Hangaround
Joined: Fri. Apr 29, 2011
Posts: 326 View posts
Location: Portland, OR, US
Posted by GTKNarwhal: Thu. Sep 19, 2013 - 11:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you disabling the DFLL after it achieves the best frequency for the RC32M oscillator? Over time the calibration register will increment/decrement by one around the value that gives the best fit. With a DFLL calibration step size of 0.23%, you should expect the frequency of the RC32M oscillator to increase/decrease by that percentage at somewhat regular intervals.

EDIT: so over shorter periods of time the accuracy may appear to be erratic, but over longer periods the variations should average out. How long of a period are you sampling when doing your testing?

Gamu The Killer Narwhal
Portland, OR, US
_________________
Atmel Studio 6.2
Windows 8.1 Pro
Xplained boards mostly

Top
Who-me
Who-me's picture
Level: Raving Lunatic
Joined: Sun. Mar 25, 2007
Posts: 2236 View posts
Posted by Who-me: Fri. Sep 20, 2013 - 01:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
The DFLL seems to cause the 32Mhz to drift over time. All suggestions are welcome

I do not think it drifts, so much as has that quanta limit.

A DFLL is not a Phase-locked loop, it just finds the nearest value, and with this basis :

DFLL calibration step size 0.22%

and taken over 30 seconds, that is ~4 seconds.

If you need higher timing precision, and 16ms is ok, why not work directly from the 32KHz Xtal timer ?
That can resolve to ~30us, plus any Xtal ppm drift.

Top
davidgrm
davidgrm's picture
Level: Hangaround
Joined: Wed. Dec 3, 2003
Posts: 133 View posts
Location: Cape Town
Posted by davidgrm: Fri. Sep 20, 2013 - 08:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Are you disabling the DFLL after it achieves the best frequency for the RC32M oscillator?

I did disable it when I tried changing the CAL register. I found that the resolution was not fine enough. It was either under or over, so I decided to let the DFLL run and change the comp register instead.

The method I used is as follows:
I have a 32bit counter with the PER set to 32000 - 1 and no pre-scaler. The 1 second pulse triggers an event which captures the count. I then calculate the error by subtracting the captured time from 1000.
The system runs and after it reaches a maximum error I switch off the DFLL and inc / dec the comp value and switch it on again and repeat. I tried various error levels up to 30ms. The program keeps a record of the comp setting that ran the longest before reaching the pre-set error level. I leave the system running for some hours and at the end have the 'winner' which ran for the longest. I then put that value in eeprom so that on start up I can load it into the comp registers. I tried a similar strategy, I turned off the DFLL and changed the CAL registers. Unfortunately as stated above all of these methods gave poor results. It just seems inconsistent. It will run for 30 minutes with a few ms drift and then the next 30 minutes it will be out by more than a second. The crystal in the meanwhile has been very constant.

Quote:
and taken over 30 seconds, that is ~4 seconds.
I am not sure how you came to 4 seconds??
Quote:

DFLL calibration step size 0.22%
I assume that this is what each single digit change to the CAL register represents? Is there a document that details the speed at which these steps occur when the DFLL is on?

Quote:

why not work directly from the 32KHz Xtal timer ?

because being a watch crystal the frequency is 32768 which does not allow for a ms time. I am now going to try creating a 1 second event from the RTC which can use the crystal and then use the event to capture the ms time and generate an interrupt. I will then do my own real time calibration by changing the per on the ms counter. I hope this works because I am running out of ideas :(

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 6337 View posts
Location: New York State
Posted by steve17: Fri. Sep 20, 2013 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
Quote:

DFLL calibration step size 0.22%
I assume that this is what each single digit change to the CAL register represents? Is there a document that details the speed at which these steps occur when the DFLL is on?
The DFLL is comparing the 32 MHz freq with 1024 Hertz. So I assume the DFLL is adjusting the CAL register 1024 times per second. The 1024 clock of course is derived from the 32 kHz oscillator.

Top
davidgrm
davidgrm's picture
Level: Hangaround
Joined: Wed. Dec 3, 2003
Posts: 133 View posts
Location: Cape Town
Posted by davidgrm: Fri. Sep 20, 2013 - 09:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So I assume the DFLL is adjusting the CAL register 1024 times per second

I assumed something like that too. But then the 32mhz frequency should be fairly tightly locked to the 32,768khz crystal. I can see using a digital scope that the crystal is very constant whereas the 32mhz seems to drift slowly in one direction and then the other. This is most likely fine if you want to keep a clock going for long time periods such as weeks or months. In my case I am trying to do accurate timing over a period of just a couple of hours. Unfortunately as already mentioned it sometimes goes out by more than a second in half an hour

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 6337 View posts
Location: New York State
Posted by steve17: Fri. Sep 20, 2013 - 10:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GTKNarwhal wrote:
EDIT: so over shorter periods of time the accuracy may appear to be erratic, but over longer periods the variations should average out.
But I suspect the variations will not average out. I don't know if this DFLL can do that. Let's say each 1/1024 second, the DFLL makes an adjustment of one in the CAL register. On one interval it finds the 32 MHz osc. is too fast so changes the CAL by one in the slower direction. In the next interval it finds the 32 MHz osc. is too slow so it changes the CAL by one in the faster direction. It keeps this up forever.

Let's say in one interval the 32 MHz osc. is actually x amount too fast. In the next interval it is 3x too slow, and this pattern repeats forever. After each fast/slow cycle the 32 MHz clock will be 2x slow.

This assumes that the DFLL only looks at each 1/1024 interval and makes the CAL adjustment and forgets about the precise error.

Maybe if the DFLL was a smart one, it could make long term adjustments. It could accumulate the actual errors in each interval. It this case it would accumulate 2x in the slow direction each fast/slow cycle. When the accumulation got big enough it could adjust the CAL by an additional amount. But is our DFLL that smart?

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2203 View posts
Posted by mojo-chan: Fri. Sep 20, 2013 - 11:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So are you still using those cheap and nasty watch crystals, or did you get something better?

What test equipment are you using? Is your frequency counter using an external reference clock? I wouldn't rely on a digital 'scope to show any kind of drift or timing error with accuracy.

For the kind of short term stability you want a fast OCXO is the only real option, or perhaps a very good xtal. Have you looked at MEMS oscillators? They are supposed to be quite good.

Top
davidgrm
davidgrm's picture
Level: Hangaround
Joined: Wed. Dec 3, 2003
Posts: 133 View posts
Location: Cape Town
Posted by davidgrm: Fri. Sep 20, 2013 - 11:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@mojo-chan - The problem is that I already have PCB's made. I am not sure how 'cheap and nasty' the crystals are. They are rated at 20ppm, which to my understanding should give me about 1.7 seconds in a day, not in an hour. The point is that according to the scope the crystals are constant. I can see that using the DFLL the 32mhz clock is not constant, it speeds up and slows down. I know that the scope is not the best thing to use, but it is what I have. The fact the using GPS and stop watches is backing up what the scope says, I therefore assume it is correct.

I agree with Steve. In the absence of more information on how the DFLL works one can only assume it is flawed for this application or perhaps all applications? If I was to purchase an (about $100 or more) OCXO I would not need to use the DFLL.

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2203 View posts
Posted by mojo-chan: Fri. Sep 20, 2013 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The DFLL is only designed to get you so far, e.g. able to so RS232 comms without an external xtal. It isn't designed to give you the same level of precision as a crystal.

I meant to say TXCO, not OCXO, sorry. A 16MHz TCXO only costs a few Euros.

Having said that you could just make your own TCXO using the XMEGA's on-board temperature sensor. I do that to temperature compensate the RTC, but I'm sure you could use it for the 32MHz oscillator as well. Well, rather than trying to adjust the oscillator with the DFLL registers it might be better to use a fast timer and adjust the period.

Top
davidgrm
davidgrm's picture
Level: Hangaround
Joined: Wed. Dec 3, 2003
Posts: 133 View posts
Location: Cape Town
Posted by davidgrm: Fri. Sep 20, 2013 - 01:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RS232 on the xmega works fine without the DFLL being used. Based on Atmels documentation the idea is to use the external watch crystal to improve on the clocks accuracy. As I stated at the top of this post you will see that your idea with the PER is what I am about to do. As already state I built the PCB assuming that the DFLL with watch crystal would suffice. There is no provision fo a TCXO

Top
GTKNarwhal
GTKNarwhal's picture
Level: Hangaround
Joined: Fri. Apr 29, 2011
Posts: 326 View posts
Location: Portland, OR, US
Posted by GTKNarwhal: Fri. Sep 20, 2013 - 02:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I assume that this is what each single digit change to the CAL register represents? Is there a document that details the speed at which these steps occur when the DFLL is on?
The spec sheet for the ATxmega*A3U, section 36.1.14.3, table 36.24, line 5 "DFLL calibration step size."

EDIT: I just realized that's not what you were asking...

EDIT2: From the XMEGA AU Manual:

Quote:
The oscillator is considered running too fast or too slow when the error is more than a half calibration step size.
This doesn't give the speed that changes occur directly, but allows you to determine the rate at which they should occur from the frequencies of the two oscillators involved.

Gamu The Killer Narwhal
Portland, OR, US
_________________
Atmel Studio 6.2
Windows 8.1 Pro
Xplained boards mostly

Top