Atmega4809 calibration of the 20 MHz oscillator

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

I try to find a way to calibrate the 20MHz RC oscillator of the Atmega4809 in software. I use the LMIC lorawan library and without setting the MAX_CLOCK_ERROR the timing is too off to run properly.

The datasheet says that there are calibration values in the SIGROW register but i can not find code examples except for the UART.

 

And i found this application Note from the AVR DA family and since i have a 32k quartz mounted i find it interesting

 

http://ww1.microchip.com/downloa...

 

But i struggle finding out the mechanics behind the Autotune feature.

 

The third thing i could do is mounting a 74HC04 to drive the main clock with a crystal but i try to avoid the extra current consumption

 

Maybe somebody can point me in the right direction?

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

 

In Atmega 4809 datasheet, search for the term OSC20M. This related to calibration of the 20 MHz oscillator.

 

Also,

 

 

Edit :- Post correction, I thought you were using MCU from AVR DA family, but it's Atmega4809.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

Last Edited: Sat. Jun 18, 2022 - 09:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

applepi wrote:

..The third thing i could do is mounting a 74HC04 to drive the main clock with a crystal but i try to avoid the extra current consumption

 

How much stability and jitter do you actually need ?

An external Xtal will have less jitter and less error than an Auto-tune option, but it does need more parts and more cost.

The autotune on a MCU is like the Crystal-less USB solutions, where the nearest trim value is chosen, to that means the error and jitter can be up to one trim-step.

The examples given in #2, show that effect, as the errors are not 0%.

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

applepi wrote:
But i struggle finding out the mechanics behind the Autotune feature.

Auto-Tune looks a really good feature; mirroring some of the MSP430 clocking options, if you know those, but Atmega4809 doesn't have the Auto-Tune hardware.

 

Does the fractional adjustment using  Factory Error Values not work for you ? I cannot see why it should not work but the code does become quite messy as a result.

 

Alternatively, manually operating the Auto-Tune principle is valid but because of the size of each adjustment step (0.75%)  it doesn't result in any better results that using the Factory Error values.

 

Be prepared however to admit that because an external high-speed quartz crystal option isn't supported by Atmega4809, you've chosen the wrong micro.

 

Last Edited: Sat. Jun 18, 2022 - 09:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

applepi wrote:
I try to find a way to calibrate the 20MHz RC oscillator of the Atmega4809 in software.
Microchip Studio with an Atmel tool and a frequency meter to measure the generated signal's frequency.

applepi wrote:
But i struggle finding out the mechanics behind the Autotune feature.
In lieu of is software autotune given a 32 KHz crystal.

applepi wrote:
The third thing i could do is mounting a 74HC04 to drive the main clock with a crystal but i try to avoid the extra current consumption
1.5 mA plus or minus though an enable signal is common for external crystal oscillators.

applepi wrote:
Maybe somebody can point me in the right direction?
Some USB UART can generate a clock signal that's accurate given USB SOF; similar for recent USB PIC which have Active Clock Tuning (crystal-less)

 


Oscillator Calibration | Microchip Studio

Calibration Clock Accuracy | AVR053: Internal RC Oscillator Calibration for tinyAVR and megaAVR Devices

 

AN8002 AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC | Application Note | Microchip Technology

 

USB in a NutShell - Chapter 2 - Hardware | Data Signaling Rate

PIC18F25K50 | Microchip Technology

 

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

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

Thank you all

 

The library says 100ppm what means for 10MHz 9.999.000 to 10.001.000

They say nothing about Jitter, so i have to give it a try.

 

N.Winterbottom wrote:

 

Alternatively, manually operating the Auto-Tune principle is valid but because of the size of each adjustment step (0.75%)  it doesn't result in any better results that using the Factory Error values.

that make sense.

 

OK, there is the 7bit OSCCAL20M0 and the 8bit OSC20ERR3V

I checked, the SIGROW_OSCAL20M0 is loaded into CLKCTRL_OSC20MCALIBA on boot, but how can i handle the OSC20ERR3V?

Both registers gave me 0x0101000, so the calibration is not only loaded on reset but also on boot.Has this value a unit?

The OSC20ERR3V gave me 0x00000101

The datasheet talks only about UART, can i use it for adjusting the CLKCTRL_OSC20MCALIBA?

 

 

 

 

 

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

The datasheet talks only about UART, can i use it for adjusting the CLKCTRL_OSC20MCALIBA?

The factory loaded sigrow error values (read-only) are what the remaining error is after the factory provided calibration value is loaded. The sigrow values can be used to compensate for the remaining clock error, such as the uart baud register value or a timer period value, etc. Its still a bunch of factory loaded numbers that may or may not be good enough for your needs (apparently not, since you are here), and if you could calibrate at runtime you will know better what you really have but most likely still have remaining errors that have to be dealt with.

 

You have an available external 32k crystal it seems, so I would look into using the rtc to do the lmic timing. Looking at some of the documentation, it appears that the default  'os tick' rate is/was 1/32768 so you could use the rtc time directly. It will take some source code browsing to see how you can replace what they have for time with the rtc time. Probably a better idea than trying to use the 32k clock to tweak the osc20m clock since the osc20m clock will still have errors to deal with.

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

I think you misunderstand the registers.

 

As you noticed,  CLKCTRL_OSC20MCALIBA gets loaded with the factory Value on boot / reset. Due to the poor granularity of the adjustment this turns out to be the ideal value but still results in some frequency error. (This might be 0.75% / 2 = 0.375%). This frequency error is measured at 16MHz/20MHz and various Vcc supply and written into  SIGROW.OSC16ERR3V / SIGROW.OSC16ERR5V respectively as a value encoded as below.

 

10.3.4.1.1 16/20 MHz Oscillator (OSC20M)

...

The error is stored as a compressed Q1.10 fixed point 8-bit value in order not to lose resolution, where the MSb is the sign bit and the seven LSb the lower bits of the Q1.10.

If you wish, you can apply the correction to a Timer Compare value, for instance, using the multiply and divide in the USERT0.BAUD example.

 

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

applepi wrote:
The datasheet talks only about UART, can i use it for adjusting the CLKCTRL_OSC20MCALIBA?
Yes in the context of auto-baud (software or hardware)

 

AN2563 AVR054: Run-time calibration of the internal RC oscillator via the UART | Application Note | Microchip Technology

AVR054.zip | Wayback Machine

Auto-Baud | USART | ATmega4808/4809 Data Sheet

 

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

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


applepi wrote:

Thank you all

 

The library says 100ppm what means for 10MHz 9.999.000 to 10.001.000

They say nothing about Jitter, so i have to give it a try.

 

N.Winterbottom wrote:

 

Alternatively, manually operating the Auto-Tune principle is valid but because of the size of each adjustment step (0.75%)  it doesn't result in any better results that using the Factory Error values.

that make sense.

 

OK, there is the 7bit OSCCAL20M0 and the 8bit OSC20ERR3V

I checked, the SIGROW_OSCAL20M0 is loaded into CLKCTRL_OSC20MCALIBA on boot, but how can i handle the OSC20ERR3V?

Both registers gave me 0x0101000, so the calibration is not only loaded on reset but also on boot.Has this value a unit?

The OSC20ERR3V gave me 0x00000101

The datasheet talks only about UART, can i use it for adjusting the CLKCTRL_OSC20MCALIBA?

 

My reading is that the 7bit OSCCAL20M0 is the one that changes the frequency, with ~ 0.7% step sizes, and it looks to be monotonic. 

ie

 

 

with that largish step, you will only be able to get a long term average locked to the 32kHz Xtal, to the claimed 100ppm - any SW ( or HW if the chip has it) control loop will sample the Osc vs Xtal frequencies and issue an INC/DEC correction.

You can get less short term jitter if you introduce a 3rd state of INC/HOLD/DEC, but if you have a hold band, the long term accuracy is less certain.

 

How much exactly is  the timing is too off to run properly  

and what precision and jitter do you need  ?  Is a 0.7% step ok ?

 

If you are handling message frames and using autobaud or similar, you could sync the frequency corrections to be stable during a frame.

Once you are in the control band, you only need to track temperature changes so the correction does not need to be rapid.

 

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

Thank you for your answers,

slowly i get the picture.

And i missed those graphs, nice.

 

The problems are Two:

  1. Jitter, the only solution is a driver circuit and waste joules there
  2. RC oscillator is off frequency. The step size of the CALIBA register is not suitable to meet 100ppm precision and the workarounds are less certain. The only way is to bind the X32K to the os ticks what needs fairly radical replumbing of oslmic (words of descartes from TTN)

 

So i asked on the TTN Forum how others handle this issue.

https://www.thethingsnetwork.org...

 

Maybe it is best to accept for now the relaxed RX window and, when the component shortage is over, change to a more suitable micro

 

 

 

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

Do you really need to calibrate the chip?
What do you need the precision for?

 

Often it's better and have a better resolution if done in SW.

 

As long you know how fast it run (perhaps extra compensate over voltage and temp.)

you can make a accurate 1 sec or what ever you need, and then time from there.  

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

needs fairly radical replumbing of oslmic

Why not point us to what library you are using.

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

applepi wrote:
So i asked on the TTN Forum how others handle this issue.

So this is a LoRa thing and you need to generate accurate time-slots ?

 

Forget using any internal RC oscillator for this. Connect a watch crystal of 32768Hz to TOSC1/TOSC2 and drive the RTC with it. At room temperature you'll get 50ppm or a higher spec. crystal can get you 20ppm uncorrected. With RTC correction this gets vastly better.

 

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

curtvm wrote:

needs fairly radical replumbing of oslmic

Why not point us to what library you are using.

in my first post

applepi wrote:

  I use the LMIC lorawan library and without setting the MAX_CLOCK_ERROR the timing is too off to run properly.

 

 

the mcci fork

 

I have to catch the RX1 and RX2 windows with 20us (as far as i remember,cant find the reference) precision

 

N.Winterbottom wrote:

applepi wrote:
So i asked on the TTN Forum how others handle this issue.

So this is a LoRa thing and you need to generate accurate time-slots ?

 

Forget using any internal RC oscillator for this. Connect a watch crystal of 32768Hz to TOSC1/TOSC2 and drive the RTC with it. At room temperature you'll get 50ppm or a higher spec. crystal can get you 20ppm uncorrected. With RTC correction this gets vastly better.

 

 

Thank you Winterbottom, i will go this way

 

You are great guys, Thank you all for your help

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

the mcci fork

Why not just provide a link. I did already search for code with the info from your original post, and there are many different versions including the original from ibm. A lot of the results found are arduino based, but do not even known if you are using arduino.

 

It appears the original code was designed to separate the library from the mcu via a hal. The interface from the hal to the library for the time was by default using 32khz as a time base, which makes sense for low power devices. So as I said in #7, using the 32k crystal via rtc as the time base for the library should be looked into, but hard to tell how difficult without seeing the library code. Your mcu still runs from the internal clock, its just the os_time that would derive its time from the rtc counter.

 

Assuming using this library-

https://www.arduino.cc/reference...

 

A possible way to use the rtc for time-

https://godbolt.org/z/W8EWcshaP

The changes to make should be self explanatory. I grepped the uses of hal_ticks() in the library, and it seems this should work ok but would just have to try it. The underlying lmic ostime_t is an int32_t but they really treat it as a uint32_t for incrementing (0-INT32_MAX,INT32_MIN-0, or 0-0xFFFFFFFF). Which is why hal_ticks() returns a uint32_t and it all still makes sense.

 

The library converts any need for ms using ms to os ticks macros, so that all should still work as it should.

 

edit- and you will have to make sure you are getting OSTICKS_PER_SEC defined as 32768. (lmic/config.h)

 

I have to catch the RX1 and RX2 windows with 20us (as far as i remember,cant find the reference) precision

The rtc counter has ~30us resolution, and you will have unknown time between ticks (since your mcu is running at a higher speed than the rtc). So you may end up having to assume a certain amount of error in reading- for example it could be the rtc changes right after reading, so you are then using a start value that is not a 'full' ~30us. Would assume you still have to open the rx window a little, but I think it would be small (maybe a tick or two).

Last Edited: Sat. Jun 25, 2022 - 09:12 AM