Xmega USART, Tx char space

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

Hi all,

 

I have a application using ATXMEGA32A4U-MH that is using internal 2MHz oscillator with PLL x 4 (8MHz controller speed) and USART connected to a serial Modbus.

 

The problem is as follows: 

When temperature is below -20 deg. Celsius the 2M oscillator is so much off that when the board sends its replay on serial bus, a get bit synchronization issue since I uses the "USART empty" interrupt and then all bytes (up to about 40 bytes) sent have no space between.  The receiver then fails after an unknown number of bytes received since the timing fault on the frozen board adds up for each char.

 

So I need a simple way to add a delay equal to maybe 1.2 char or so.  I can use a timer to send chars with space between, but maybe there are some more easy way to do this, possibly something built into USART ?  I believe this is a problem many have experienced.  Any tip is welcome :)

 

Have a nice coding day :)

Morten

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

If the error really happens only after several bytes has been sent, you should be able to fix it by having the USART send two stop bits (SBMODE in CTRLC). This will allow the receiver enough time to catch up with the transmitter after each byte.

 

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

I would expect the 2MHz RC to work fine over a large temperature range.
The PLL and USART should not be very sensitive to temperature.
.
Pure guesswork. I have no practical expereience with low temp.
However, I suspect that your pcb might be prone to condensation / ice.
Bad flux cleaning before conformal coating?
.
You can fix most things in software. But I would want to find the actual hardware problem first.
.
David.

Last Edited: Wed. Nov 8, 2017 - 04:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I uses the "USART empty" interrupt

 

I'm not quite sure I understand the process, but if you have a hardware triggered ISR transmitting the data, could you just put a couple of "NOP" instructions at the start of the ISR?

 

JC

 

Edit: Typo

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

Also, if the board will always be in the cold environment, then you could tweak / calibrate the clock to be accurate at the -20'C temperature, (or perhaps adjust the baud rate to compensate, (I'm not sure how finely that can be adjusted...)).

 

JC

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

Finely, again assuming your don't' want to add an external Xtal, if the Xmega will be in an environment with a wide temperature swing, perhaps you could use the on board temperature measurement feature to get a ROUGH idea of the temperature, and then have a clock calibration table to compensate.

 

JC

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

MortenB wrote:
When temperature is below -20 deg. Celsius the 2M oscillator is so much off that when the board sends its replay on serial bus, a get bit synchronization issue

 

You need an accurate and temperature stable clock source for reliable serial comms, a $0.20 xtal would provide that!  Without that you will spend much time characterizing and building a temp compensation table.

You will need to decide if your time or your money is better spent on this project.  My time is valuable so I spend the pennies on the h/w (xtal).

 

YMMV

 

Jim

 

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

Hi all,

 

Thanks for input.  The board is made without crystal since I do not need accurate timing, and it is a low power design.  I am sure there are no condensation problems.  Using "USART empty" interrupt

and not shift reg. empty int. may be enough to get the space I need, and is simple to test.

 

Maybe the best suggestion is to tweak the USART baud rate a little when below maybe -5 deg- (equals -10 because of self heating).  I happens to have a I2C MCP9800A temperature sensor on board and have a accurate temperature.

I then have to find out how much the 2M osc. is changing.  Possibly I can multiply the number of chars received with 10 bits (start/stop bit and 8 data bits) and calculate this out of temperature when CRC start to fail and my baud-rate at 38.400...

 

The first series of boards is actually in customers test now, but as they only uses the current loop (4..20mA loop) and not the serial bus they will most likely never know that this happens :)  But doing things perfect is my way so I want this working in next FW update.

 

I will describe what I ends on later

 

Morten

Last Edited: Thu. Nov 9, 2017 - 01:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My earlier reply was from a Tablet.

 

Looking at my ATXmega32A4U datasheet: Figure 37-158.2MHz internal oscillator frequency vs. temperature. DFLL disabled.

and Figure 37-159.2MHz internal oscillator frequency vs. temperature. DFLL enabled, from the 32.768kHz internal oscillator .

 

The 2MHz has a consistent temperature curve when DFLL is dsabled.   And an even better result with DFLL.

 

It should be simple enough to do your own compensation without DFLL.   But I really don't see much of a problem with USART comms.   The timing only has to be +-2% relative to the other side.    I am assuming that the "other side" is operating with XTAL and at room temperature i.e. accurate within a few ppm.

 

It should be easy enough to measure the clock frequency vs temperature e.g. with a XTAL controlled AVR or a Laboratory Frequency Meter..

You just have to check whether your device follows the typical curves from the datasheet or is vastly different.

 

If you do end up with doing your own 2MHz RC oscillator compensation,   the Xmega internal temperature sensor should be plenty good enough in conjunction with the typical slope.

 

David.

Last Edited: Thu. Nov 9, 2017 - 03:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David for a good idea.

I understand that Xmega still has features I do not know of, DFLL will be the first thing I will test.  Partly this is also the reason for asking other programmers on avrfreaks smiley

 

Since I have an application where I use a USART interrupt that fill the USART's shift register while last char still is shifted out, the bit timing error in Tx message gets added up for each byte (consisting of 10 bits x 42).  In total I have max. 42 chars in a message that equals to 420 bits and somewhere in the end of the message the bits get out of sync.  The applications code base is taken from other projects where the serial port do not need to work at -20 deg. (only for lab test and calibration), and in most cases have a crystal that keep timing correct at -20 deg.

 

Morten.

Last Edited: Fri. Nov 10, 2017 - 01:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should always use DFLL unless frequency accuracy is irrelevant.   The 32 kHz RC osc freq. is more accurate than the other RC osc. and varies less with temperature.

Last Edited: Sun. Nov 12, 2017 - 10:58 AM