32MHz calibration - Datasheet misunderstanding

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

I am doing some XMega tests that require a 32.5MHz clock speed, and found this in the datasheet...

The 32MHz run-time calibrated internal oscillator is a high-frequency oscillator. It is calibrated during production to
provide a default frequency close to its nominal frequency.

This oscillator can also be adjusted and calibrated to any frequency between 30MHz and 55MHz. The
production signature row contains 48 MHz calibration values intended used when the oscillator is used a full-speed USB
clock source.

Now this really has my interest, but I think I am not understanding the proper meaning of this text. What I get form this is...

1) I can change the 32MHz internal clock to anything betwen 30MHz and 55MHz by messing with the RCOSC32M bits in Studio6. If, so great!!

2) The 32MHz osc is actually set to run at 48MHz and not 32MHz from the factory??! This can't be correct, I have verified that mine is indeed running at 32MHz.

I'm sure I just misunderstood point #2, but the part about being able to alter the frequency is of great interest to me right now.

So ignoring this 48MHz text, I know that the internal osc is running at 32MHz right now. So if I just bumped it up to known percentage of 32, I should be able to get it to 32.5 MHz easily or any other value up to 55MHz.

I cannot seem to find a detailed doc on using RCOSC32M/A and how this affects the calibration. is this a 16 bit value of fractional increments of some kind?

I am away from my lab right now, or I would just hack around until I figured out the values.

Thanks,
Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

Quote:

2) The 32MHz osc is actually set to run at 48MHz and not 32MHz from the factory??!

No they are saying that as well as the 32MHz calibration value that is loaded by default they also tested the chip at 48MHz, found out what the calibration value would be for that then wrote it into the signature row. You can write code that reads that signature row value, loads it into the calibration register and given the right temperature and Vcc the chip will also run at 48MHz for you too. That can then be divided down to the 12MHz that USB runs at.

If you can assume the calibration is linear and Atmel give you two datapoints at 32MHz and 48MHz it should be possible to do a y=mx+c style calculation to find out the calibration for any intervening value including 32.5MHz. Though it might be best (on a per chip basis) to actually calibrate it using a scope/frequency meter and then write that value for each chip somewhere safe like EEPROM.

BTW surely it's the combined CALA and CALB registers you use to do the actual calibration (a brief reading of the manual suggests).

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

Ok thanks, that makes sense. So then once I know what the offset to go from 32MHz to 32.5MHz would be for one chip, I can just use that value to offset the calibration in any other to achieve a perfect 32.5MHz each time since I am just adding the difference, not setting a value.

This is great news as I need to reach 65MHz internally and cannot find a 32.5MHz external clock to run the PLLx2 with.

I am doing some 1024x768 VGA experimentation right now.

I wonder if I can set this in code? Have my program start up, read the current calib. bytes, then add the offset up to 32.5MHz?

Yep, finally found it in another datasheet...

For the 32MHz oscillator, this register can be
written from software to make the oscillator run at a different frequency or when the ratio between the reference clock
and the oscillator is different (for example when the USB start of frame is used). The 48MHz calibration values must be
read from the production signature row and written to the 32MHz CAL register before the DFLL is enabled with USB SOF
as reference source.

I guess this 48MHz USB operation is the reason why these babys can overclock so easily. In reality, they are 48MHz uCs. I wonder why they are'nt simply rated at 48MHz then? Hell, I had one running at 75MHz for days without any issues at all!

Coolness!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

Quote:

Hell, I had one running at 75MHz for days

Quote:

Coolness!

Hmmm--just as a guess when overclocking that much a more appropriate word would be "warmness". Or maybe "Hot!".

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

Nope, no heat or substantial current increase at all. I was messing around with the 75MHz project (XMega 256 using 90% progmem and 100% SRAM), driving almost 50 IO lines and I let it run for over a month while I worked on other projects. It never reset or warmed up at all.

My current release is going out as a 64MHz XMega384.

My next project needs that 65 MHz final clock, so I am going to tweak the calib. to get the internal running at 32.5MHz and run it through the PLLx2.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

The best way would be to use an external 32.768KHz crystal as a reference for the DFLL, and use the DFLL to calibrate the internal clock which you can then PLL up accurately to your target frequency. You can also DFLL the internal clock using the internal 32KHz RC oscillator, but that won't give you the best results.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

AtomicZombie wrote:

to get the internal running at 32.5MHz and run it through the PLLx2.

There is a divide by 4 prescaler between 32Mhz oscillator and PLL. So the PLL multiplication factor should be 8.

Ozhan KD
Knowledge is POWER

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

AtomicZombie wrote:
I guess this 48MHz USB operation is the reason why these babys can overclock so easily. In reality, they are 48MHz uCs. I wonder why they are'nt simply rated at 48MHz then? Hell, I had one running at 75MHz for days without any issues at all!

When you say "without any issues at all" did you test every function, like writing to EEPROM, reprogramming flash memory, ADC conversion accuracy etc? Chances are the CPU core is fine at 75MHz but some of the peripherals will break.

As an example I found I could run an AT90USB1286 at 16MHz on 3.3V but when trying to read data in PROGMEM it would either be corrupted or just reset.

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

My overdrive tests have never involved EEPROM or ADC, but I do R/W the entire 32k SRAM and have the XMega384 progmem filled to 100% capacity. I also use all 8 timers, the PLL, and 48 out of 52 IO pins.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

fyi, AVR1610: Guide to IEC 60730 Class B Compliance with XMEGA describes some XMEGA self-test code.
It has a EEPROM test and a DAC-to-ADC wrap test (and such).

"Dare to be naïve." - Buckminster Fuller