Xmega32E5 32MHz oscillator issue - measures ~60MHz?!

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

I'm having issues with the 32MHz internal oscillator on a Xmega32E5.  The 2MHz clock checks out fine.  I also tried enabling the 8MHz oscillator and using PLL for 32MHz and that works fine.  However, if I attempt to use the 32MHz oscillator, I'm seeing a ~60MHz clock at a much lower amplitude (~2.25vpp).  The same code I'm using works fine on a Xmega8E5 which produces a stable (enough) 32MHz clock.  Using DFLL against the internal 32KHz clock doesn't make a difference.  Is the internal 32MHz oscillator just hosed or is there anything I can do to fix it? Any troubleshooting tips?  Thanks!

 

I'm watching the clock on PC4 with the following:

PORTC_DIRSET = PIN4_bm;
PORTCFG_CLKOUT |= PORTCFG_CLKOUT_PC7_gc;
PORTCFG_CLKOUT |= PORTCFG_CLKEVPIN_PIN4_gc;

32MHz w/ DFLL code:

OSC.CTRL |= OSC_RC32MEN_bm | OSC_RC32KEN_bm;    /* Enable the internal 32MHz & 32KHz oscillators */
while(!(OSC.STATUS & OSC_RC32KRDY_bm));         /* Wait for 32Khz oscillator to stabilize */
while(!(OSC.STATUS & OSC_RC32MRDY_bm));         /* Wait for 32MHz oscillator to stabilize */
DFLLRC32M.CTRL = DFLL_ENABLE_bm ;               /* Enable DFLL - defaults to calibrate against internal 32Khz clock */
CCP = CCP_IOREG_gc;                             /* Disable register security for clock update */
CLK.CTRL = CLK_SCLKSEL_RC32M_gc;                /* Switch to 32MHz clock */
OSC.CTRL &= ~OSC_RC2MEN_bm;                     /* Disable 2Mhz oscillator */

32MHz via 8MHz PLL:

OSC.PLLCTRL = OSC_PLLSRC_RC8M_gc | OSC_PLLFAC2_bm;
OSC.CTRL |= OSC_PLLEN_bm | OSC_RC8MEN_bm;
while(!(OSC.STATUS & OSC_PLLRDY_bm));   /* Wait for PLL to stabilize */
while(!(OSC.STATUS & OSC_RC8MRDY_bm));  /* Wait for RC8 to stabilize */
CCP = CCP_IOREG_gc;                     /* Disable register security for clock update */
CLK.CTRL = CLK_SCLKSEL_PLL_gc;          /* Switch to PLL clock */

 

Last Edited: Sun. Sep 7, 2014 - 04:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you setting the DFLL COMP1-COMP2 register pair with the frequency multiplier 32 MHz / 1024 Hz = 0x7a12? 

 

This may be set automatically at reset, but I always set it myself.

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

steve17 wrote:

Are you setting the DFLL COMP1-COMP2 register pair with the frequency multiplier 32 MHz / 1024 Hz = 0x7a12? 

 

This may be set automatically at reset, but I always set it myself.

 

I'm not, but I'll inspect their default values tonight and try setting them manually.  I haven't had to do this on my Xmega8E5 chips.  Also, if I remove the DFLL configuration the results are the same, ~60MHz.  I only have two 32E5's on hand and will build another board up this evening.  I had been using 8E5's on these boards but need more memory now. 

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

For testing purposes it's probably better to not even use DFLL until you figure this thing out.  Without DFLL, the frequency should be in the neighborhood of 32 MHz with maybe a 5% error or so.

 

To get even this accuracy depends on the factory calibration of the oscillator's frequency adjustment registers.  I think they are called something like CALA and CALB where CALA is the fine adjustment and is set at the middle of the range of its 7 bit value.  In other words 0x40.  CALB is the course adjustment register.  I think it's 6 bits.  The correct value is determined in the factory and put in the Production Signature Row, A.K.A. Calibration row.  It should be automatically loaded at reset.

 

Actually I'm only familiar with the AU series but I guess the later series are similar.  They might have made some improvements in the later series.  Apparently they have also introduced some bugs in the silicon judging from some of the posts I've read.

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

Looks like something got screwed up in the factory calibration.  Soldered up another Xmega32E5 and it works fine.  On the borked one, I checked OSC.RC32KCAL and it was 0xFF.  I switched to the 32KHz clock and it was running at 53.19KHz.  I then disabled the 32KHz clock all together and with no DFLL, it was running at 75MHz off the 32MHz oscillator.  I then set RC32KCAL to 0x5D (value pulled from my other 32E5) and it runs at 32.26KHz. I then set DFLLRC32M.CALA and CALB to values pulled from the other 32E5 and tried the 32MHz oscillator again.  This got me in the ballpark at 31.25MHz w/ DFLL.  I checked the comp values as well and they were already correctly set.  Seems like I figured out the problem, now I just need to figure out how to properly calibrate the clocks.  Surely there's an appnote on it :)

Last Edited: Tue. Sep 9, 2014 - 01:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting, seems the choices are either Atmel forget to calibrate that single part, or somehow it erased later.

Do they have the same date codes ?

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

You shouldn't have to calibrate clocks.  Normally the 32 kHz clock has less than 1% error which is more than accurate enough for USB, USART, etc.

 

I would think the chip that has 0xFf for OSC.RC32KCAL would be considered defective and could be returned to wherever it came from.  Atmel might be interested in what you found.

 

If the only problem is the lack of factory calibration, you could  fix that.  Figure out what the RC32KCAL should be by trial and error, and stick it in appropriate osc. register.  If I remember correctly, you should be able to set the frequency correctly to within 0.25%, if you are a perfectionist.  There is another complication of course.  You would want to store that value somewhere on the chip, either in EEPROM or the User Signature Row.  Unless you are set up to do that, it is a bit of a pain in the ass.

 

Apparently the factory calibration for the 32 MHz oscillator is wrong too.  I'm guessing they are also 0xFF.  It looks like the only RC oscs. that got calibrated are the 2  and 8 MHz ones.  By the way the AU series doesn't have an 8 MHz osc.

 

So if you want to fool with it, you could figure out what the calibration values should be and save them somehow, or toss the chip, or return it.  Anyway with 2 clocks working and with PLL working, you may have more clocks than I would know what to do with.

 

Getting the 32 kHz osc. working, and I guess you have it running accurate enough for most things already, using it for a DFLL reference rather than running the other oscs. without DFLL would give more frequency stability with large temperature and voltage changes.  At least I think the 32 kHz oscillator is more stable than the others.

 

 

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

I'll check the date codes tonight.

 

I'll fiddle around when I get time and see if I can get the 32kHz oscillator calibrated.  Are the cal values for the 32MHz oscillator accessible?  I didn't see them, just the DFLL cal values.  I'd be interested to know what its set at.  I found this as well: AVR1606 - XMEGA Internal RC Oscillator Calibration.  Haven't had a chance to look at the code yet, but could be what I need.

 

I had been using the USART at 460,800 via RS485 on these same boards off the DFLL 32MHz oscillator, using the internal 32kHz as a reference.  This has been working fairly well for me, but I'll move to a crystal in the next revision as I want to get around 1Mbps.  I'm building just a few of these things and have more 32E5s on the way.  I'll gather more data and contact Atmel about it, maybe they'll want it for analysis and send me some chippies.

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

sporadic wrote:
  Are the cal values for the 32MHz oscillator accessible?
I think you already found them.  The registers appear in the DFLL section but they are actually the osc. coarse and fine adjustment registers.  Strange but true.

 

The factory calibration values are right after the 32kHz calibration in the Production Sig Row, at least for my AU chips.

 

Notice the CAL A value is 0x40 in the middle of the range.   When the DFLL is enabled, it will constantly check to see if the osc. is running faster or slower than the desired multiple of the 32 kHz osc. and it will increment or decrement the CAL A (fine adjustment) value accordingly.  The DFLL only tweaks the fine adjustment.  You have to get the course adjustment in the ball park.

 

Note, neither the calibrate registers nor the compare registers can be changed by software when the DFLL is enabled.

Attachment(s): 

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

steve17 wrote:

 

sporadic wrote:

  Are the cal values for the 32MHz oscillator accessible?

I think you already found them.  The registers appear in the DFLL section but they are actually the osc. coarse and fine adjustment registers.  Strange but true.

 

 

The factory calibration values are right after the 32kHz calibration in the Production Sig Row, at least for my AU chips.

 

Notice the CAL A value is 0x40 in the middle of the range.   When the DFLL is enabled, it will constantly check to see if the osc. is running faster or slower than the desired multiple of the 32 kHz osc. and it will increment or decrement the CAL A (fine adjustment) value accordingly.  The DFLL only tweaks the fine adjustment.  You have to get the course adjustment in the ball park.

 

Note, neither the calibrate registers nor the compare registers can be changed by software when the DFLL is enabled.

 

Ahhhh.. I completely missed that and didn't even check signatures with the programming tool.  RCOSC32K, RCOSC32M, and RCOSC32MA are all set to 0xFF on this borked chip.  Date codes match and lot numbers are the same, but different wafers.

Borked 32E5 Oscillator Cals by smerrick, on Flickr

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

Interesting that you can "calibrate" the 32MHz osc all the way up to 60. Does the chip work so ridiculously overclocked, or is that how you discovered the problem?

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

It doesn't surprise me much.  In the AU series the 32 MHz osc. is designed to run at 48 MHz.  The AU has USB and to use full speed USB the USB hardware needs a 48 MHz clock. 

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

Torby wrote:

Interesting that you can "calibrate" the 32MHz osc all the way up to 60. Does the chip work so ridiculously overclocked, or is that how you discovered the problem?

Its how I discovered it. Operation was very sporadic, not even able toggle a pin at times.

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

You could report your chip to Atmel by logging in to their website and opening a support case.

 

Not having valid frequency calibration must make for a lot of unhappy customers.

 

I find it interesting that your chip does have calibration for the DAC and temperature sensor.  I don't think the AU chips ever have that.  Those values are all 0xFF on my AU chips.  I was under the impression that if you wanted to use DAC you calibrated it yourself.  That's what I do.

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

steve17 wrote:

You could report your chip to Atmel by logging in to their website and opening a support case.

 

Not having valid frequency calibration must make for a lot of unhappy customers.

 

I find it interesting that your chip does have calibration for the DAC and temperature sensor.  I don't think the AU chips ever have that.  Those values are all 0xFF on my AU chips.  I was under the impression that if you wanted to use DAC you calibrated it yourself.  That's what I do.

 

I submitted one this morning, will see what they have to say.  Thanks!