Atxmega128A3U USART Data Corruption by Temperature change

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

Dear all,
I am newbie on Atxmega128A3U. Problem i am facing is I have programmed two of my custom board based on Atxmega128A3U.

I am transmitting data using USART at baud rate 38400.

Data frame transmitted correctly. while after passing some time, means in winter with temperature change data is being corrupted.

What i did is change value of baud rate and again its work fine.

Another test conducted today is I turned On the device and put it into freezer at -4 degree centigrade. Suddenly it starts sending too much garbage data.I am shocked. Its data sheet is saying that it can work in -40 degree--- +80 degree centigrade.

I am using internal 32MHz oscillator with no division.

Please update with your valuable suggestions.

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

Have you looked for the oscillator info in the datasheets on what happens on extreme temperatures. Maybe you need to invest in some temperature compensation either within the chip itself or get a temperature compensated external clock source.

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

The 32 MHz oscillator frequency is not particularly stable. The 32 kHz oscillator is considerably better. If you aren't using DFLL, then you should. DFLL adjusts the 32 MHz frequency using the 32 kHz frequency as a standard. I don't know if this is good enough at -4 centigrade.

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

Dear all,
Thanks for your quick response appreciating. I have also read the data sheet saying that frequency drift can occur at voltage and temperature change. To compensate this frequency drift need to use DFLL.

@Steve, you are absolutely right. let me do it on DFLL then will post updates again.

For my own clarification and understanding, Can i generate 38400 baud rate using 32Khz internal oscillator?

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

32KHz isn't enough to generate 38400 baud (38400 > 32768). You need to use the 32KHz clock as a reference for DFLL to keep the 32MHz clock within an acceptable range. If you are dealing with wide temperature ranges you might need a TCXO. How cold are we talking?

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

I'm not sure just what your question is.

Using DFLL changes nothing except to make the RC system clock more accurate. In particular, you can still use a "usart friendly" system clock if you want.

Most of us no longer use a "usart friendly" clock with the Xmega, because the Xmega has a "fudge factor" capability in it's baud rate generator that allows generating almost any baud rate regardless of whether the PER/CPU frequency is "usart friendly". That "fudge factor" is called BSCALE.

Calculating the correct BSCALE is apparently not simple. I use the Excel spreadsheet found here:
https://www.avrfreaks.net/index.p...

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

Dear all,
Thank you for your support. I am implementing DFLL now for system frequency is 32MHz internal oscillator, while 32.67KHz internal oscillator reference frequency.

Temperature of tesing is = -15 degree centigrade

While BSEL=(817,not working fine on 817) using 827 actually
BSCALE= -4

I just enabled DFLL. and programmed my system. its still giving garbage data.
Definitely I will test all of your instructions step by step.



void EnableInter32MhzOsc() {
	CCP = CCP_IOREG_gc;              // disable register security for oscillator update
	OSC.CTRL = OSC_RC32MEN_bm;       // enable 32MHz oscillator
	while(!(OSC.STATUS & OSC_RC32MRDY_bm)); // wait for oscillator to be ready
	CCP = CCP_IOREG_gc;              // disable register security for clock update
	CLK.CTRL = CLK_SCLKSEL_RC32M_gc; // switch to 32MHz clock

 CLK.PSCTRL = 0x00; // no division on peripheral clock
	 DFLLRC32M_CTRL = DFLL_ENABLE_bm;
	}


Is i need to put compare & calibration value in those registers myself? Is not it take default value. Please advise. or add some comments for my code. thanks
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you are not setting the DFLL COMP register pair. I think those are called DFLLRC32M_COMP1 etc. in the iox...h files. The correct value for 32 MHz is 0x7a12. You can calculate it for any frequency. It is desired freq. / 1024. Note the 32kHz freq. is divided by 32 = 1024Hz before it is used.

Maybe this value is set at reset. In that case I don't know what your problem is.

Are you testing at room temperature now or at -4C?

If you are testing at -4C, then probably the 32 kHz osc. is inaccurate at that temperature. In this case, there may be an adjustment you can make. Consider that the Xmega can report it's own temperature, and the frequency of the 32 kHz osc. is tweakable (RC32KCAL).

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

Actually if you want to pursue this tweaking stuff, it may be more practical to tweak the DFLL COMP registers instead of the 32kHz calibration register. Either way it should produce the same result.

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

Dear all,
Thanks

@Steve, I have read your earlier posts about DFLL not working.

Can you please guide me how to enable DFLL? Is I need to enable both DFLL?

Also I need the value for calibration registers? Its confusing to me what value should be in these registers.

My custom boards temperature will vary. I want to test it -10 degree centigrade. At room temperature testing device works fine. while at -5 degree centigrade it sends me garbage data.

DFFL CAL A?
DFFL CAL B?
DFLL COMP A?
DFLL COMP B?
DFLL COMP C?

I have not external oscillator at my custom board. I am using internal oscillator 32 MHz. and want to use reference osicllator 32.67KHz. If this is stable.

@Steve can you please post a simple code for this calibration. Appreciate your response. Thanks

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

I don't use the names from the iox....h file. I don't use ASF. My code probably won't be very useful. You might find the code somewhere in the ASF stuff.

The DFLL CALA and CALB values for running the oscillator at 32 MHz are set automatically at reset. At least that's what the manual says. You shouldn't have to set them yourself.

Only two of the DFLL COMP registers are used. COMP1 @ DFLL regs + 0x05 and COMP2 @ DFLL regs + 0x06. The old COMP0 is no longer used. COMP1 holds the low order 8 bits and COMP2 holds the high order bits. (freakin' assbackwards endian, you know) So to run at 32 MHz, put 0x12 into COMP1 and 0x7a into COMP2.

I believe none of the DFLL registers can be changed when the DFLL is enabled.

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

Going back to your original post, the Xmega no doubt works over the temperature range specified. However the frequency of the RC oscillators will certainly change as the temperature changes.

Usart communications requires fairly exact timing. When you say you are using 38,400 baud, you are specifying a certain frequency. Maybe 38,400 Hertz. I have found I can vary the frequency 2% here at home and still communicate with my PC. Such a variation however is not guaranteed. It depends on things like the frequency accuracy of the RS232 port on the PC.

I guess an experienced hardware designer would probably use a crystal in cases like yours, as crystals are a lot more stable than RC oscillators. We are lucky to have an RC oscillator as good as the Xmega one.

It remains to be seen if using DFLL will allow the USART to work at such a low temperature without some other compensation scheme.

There are graphs showing the frequency variation for the various oscillators vs. temperature near the end of the manuals for the various AU chips. If I'm reading it correctly, you may get lucky using DFLL.

Here's the graph of the 32MHz oscillator with DFLL, for the A4U series.

Attachment(s): 

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

Dear all,
thanks for your help. now its working fine using DFLL.
:)

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

That is good to hear. Thanks for letting us know.