AVR Freaks

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 (https://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.

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.

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.

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.

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.

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?

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.

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?

Was that using a crystal or a module?

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.

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.

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.