Synchronization issue: Clock configuration and Timer's accuracy on Xmega

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

I've recently encountered a synchronization problem on an application where an error code is an output on a display of many parallel connected "slaves" when a "master" sets an error bit(s) on a bus.

 

  • In other words, a master sends over RS-232 a regular message to all connected slaves concerning the general status of a central machine. When on this message, an error bit is set (which can remain set for several minutes), all connected slaves begin showing a sequence of characters, one after the other with a small pause between each character, on a single display that they individually have (e.g. F_12:  'F' → '_' → '1' → '2' and repeat).   

 

  • The master does not send these characters, only the error status bit(s), to avoid putting so much information on the bus. It also does not set the wait time in between each character being displayed. This parameters and information are already programmed on each individual slave and it is done using timers on an internal state machine they have.

 

  • After just a few seconds of the message being shown on the display, I can already notice that the sequence does not begin anymore at the same time on all slaves. After a few minutes, the sequence seems completely different on all slaves (e.g. some of them showing 'F' when others are showing '2').

 

  • The original sequence starts at the same time on all slaves since they all receive the message on the bus simultaneously. From this point on, the sequence is controlled using a ticker that is updated on a single ISR() every 1ms. There are only two ISR() on the program, one for the bus (Rx) and one for the timer. The ISR() for the bus has the highest priority. Both ISR()s allow nested ISR calls from the other one during execution.

 

  • The controller is working with 12MHz and the Timer uses CLK(sys)/2 = 6Mhz with a PER = 6000d -> exactly 1ms (verified using an oscilloscope on a test pin that toggles within this ISR)

 

  • The CLK(sys) is first configured with the internal 2MHz clock (1% error, same as other internal sources), then using the PLL it is set to 24MHz (the output must be between 20Mhz and 200Mhz), and finally using a prescaler it is set to 12MHz. After that, DFLL (digital frequency-locked loop) is used using the internal 32Khz-Osc. Finally, CLK Configuration locking is also set. 

 

  • For testing purposes (on a copy project), I deleted all other functions done on the program and only left the receive routine and the state machine for the display. I even simplified the display routines, so that only a single line is turned on and off (over and over). Even the timer ISR now only updates the ticker for the display and nothing else. This, of course, to verify that no other routines are blocking the main program. The Same effect can be seen after a few seconds.  

 

  • I also did a small synchronization adjustment on the receive routine. When the error bit is first received on the serial port, the Timer Counter for the respective Ticker is initialized at 0:  ATOMIC_BLOCK(ATOMIC_RESTORESTATE){TCC1.CNT = 0;}. This improved the performance but after a few seconds more, it showed the same issue on the display. 

 

Before I go ahead and put all the code of this program, I guess the main question would be: is it at all a mistake to expect that all these controllers would be showing exactly the same timing on all individual timers after several minutes, taking as a given that all of them receive the same "go" trigger signal on the bus at the same time, that all of them have the same clock and timer configuration and (let's just say) that the clock has been perfectly configured and calibrated (as much as it can be)? Is the error of the internal clock sources of 1% the issue?

 

NOTE: I have seen a similar project in my company doing exactly what I am trying to do, but there an ATmega with external crystal is being used and it works!!! without any kind of "synchronization routine" being necessary. 

 

Any help would be extremely appreciated. 

 

------------------------------------------------------------------------------------------

Using:

 

  • Controller: ATxmega32D3
  • Programming language: C
  • IDE: Atmel Studio 6.2
  • Toolchain: AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain

 

EDIT: last bullet point with the "synchronization adjustment"

Last Edited: Fri. Dec 8, 2017 - 10:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess the question is, "Is the 32kHz RC osc. in each Xmega within 1% of each other?".   If you haven't checked them all and made adjustments if necessary, there is a good chance they are not within 1% of each other.

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

I just noticed you have a D series Xmega.  I only know the AU series.   I guess they are similar.

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

avr_ivan wrote:

 is it at all a mistake to expect that all these controllers would be showing exactly the same timing on all individual timers after several minutes, taking as a given that all of them receive the same "go" trigger signal on the bus at the same time, that all of them have the same clock and timer configuration and (let's just say) that the clock has been perfectly configured and calibrated (as much as it can be)? Is the error of the internal clock sources of 1% the issue?

 

NOTE: I have seen a similar project in my company doing exactly what I am trying to do, but there an ATmega with external crystal is being used and it works!!! without any kind of "synchronization routine" being necessary. 

 

You have pretty much answered your own question.

ALL MCUs with independent clock sources, will drift apart over time, the only issue is by how much.

A crystal will be within 50ppm or better, so such drift will take longer to be apparent.

If you are using local RC Osc clocks, of course that has much larger errors, in both calibration and drift over time and jitter.

 

I'm curious, if these are local displays, why does it matter if they do not update at identical times ?

 

If that really does matter, and you cannot add a crystal, then you will need to send some dummy/NOP char over the link, to 'pace' the display updates.

We have used serial links in the past, as continual streaming data for more accurate timing.

This can be as good as the UART clock stability, and has quite low skews across all slaves (some fraction of a baud bit time)

 

One small detail to watch, there are  2 classes of USB-UART - some calibrate a local RC osc to the 1ms USB frame, and those are 0.25%~0.1% of baud precision, I think with no guarantee of any long-term-average.

Others use a crystal, and those have much better stability.

HS-USB bridge parts tend to all use Crystals, as RC osc are not good enough. (FT232H, FT2232H etc)

 

There are some Asian FS USB-UARTS that still use crystals - the CH340 I think still does that.