Xmega RTC and external crystal

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

We just discovered that our external RTC, Maxim DS1374C, is not to be trusted in low temperatures. The internal clock divider of the RTC units fails for some units when temperatures falls below 0 C, which is verified by their support. Crazy, but a fact that we have to handle for our sensor boards that we manufacture. They say that it's probably a manufacturing error in their component.

 

So, we need to move away from using the external RTC to time our events. Specifically we need an accurate wake up interrupt every 24 hours as well as an interrupt to handle sampling of our sensors at 512 Hz. We have ween using the external RTC for both during the last few years, but now have to find a new solution. 

 

A nice alternative seems to be the internal RTC of the Xmega (we're using the Xmega 256a3). If we could use that we could fully eliminate the need for the external RTC. However, from what I understand it needs a 32 kHz crystal to clock it. Right now we only have a 4 Mhz crystal connected to the XTAL pins. Isn't there some way we could use that to clock the internal RTC? We use the PLL to clock the processor at 32 Mhz from the 4 Mhz clock today.

 

 

Best regards

Fredrik

 

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

Or you could add some heating to your existing solution, a temp sensor with a set point output bit and a resistor all encased around your rtc chip.

you did not say if this is a battery operated sensor? 

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

ki0bk: hehe, I like the innovative thinking, but unfortunately the sensor cards are installed in the ground for up to 10 years on a singe battery back. So, power consumption is quite critical.

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

zetter wrote:
However, from what I understand it needs a 32 kHz crystal to clock it.
or a 32KHz oscillator that's signal TOSC1 (pin PE7).

The following is temperature compensated up to an order of magnitude better than a crystal oscillator, has reasonable PSRR, an option covers the industrial temperature range, and consumes 1 micro-amp (typical) :

Abracon Logo

Abracon Products

MEMS Oscillators

kHz SMD

http://www.abracon.com/products.php?search=osc&type=MEMS&subtype=kHz%20SMD

ASTMTXK

...

0C to 70C, or, -40C to 85C

5ppm, 10ppm, or 20ppm

...

 

Edit : corrected URL

 

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

Last Edited: Mon. Jun 12, 2017 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A nice alternative seems to be the internal RTC of the Xmega (we're using the Xmega 256a3). If we could use that we could fully eliminate the need for the external RTC.

Are you using an ATXmega256A3 or the Xmega256A3U:

 

The A3U's RTC can be clocked by:

An external 32 KHz Xtal

An external clock signal

A 32 KHz Internal Oscillator

A 32 KHz Ultra Low Power internal oscillator, (which is less accurate...)

 

 

The 256A3 data sheet also shows the internal 32KHz Osc, and mentions it as a clock source for the RTC, and it is in the Xmega A manual.

So, I think it should exist in the chip, and be usable.

 

Have you tried configuring it?

(Enable it, wait for it to stabilize, select it as the RTC source, etc.)

 

To answer your specific question, I do not see a straight forward way to use the External (4 MHz Xtal in your case) clock as the RTC clock source.

 

(But it looks like you should be able to use the internal 32 KHz clock, without an external 32 KHz Xtal, so you should be back in business!)

 

JC

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

zetter wrote:

ki0bk: hehe, I like the innovative thinking, but unfortunately the sensor cards are installed in the ground for up to 10 years on a singe battery back. So, power consumption is quite critical.

 

On what planet?  Ok, just kidding,  in the ground but not below frost level?  Just trying to figure out how it gets to below 0 Celsius.....

 

What kind of sensor, earthquake, soil moisture, temperature?

Last Edited: Fri. Nov 11, 2016 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

zetter wrote:
However, from what I understand it needs a 32 kHz crystal to clock it.
or a 32KHz oscillator that's signal TOSC1 (pin PE7).

The following is temperature compensated up to an order of magnitude better than a crystal oscillator, has reasonable PSRR, an option covers the industrial temperature range, and consumes 1 micro-amp (typical) :

Abracon Logo

Abracon Products

MEMS Oscillators

  --  Temp. Compensated kHz

http://www.abracon.com/products.php?search=osc&type=MEMS&subtype=Temp.%20Compensated%20kHz

ASTMTXK

...

 

That's a cool part.

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

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

Thanks for the replies.

DocJC: I'm pretty sure we have switched to the AU in the latest batch of sensors (I have moved away from the manufacturing side lately, byt still jump when problems like this occur). I did read the text you are referring to, but none of those alternatives are temperature stable. As far as I understand, the external crystal option only allows for 32 kHz or a 1 kHz crystal. Have I misunderstood this? Can we use the 4 MHz crystal we have through the PLL to clock the internal RTC?

ki0bk:Quite often below frost level. During wintertime the sensors quite often report temperatures below -20C in some of the countries we install them. The batterypack is designed inhouse together with a cell manufacturer to allow for 10 years operation in the quite large temperature span we operate, and the sensors sleep most of the time, so not that much power is consumed per day.

 

 

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

I build similar products, sensors that live underground for 5-10 years running on batteries.

 

Did you calibrate the XMEGA's internal temperature sensor? There is a one point factory calibration at 85C, but to get any kind of accuracy you need to do at least one other point, ideally close to operating temperature. You might then be able to calibrate the internal 32kHz oscillator and get some kind of useful accuracy. How good do you need? 30 minutes a year might be possible that way, assuming your environment is similar to mine (utility pits) where temperature changes are relatively slow.

 

To calibrate the 32kHz RC oscillator, I'd suggest doing a factory calibration against an accurate reference (say 10MHz) and then using a lookup table based on the temperature profile given in the datasheet. You could also try to do runtime calibration by comparing it to the 4MHz clock.

 

Perhaps you could characterize the DS1374C below 0C and compensate for its error too.

 

The best option from a timing accuracy point of view would be to make a little carrier PCB that matches the footprint of the DS1374C, stick a proper TCXO on it and attach that.

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

The RTC of the ATxmega256A3U  can select between these inputs: ULP (internal low power 32kHz osc), internal 32kHz, external 32.768kHz crystal on TOSC pins or external clock input on TOSC1. So neither the 4MHz crystal nor the PLL can be fed into the RTC unfortunately.

 

However, one possibility could be to use the internal 32kHz RC osc as source for the RTC, and periodically wake up and do a calibration of the internal 32khz against your 4MHz crystal. The internal 32kHz can be calibrated through the RC32KCAL register. You can see a typical characteristics over voltage and temperature of the 32kHz in Figure 37-318 in the datasheet, a run-time calibration should be able to improve this.

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

One thing about calibrating the RC32K oscillator though, the resolution of the calibration register is rather low. You won't get good results over a number of sample devices unless you do some dithering. It's not terribly hard, although there is of course a cost in terms of energy consumed, but I did something similar on a 10 year battery life product.

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

Thanks for the suggestion. We have considered calibrating the internal oscillator, but I don't think it's worth the complexity. Sounds like our best choice is to either replace the DS1374C for another RTC or adding a 32 kHz crystal to clock the internal one. I guess it comes down to wether the internal RTC can provide the same low power consumption in sleep modes as the external one, which I haven't really read up on yet.

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

zetter wrote:

Right now we only have a 4 Mhz crystal connected to the XTAL pins. Isn't there some way we could use that to clock the internal RTC?

....

 Specifically we need an accurate wake up interrupt every 24 hours as well as an interrupt to handle sampling of our sensors at 512 Hz. We have ween using the external RTC for both during the last few years, but now have to find a new solution.

....

Thanks for the suggestion. We have considered calibrating the internal oscillator, but I don't think it's worth the complexity.

 

Depends on how often you wake to 4MHz, and how much time you run for ?

ie There are systems that improve on classic/poor  32.768kHz Crystal tempcos, by running a higher Xtal in bursts, and calibrating a internal RC osc.

This also assumes you can capture from the 32kHz signal

 

Obviously, you need at least one full cycle at 32kHz and at 4MHz you resolve that to one part in ~122, which is not great.

To get to a measure precision of 100ppm, you need a 4MHz run time of > 82 RTC cycles, or 2.5ms, or 0.1% is ~ 244us   - How much do you need ?

 

You then try to do that calibrate as infrequently as you can, to save energy - eg 2mA  added for 2.5ms every 25 seconds, adds 0.2uA to your power budget. (2m*(2.5m/(25))  = 2.0e-7)

You are lucky, your temperature slews will be very slow.

 

 

It is not needed to trim the RTC-RC, as that may actually complicate the long-term maths, you just need to arrange the time to the next measure cycle, and total that in SW.

If you want that 512 sps to be a correct average, then you would derive a fractional swallow rate - eg 64/65 or 63/64 (etc) from ~32kHz, and the ratio of 64:65 sets the long term average.

eg a Swallow NCO running at 16b fractional part, 32kHz to 512Hz, I make has a LSB step precision of  0.238ppm, way better than that 2.5ms capture precision.

 

zetter wrote:

Sounds like our best choice is to either replace the DS1374C for another RTC or adding a 32 kHz crystal to clock the internal one. I guess it comes down to wether the internal RTC can provide the same low power consumption in sleep modes as the external one, which I haven't really read up on yet.

You could do a band-aid for existing products of a hybrid, that checks for external RTC and uses internal if it is missing.

If doing a new PCB, I'd allow footprints for a choice of  a RTC crystal, or one of those new 32kHz oscillators mentioned above.

 

zetter wrote:

We use the PLL to clock the processor at 32 Mhz from the 4 Mhz clock today.

Just noticed that, - that improves your capture by a factor of 8, so one RTC cycle is one part in 1024, and ~100ppm needs 10 RTC Cycles capture-time, for 102ppm result.

34 Cycles capture gives a 15b result, for 30ppm LSB and ~1.04ms required capture time.

Last Edited: Mon. Nov 14, 2016 - 08:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ivarho wrote:

The RTC of the ATxmega256A3U  can select between these inputs: ULP (internal low power 32kHz osc), internal 32kHz, external 32.768kHz crystal on TOSC pins or external clock input on TOSC1. So neither the 4MHz crystal nor the PLL can be fed into the RTC unfortunately.

Why wouldn't that work? You can use XTAL1 and 2 for the crystal, enable clock output and feed it back to TOSC1. The problem is that you need to keep the 4 Mhz oscillator running at all times, Standby mode allows keeping the main clock running while power save mode keeps the RTC running. 

Last Edited: Tue. Nov 15, 2016 - 09:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to be clear - is this something that has to be a software only change as the existing design cannot be modified in any way? Or can components be changed/added? (the most obvious change obviously being to simply replace the faulty Maxims!)

 

If no hardware changes are allowed a lot of the traffic in this thread becomes irrelevant.

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

The OP doesn't say what battery they have, but for example if it was a lithium AA with around 2000mAh capacity the device needs to average around 20uA to achieve a 10 year lifespan. Of course your idle current should be lower, so that you have some available for when you need to wake up and take measurements or transmit data. I'd aim for under 5uA, so clearly anything that involves running fast clocks or being in anything but the deepest sleep modes isn't going to work.

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

oczocz: interesting, is that something that can be achieved in SW?

 

clawson: we can do both SW and HW changes, but prefer as little HW changes as possible.

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

zetter wrote:
but prefer as little HW changes as possible
The is replacing the faulty RTC not the obvious?

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

Sure, but I guess using the internal RTC would be better in the long run as it requires less parts and is faster to access. And also, there is the whole process of finding a new RTC and making sure it works as intended.

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

We found that very small TCXOs can have supply issues too... Mouser seem to buy reels, but the lead times when they run out are long and if you go direct to the factory the MOQs are high. In the end we had two footprints on the board allowing five different TCXOs to be fitted, so we are protected if is unavailable or turns out to have issues like the OP's.

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

oczocz wrote:

ivarho wrote:

The RTC of the ATxmega256A3U  can select between these inputs: ULP (internal low power 32kHz osc), internal 32kHz, external 32.768kHz crystal on TOSC pins or external clock input on TOSC1. So neither the 4MHz crystal nor the PLL can be fed into the RTC unfortunately.

Why wouldn't that work? You can use XTAL1 and 2 for the crystal, enable clock output and feed it back to TOSC1. The problem is that you need to keep the 4 Mhz oscillator running at all times, Standby mode allows keeping the main clock running while power save mode keeps the RTC running. 

 

Good point, I did not think of that. However, as you point out, you will need to run the main clock, which in turn means higher power consumption.

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

5ppm 32768Hz, 2micro-amp max, industrial temperature range :

Ecliptek

EMTB83 Series Oscillator

http://www.ecliptek.com/oscillators/EMTB83/

Temperature Compensated MEMS Clock Oscillators TCMO LVCMOS (CMOS) 3.3Vdc 4 Pad 0.8mm x 1.5mm Chip Scale Package (CSP)

via

http://www.mouser.com/new/ecliptek/ecliptek-emt-oscillators/

Other supply voltages are available (up to 3.3V)

 

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

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

Once again, thanks for all the suggestions. We have, partly due to other factors, decided to go with a hardware update.
 

Now we need to decide on the optimal clock/crystal setup. As stated earlier, we use a 4 Mhz crystal connected to the XTAL pins for the CPU clock and an external RTC module (DS1374) for wake-ups every 24 h, keeping track of timestamps, as well as event timing today. The plan is to switch to the internal RTC in the Xmega for this instead. My initial thought was to find one awesome watch crystal (very accurate freq, low drift, cost not that critical) to use for both the internal RTC and the CPU, thus also getting rid of the external 4 Mhz crystal we use today. It seems unnecessary to have two crystals. However, it's not obvious to me how, or even if, this would work. 

Clocking the internal RTC from an external watch crystal connected to the TOSC pins seems pretty straight forward. However, it's not obvious to me if this crystal also can be used as a source for the CPU clock.The "AVR1003: Using the XMEGA Clock System" says "The Real-time Counter Oscillator can be used as a system clock source" (2.2 External Clock Sources). However, the maximum multiplication factor in the PLL is 31x, which would only give us a ~1 Mhz F_CPU. We would prefer being able to keep running at 32 Mhz, as we do today.

Another option seems to be to use the internal 32 MHz ring oscillator with the automatic runtime calibration with the external 32 Khz watch crystal as a source. The same document as referenced above states "The XMEGA Clock System provides two Digital Frequency-locked Loops (DFLLs), one for the 2 MHz RC oscillator and one for the 32 MHz ring oscillator. The DFLLs can be configured individually to use either the internal 32 kHz RC oscillator or an external 32 kHz watch crystal as a reference for the calibration process.", which seems promising. Automatic run-time calibration is however new territory for me. 

Have anyone here tried any of the above? Any thoughts on a good setup (now that we can design the clock stuff from scratch) for high CPU freq, accurate timing and low power consumption? Keeping the CPU clock accurate is quite important for use, if nothing else, to ensure low error rates on communication with other modules on the card via USART, SPI and I2C.

 

 

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

Hello zetter,

 

I apologize for breaking into this thread.   As i read this thread I became more curious of the application than your question (sorry, but I would not have been much help anyway as I am reading to learn).

 

If it's not a problem for you can you share how you get the data from such an underground sensor?

 

Thank

BR

 

JohnRob

 

 

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

Hi JohnRob,

no worries. The application varies somewhat depending on project/customer, but the general platform we develop is used for collection of sensor data and analyzing it in the cloud. How the data is moved to the cloud also varies depending on the project requirements. Some of our sensors have an integrated 2G/3G modem while some have an ethernet-connection.

 

 

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

zetter wrote:
Have anyone here tried any of the above?
Apparently yes for DFLL per the XMEGA A3U datasheet for the 32MHz internal oscillator :

Table 36-100. Current consumption for active mode and sleep modes.

...

DFLL enabled with 32.768kHz int. osc. as reference

zetter wrote:
Any thoughts on a good setup (now that we can design the clock stuff from scratch) for high CPU freq, accurate timing and low power consumption?
"Two out of three ain't bad"

DFLL consumes nearly 200microA for the 32MHz oscillator.

zetter wrote:
Keeping the CPU clock accurate is quite important for use, if nothing else, to ensure low error rates on communication with other modules on the card via USART, SPI and I2C.
Don't need accuracy, other than jitter (phase noise), when the signal set includes a clock (USART, SPI, TWI) but may need some accuracy for UART.

Internal MHz oscillators can be calibrated to 0.2% plus about 0.5% for temperature (total of 7000ppm)

Might be better to use SOF to sync the internal UART to an external UART (ideally external has the more accurate clock); similar is used for USB.

If able, replace a UART with USB.

 

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

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

gchapman, do you mean the fact that the data sheet states that it's possible? If so, I have found some worrying threads in various forums where people seem to have problems related to this, that's why I wanted to make sure at least someone has done this successfully in practice before we design a card with the setup.

 

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

Sorry, I don't have a good answer for you, I've not used the DFLL's on the Xmega.

 

That said, do your original PCB's use the X256a3 also?

Clearly it would make sense to install the 32 KHz xtal and test out the DFLL function before you spin a new board!

 

Unfortunately, it appears that there is an Xplained Demo PCB for the Xmega A3BU, but not for the Xa3, or you could simple order one to test out that capability, as an alternative.

 

Although all of the Xmegas are very similar, don't forget to look at the Errata section of the data sheet to make sure that there isn't a known problem (hardware bug) with a given feature, if that feature is critical to your project.

 

JC

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

zetter wrote:
do you mean the fact that the data sheet states that it's possible? ...
Yes and now see your concern.

zetter wrote:
... before we design a card with the setup.
Could do as Atmel at the time did for the XMEGA 32KHz crystal oscillator testing where a QFP XMEGA was in a simple breakout that was delivered to several crystal manufacturers for their testing.

Or, use an off-the-shelf XMEGA board for evaluating DFLL.

One of several :

MattairTech LLC

MattairTech

MT-DB-X3 Atmel AVR XMEGA 64-pin A3U / A3BU / C3 / D3 USB development board

https://www.mattairtech.com/index.php/development-boards/mt-db-x3-atmel-avr-xmega-64-pin-a3u-a3bu-c3-d3-usb-development-board.html

In addition to bench testing and proof-of-concept, such can be used for the first prototype.

 

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

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

Thanks for all the suggestions. Are there any Atmel engineers in these forums these days? Maybe they could give a definitive answer to this? If not, we'll go ahead with the prototype based on a 32 kHz clock crystal for DFLL runtime calibration and hope for the best.

Somewhat OT, but we also decided to have a look at our current storage solution, SD-card with SPI interface. It would be convenient to have the storage in an IC rather than inserting a card to each product before shipment. I had a quick look at eMMC, which seems to fill our requirements regarding power, speed and temperature ranges. But, they do not seem to support SPI anymore. Has anyone used eMMC with an Xmega successfully here?

 

 

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

TCXOs are really cheap now. I've been using EME32T3 which are only €0.70 in smallish quantities. At this point I view crystals as an ultra low-cost "better than nothing" option.

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

I am currently using an external 32kHz crystal and DFLL with the 32 Mhz ring oscillator on an ATXMEGA256A3BU.  On startup it takes about 8K cycles of the 32kHz oscillator before you can select it as a clock source to enable the DFLL and as gchapman said it uses 200 uA and would need to run the entire time depending on how often you need to wake up.  The RTC has the option to interrupt at 1.024 kHz you may be able to use this to correct errors in the 32 MHz oscillator manually before sending any data, but again this will take a millisecond or so to do.  Temperature compensation seems like a good idea or just keep two crystals

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

IdiocyCubed, great, thanks for the info! We'll go with that option. Since we use the RTC for timing, an accurate CPU freq is really only needed during USART communication, which we don't do that often.