xmega256a3u RTC divide external oscillator by 32 cold issue

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

We have a design that uses the xmega256a3u and a 32.768 kHz external oscillator.  What we have noticed is that on about 10% of the chips if you use the RTC divide by 32 to reduce the oscillator to 1 kHz, and then run at low temperature the RTC is very unstable.  However, if you do not divide by 32 then the RTC is very stable at low temperature.

 

We are not running the oscillator in low power mode, that just makes things worse.

 

Anyone observed anything similar?

 

Still doing testing to try and see if it is just the RTC or if there is some instability in the crystal.  Initial testing shows the the system clock running at 32 MHz is very stable using the external oscillator as calibration.

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

What is your low temp?  How does that compare to temp range of the components?

I've had mega's to -40C and still working, most stopped working as temp neared -50C.

 

Jim

 

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

We are doing some freezer tests so more like -20C at the lowest...  We only see it on about 10% of the U modules...

 

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

You description of the situation and symptoms is a bit unclear to me. 

 

1) Are you using a true "external oscillator" or it just a crystal? (some people call crystals "oscillators" even though they are not)

 

2) This "RTC" - is it part of this external oscillator or is it internal to the Xmega?

 

3) Likewise, the divide-by-32 - is it part of the external oscillator or is it internal to the Xmega?

 

4) What defines "unstable"? Does it drift? Does it miss counts? What is actually happening?

 

5) How do you know that it is the RTC that is unstable vs the oscillator being unstable?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Feb 13, 2017 - 09:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) The crystal is a 32.768 kHz on the TOSC pins.

2) The RTC is the 16 bit internal xmega RTC, that can be set using the divide by 32 and/or a prescaler 

3) Divide by 32 is internal to the xmega.

4) If you watch the RTC on one of the XMEGA pins, or using the RTCOUT pin (PORTCFG.CLKEVOUT |= PORTCFG_RTCOUT_bm;) you will see substantial change in the output frequency (instead of 1 kHz output you will see variations down to 100 Hz).  No such variation is observed if you don't divide by 32.

5) I "suspect" that the divide by 32 circuit is unstable because if I do a comparison of two pins, one running off the RTC and one running off a timer/counter (using the 32 kHz as a calibration source) there is no variation in the timer/counter as temperature changes only in the RTC.

 

 

 

Last Edited: Mon. Feb 13, 2017 - 10:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great - 

 

Then we can conclude that there is no external oscillator. That DOES make a difference.

 

Can you pipe the prescaler output to a port pin? That ought to tell, pretty definitively.

 

It is a bit surprising that just the prescaler would be temperature sensitive on that MCU. Certainly, the transistor design rules must be pretty consistent across the chip (low power oscillator being a definite exception). Of course, slip-ups are always possible. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

We have done a comparison were we divide the 32.768 kHz by 32 and then leave the prescaler at divide by 1, thus we get 1.024 kHz output and I have that trigger an external pin every millisecond (this is the heartbeat of our simple RTOS).  Then compare that to the timer/counter firing at 1 ms as well.  As you cool the board you can see the RTOS fluctuations.

 

I don't completely rule out the crystal as the problem, but I would have expected it to effect the system clock as well, but maybe the limited swing of the DFLL masks the problem.

 

Last Edited: Mon. Feb 13, 2017 - 10:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

photonthunder wrote:
We are not running the oscillator in low power mode, that just makes things worse.
Is the XMEGA directly powered via a cell or battery?

Reasons :

  • Power is proportional to the square of the voltage and to the frequency
  • Oscillator jitter (phase noise) is proportional to power supply noise
  • Regulators are (usually) conditionally stable

http://www.atmel.com/Images/Atmel-8386-8-and-16-bit-AVR-Microcontroller-ATxmega64A3U-128A3U-192A3U-256A3U_datasheet.pdf

(page 140)

The maximum CPU clock frequency depends on VCC.

Safe Operating Area

http://www.atmel.com/devices/ATXMEGA256A3U.aspx?tab=documents

...

AVR1012: XMEGA A Schematic Checklist
(file size: 333642, 17 pages, revision B, updated: 03/2010)

This application note describes a common checklist which should be used when starting and reviewing the schematics for a XMEGA A design.
http://www.atmel.com/Images/doc8278.pdf

(page 2)

3. Wire wound inductor should be added between the external power and the VCC for power filtering.

 

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

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

Interesting.     I think you can use the prescaler  of the RTC to divide the clock by 32 instead of that divide by 32 clock output thing.  If that works okay, that should tell you the divide by 32 clock output thing is the culprit.

 

I stuck my Xmega in the freezer and am monitoring the RTC clock frequency on pin C6.  I'm using the internal 32kHz RC osc. with the divide by 32 thing in my 128A4U chip.  The frequency is still 1026 Hz.  It hasn't changed more than one Hz. from room temperature.   That RC osc. is not your father's RC osc.. smiley

 

The DFLL also uses the 32 kHz clock divided by 32.  I don't know if it is the same divider that is failing.  If it is, that would screw up the 32 MHz or 2 Mhz rc osc. that use DFLL.

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

Thanks for the thought.  At one point to try and minimize sleep current we would reduce the voltage to 1.8 V and the system clock to 2 MHz when we slept.  Eventually learned the savings wasn't worth the effort of the added circuitry.  

 

We do run off D batteries or solar panels for this application and the design was done in partnership with another company that is also looking into the problem.  Some older posts do make suggest that the divide by 32 circuit connected to the internal 32 kHz oscillator is suspect (http://www.avrfreaks.net/forum/atxmega128a1u-32768-khz-rtc-problem?skey=xmega%201kHZ%20not%20switch%20to%2032%20kHz) and thus I was curious if this might be a related issue.

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

I think because of the divide by 32, the prescaler in the U version does not include 32 as an option (just 1,2,8,16,64,256,1024).  We have tried some initial experiments using an RTOS "heartbeat" of 0.5 ms (divide by 16) and it appears stable but will take some work to tweak code that relied on a 1 ms heartbeat.

 

We are in the process of testing our supply of boards and we are only seeing this on about 10%...

 

I did just read this in the manual (P.22):  "A calibration feature (DFLL) is available, and can be used for automatic run-time calibration of the internal oscillators to remove frequency drift over voltage and temperature. An oscillator failure monitor can be enabled to issue a non-maskable interrupt and switch to the internal oscillator if the external oscillator or PLL fails."  

 

I make sure it is clear before starting the DFLL, but I don't check to see if it has failed...

Last Edited: Tue. Feb 14, 2017 - 01:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've wondered about the divide by 32 before feeding the RTC.   The RTC has a prescaler that can do the dividing.  I'm thinking it's a special low power divider to help reduce the power when sleeping and only the RTC is running.  Maybe they pushed the limit on a low power divider so it's on the verge of failing at low temperature.

 

 

 

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

photonthunder wrote:
I don't completely rule out the crystal as the problem, but ...

FAQ: How to choose a crystal for my application?

http://atmel.force.com/support/articles/en_US/FAQ/How-to-choose-a-crystal-for-my-application

How to choose a specific crystal for my application? Does Atmel recommend specific crystals? Can you confirm whether crystal "XYZ" works with my AVR device?

...

... Atmel does not recommend specific crystals.

 

We recommend proper testing and characterization to ensure proper robustness in the end application.

As a starting point, the safety factor described in chapter 4.2 in AVR4100 should be measured.

...

 

 

More :

http://atmel.force.com/support/articles/en_US/FAQ/Using-crystals-and-ceramic-resonators

 

The oscillator safety factor is likely temperature dependent (gain is temperature dependent)

Maybe a resonator would be more robust though less accurate than a crystal.

 


http://www.atmel.com/devices/ATXMEGA256A3U.aspx?tab=documents

...

AVR4100: Selecting and testing 32kHz crystal oscillators for AVR microcontrollers (file size: 1MB, 24 pages, revision E, updated: 03/2015)

This application note summarizes the crystal basics, PCB layout considerations, and how to test a crystal in your application. A crystal selection guide shows recommended crystals tested by experts and found suitable for various oscillator modules in different Atmel® AVR® families.
http://www.atmel.com/Images/doc8333.pdf

http://www.atmel.com/images/AVR4100.zip

Edit : AVR4100.zip URL

 

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

Last Edited: Thu. Feb 16, 2017 - 02:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

photonthunder wrote:

I think because of the divide by 32, the prescaler in the U version does not include 32 as an option (just 1,2,8,16,64,256,1024).

Aha.  I see that now. 

 

photonthunder wrote:
  We have tried some initial experiments using an RTOS "heartbeat" of 0.5 ms (divide by 16) and it appears stable but will take some work to tweak code that relied on a 1 ms heartbeat.

I use an RTC overflow interrupt for my periodic stuff.   My Xmega is lazy.  It gets an interrupt at 2 Hz.   I played around with it.   I can get the same periodic interrupt frequency by eliminating the divide by 32 thing, changing the RTC prescaler from /2 to /16, and using an overflow period 4 times what I did previously (changed period from 0xff to 0x3ff).

 

Of course your interrupts happen much faster.  I don't know if you can get rid of the clock /32 thing and still have the same interrupt frequency.

 

 

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

Have you measured how marginal your 32kHz clock is? I had some similar issues ages ago and found that the crystal was on the limit. gchapman linked to the Atmel document that covers testing.

 

Have you tried using the RTCCTRL to scale to 1024Hz, rather than the prescaler in the RTC itself?

 

The other tip I would offer is to look at 32.768kHz oscillator modules. They don't cost much but they are laser trimmed at the factory and have been fully tested for stability over temperature range and the like.

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

Thanks for the feedback it is always helpful to see things from new perspectives.

 

I was hoping that the problem would be more on the software end, some feature that I had forgotten to turn on or off (like setting the crystal in low power mode).

 

RTCCTRL scale to 1024 Hz is the divide by 32 circuit that I have been referencing.

 

mojo-chan, you may not recall but when you saw the similar issue was it only manifesting on the RTC and not visible on the system clock?

 

Another thing I am interested to try is to check the oscillator failure bit (OSC.XOSCFAIL & OSC_XOSCFDIF_bm).  That should give me a better feel if it is the divide by 32 circuit or the crystal.

Last Edited: Tue. Feb 14, 2017 - 05:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was only the RTC that was affected, but I was not using the 32kHz clock for the CPU. I'm not sure if the clock failure monitor works with 32kHz clocks because my understanding is that it checks each clock source against the ULP. Since the ULP and the 32kHz external clock are so close to each other it doesn't work... It's in the documentation somewhere, sorry I don't recall where.

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

Thanks for the insight,

 

The crystal we are using is the ECX-31B which has an extended temperature range and "should" only vary in the ppm range.

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

Dividing the 32 kHz clock by 32 without using the clock's divider is easy.  I'm getting a 1024 Hz interrupt by  setting the RTC prescaler to divide by 2, and setting the RTC period to 0x0f, and using the overflow interrupt.

 

 

 

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

I am almost certainly wrong but the way I read the 2 docs recent;y posted sugests to me that your systems are actually using the internal 32mhz rc oscilator & not the external crystal you think you are using

 

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

steve17: Thanks for the suggestion and I do think that would work.  We tried something similar where we used the divide by 16 and then did a divide by 2 on the rtos tick. Then to get full range we flipped the highest bit on overflow.

 

My main question at this point: Is it the divide by 32 circuit or is it the crystal with the error being "masked" by the system clock.

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

Yeah, actually as you know, there are a lot of combinations that can divide by 32.

 

From here, it seems that if you bypass that special low-power divide by 32, and instead use the RTC stuff, that should tell the story.  If it works at cold temperatures, I'd definitely suspect the special /32 stuff is bad.

 

The "system clock" is completely different from the RTC clock.  I don't see how the system clock can mask anything.  What you see on pin C6 is the output of the 32kHz module, either divided by 32 or not, your choice.

 

When I am using a crystal, which is seldom, I see the exact 32,768 frequency or 1024 frequency.  When I'm using the RC osc., I've never seen it exact.  It's always somewhere around 0.2% off.

 

If you see the /32 clock is bad but the undivided 32kHz clock is good, it sure seems like that divider is bad.

 

I don't think there is any way the 2 or 32 MHz RC clocks can affect the 32kHz clock.  The 32kHz clock can adjust the other RC clocks.  That's what DFLL is for.  It gives the lousy 2 and 32 MHz clocks the accuracy of the good 32kHz clock.

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

Another thing you might want to try, to convince the sceptics,  is to use the internal 32 kHz RC osc instead of the crystal.  If that fails too, then it's surely not the crystal. 

Last Edited: Tue. Feb 14, 2017 - 11:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the initial testing we did where we bypassed the low power /32 it did appear to function but we do need to do some more thorough analysis.  

 

My question though is what if there is a subset of crystals that are faulty at low temperature and low power.  It might manifest as the /32 being faulty.

 

I was hoping to find a way to identify using a timer/counter or similar to see if the 32 MHz clock becomes less accurate with a faulty crystal, but the variation may not be as drastic as it is on the RTC.

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

steve17, I missed your latest post with my response.  I want to rerun some test with the internal oscillator set as RTC, my recollection is a little vague on that particular test.  So is it safe to say that it is the same /32 that the external oscillator uses?

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

photonthunder wrote:

  So is it safe to say that it is the same /32 that the external oscillator uses?

I think so.  I doubt if anyone here could know for sure.  Somebody at Atmel should know.

 

I have a C++ module that uses a timer/counter to divide the PER/CPU clock down to a frequency my DMM can display.  It can put this clock on pin 0 or 4 of any digital port.  I can give that to you.   It might be useful.  No guarantees. 

Last Edited: Wed. Feb 15, 2017 - 01:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

photonthunder wrote:

Thanks for the insight,

 

The crystal we are using is the ECX-31B which has an extended temperature range and "should" only vary in the ppm range.

 

It says "operating range" in the datasheet, but "operating" can mean just barely oscillating, and only under ideal conditions. Unfortunately it's not easy to tell, you would need a near field probe or maybe a 100x probe to really see it.

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

I experimented with two "suspect" boards and observed that if I put the crystal in low power mode (OSC_X32KLPM_bm) then I would see variation on the RTC output even at room temperature.  I do not see this variation on "good" boards.

 

On one "suspect" board with high jitter on RTC output I also get gibberish out my serial debug port.  Switching the DFLL to the internal oscillator, while leaving the RTC external, it will fix the serial output while still experiencing RTC jitter.

 

Switching the RTC to internal oscillator and leaving the DFLL connected to the external results in no jitter and no gibberish on the serial port.  I was surprised that serial was fixed by connecting the RTC to internal, any insights?

 

We are going to try swapping crystals and see if it is indeed the problem.

 

 

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

photonthunder wrote:

Switching the RTC to internal oscillator and leaving the DFLL connected to the external results in no jitter and no gibberish on the serial port.  I was surprised that serial was fixed by connecting the RTC to internal, any insights?

Maybe when the RTC and the DFLL are both sucking clocks from a weak crystal osc., they both have problems.  When the RTC uses a different clock, the crystal osc. has enough power to drive the DFLL. 

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

Another interesting observation, if you monitor the RTC output line at room temperature you see the jitter around the 1.024 kHz range.  Cooling the module using dust spray, a very scientific method of course, you can get it to lock in at 2.048 kHZ with no visible jitter.  As it warms back up then the jitter will return.  I am told these crystals have harmonics and that we might be entering one...

 

Also, a quick crystal swap of a "suspect" board and a "good" board and the jitter remained with the suspect board and not the crystal.  I am starting to wonder if when running in low power mode, because of the /32 the crystal is on the power edge.  When you turn on the low power bit of the crystal as well then it throws it over the edge?

Last Edited: Thu. Feb 16, 2017 - 12:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

photonthunder wrote:
When you turn on the low power bit of the crystal as well then it throws it over the edge?
Maybe

From a partial read of the XMEGA test results in AVR4100 :

  • low power can be functional and, IIRC, with enough safety factor
  • some crystals will not work but there were retests to find one that did
  • the test equipment and setup is fascinating especially in variety; crystal manufacturers have different takes on testing
  • some testing across nearly the entire industrial temperature range
  • recommendations on PCB layout and crystal oscillator loading

The crystal manufacturers with XMEGA test results (may have missed one or two) :

  • Citizen Finetech Miyota
  • Fox Electronics
  • Micro Crystal Switzerland
  • Seiko Instruments

Atmel would send an XMEGA QFP (64 leads or 100 leads) on a custom breakout, similar to below, to a crystal manufacturer for testing.

SparkFun Electronics, ATxmega128A1 breakout, retired product

A STK600 socket board is not what was used.

Atmel STK600 socket card for QFP 64 pin 0.8mm pitch

The AVR4100 firmware is simple with C source code in IAR EW AVR projects.

Do you want to perform AVR4100 crystal robustness testing?

 

O.T.?

Is the XMEGA lot and production date printed on the bottom of the package?

photonthunder wrote:
Cooling the module using dust spray, a very scientific method of course, ...
... but relatively safe.

A Fluke 59 IR temperature meter is inexpensive; use it or similar to calibrate the XMEGA's internal temperature sensor for -20C.

Could replace the spray with dry ice in an anti-static bag, but there's a safety concern for dry ice due to freeze burns.

 


http://www.avrfreaks.net/forum/xmega256a3u-rtc-divide-external-oscillator-32-cold-issue#comment-2086426

https://www.sparkfun.com/products/retired/9546 (SparkFun XMega100 Breakout, Retired)

https://www.olimex.com/Products/AVR/Header/AVR-HX128-A1/ (Olimex ATxMega128A1 header board with JTAG)

http://www.atmel.com/tools/stk600-tqfp64.aspx

http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyFLUKE-59MAX+-NA

 

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

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

It looks like the board is the problem.  It could be the chip, of course.  I don't know anything about crystal oscillators, but I'd also be suspicious of the capacitors in the circuit.  Maybe the power supply too.

 

I've also had problems with flux on the board.  It can provide a conductive path between adjacent pins that can affect the circuit if the pins are high impedance.  The conductance depends on moisture absorbed from the air which depends on the relative humidity of the air which depends on the temperature of the air.

 

The first time it happened,  I hadn't cleaned the flux from the board.  The second time, I was using a QFN (pinless) chip and the flux was hiding under the chip. I had to soak the board in flux remover to fix that one.  Neither problem had to do with a crystal oscillator.

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

steve17 wrote:
I've also had problems with flux on the board.  It can provide a conductive path between adjacent pins that can affect the circuit if the pins are high impedance.  The conductance depends on moisture absorbed from the air which depends on the relative humidity of the air which depends on the temperature of the air.
From AVR4100 :

(page 8)

3 PCB layout and design considerations

...

To increase the robustness of the oscillator, we recommend these guidelines during PCB layout:

  • ...
  • Shield the crystal and signal lines by surrounding it with a ground plane and guard ring.
  • ...
  • PCB cleaning is recommended to reduce flux residues from soldering.
  • ...
  • Dust and humidity will increase parasitic capacitance and reduce signal isolation, so protective coating is recommended.

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

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

That would be my concern as well, that I could do a test of the crystal and 90% of the time it would pass, so a test of this crystal would most likely result in Atmel approval.  I could switch to a new "approved" crystal and experience the same problem, especially if it is related to flux or other manufacturing defect.

 

Sounds like I better try to do some board analysis and see if I can fix the problem on a few of these boards.  Or better yet, have those with skills do the inspection/fix.

Last Edited: Thu. Feb 16, 2017 - 03:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

photonthunder wrote:

I experimented with two "suspect" boards and observed that if I put the crystal in low power mode (OSC_X32KLPM_bm) then I would see variation on the RTC output even at room temperature.  I do not see this variation on "good" boards.

 

That's what I saw on marginal boards too. It's most likely an issue with your PCB layout or soldering. We have seen cooked crystals behave this way too. It seems to be a combination of factors - marginal PCB layout, soldering, flux residue, variations in crystals... The only way to fix it is to make the layout more robust so it can cope with the other variations.

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

photonthunder wrote:
I could switch to a new "approved" crystal and ...

Or better yet, have those with skills do the inspection/fix.

There are no "approved" crystals; there are a relative few crystals that are known functional with XMEGA.

Likely the set of XMEGA-ready crystals is more than a relative few; some duds or marginals will be found.

The recommendation is to confirm the crystal oscillator safety factor for a specific XMEGA with specific crystals.

AVR4100 describes how to do this with a STK600.

An alternative is to use one of the several XMEGA breakouts, bring ground and a piece of double-sided SMT protoboard to the top of the XMEGA's package, lift TOSC1 and TOSC2 then bring both to the protoboard, etc

 

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

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

When they say "approved", they mean "known to work well if you lay your PCB out well and do a good job on the solder/cleaning".

 

That's another reason to consider using a module. For a few pennies more you get a laser trimmed board you can just solder down, eliminating most PCB layout issues because it has an on-board oscillator circuit and amplifier.

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

I like the suggestion of trying a module, it sounds like this XMEGA makes it a real challenge to get any crystal to function properly.  

 

Especially since our application is outdoors in extreme conditions.

 

Has anyone had success with an XMEGA in low power mode and /32 with a crystal?

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

It works fine for me in low power mode with a good PCB layout. However, low power mode only shaved nanoamps off so I decided to err on the side of caution.

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

Was that using a crystal or a module?

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

SMT crystal, I'll get the part number if you like but it was just a cheap one.

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

Thanks for the information, it is helpful.  Board design and layout is not what I do typically so I will share this information with those who do and get them to re-evaluate the design.

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

photonthunder wrote:
Has anyone had success with an XMEGA in low power mode and /32 with a crystal?
Maybe

1KHz XMEGA low power crystal is mentioned in the AVR4100.zip Seiko Instruments test report but the remainder of that report is 32KHz.

The other crystal manufacturers show XMEGA low power 32KHz.

 

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

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

Wanted to follow up.  Atmel (now Microchip) gave the following on a few boards we returned:

 

The clock glitch is caused by a marginally weak Internal decoupling on the XOSC32 circuit.

The glitch is caused by a combination of factors working together i.e customer particular application, interaction with the board (32Khz crystal), and the characteristics of a particular die, which, despite meeting datasheet specifications, appear to fall in the tail of distribution for certain parameters critical to this application.

The failure mode is classified as test coverage issue as the part did not fail and not being screened during production testing. 

 

The resolution is an additional post manufacturing test.  Thought it was worth sharing.

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

Thanks, that's extremely helpful.

Can I ask, what was the post-manufacturing test? I have a similar issue.

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

All it really says it that they implemented a new test procedure but no specifics other than the following:

 

The devices pass the ATE with the standard production test flow using the old test program version. However, bench test on one of the selected sample 3 showed spikes in the output frequency (in the MHz range) indicative of clock glitch. Waveforms from PC7, which is the clock output pin, showed anomalous behavior on the trailing edges of the pulse affecting the normal behavior of the Real Time Counter (RTC). 

 

The new test program was implemented and released to production under Change Release System (CRS#16-0420) 

 

We have implemented a test where we put them in a freezer overnight and then check the RTC output.  Makes it fairly easy to identify,  but open to other suggestions if there is something easier and more reliable.

 

 

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

Thank you again photothunder, that is really helpful. My hardware operates in low temperature environments, but there is a lot of it so getting it all in a freezer could be tricky, but definitely worth an experiment.