XmegaA3U USB and clock options

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

I'm wondering about the best clock option for my xmega project. I've got no constraints, except the I want to use USB. From the USB design note AVR1017 I see that I need a 48Mhz clock that can be generate by the internal calibrated PLL. There is a mention that the internal DFLL can calibrate the PLL and no external crystal may be required.

I don't really see against what the DFLL will calibrate and I don't want to rely on manual calibration during manufacturing.

Should I design a crystal anyway ?

If yes, what frequency is best ?
What about using a 32kHz vs traditional 16Mhz, for example) ?

Markus

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

The best way to do this is to:

a) Enable the 32MHz RC oscillator, using the 48MHz calibration values in the signature row
b) Enable the DFLL on the 32MHz RC oscillator, using the USB Start Of Frame as the reference
c) Enable the PLL and connect it to the internal 2MHz RC oscillator to upscale it to your desired system frequency

This will give you a rock-solid, always synched to the USB bus 48MHz clock with no external crystal required, as well as a less accurate PLL scaled system clock for the CPU (which you can choose to also DFLL calibrate from a clock source).

EDIT: ASCII art!

   _______USB SOF Reference_______
  /                               \
[DFLL]==[32MHz RC Osc @ 48MHz]-->[USB]<-->(PC)

[2MHz RC Osc]-->[PLL]-->[CPU]

Or for better accuracy with a fast XTAL:

   _______USB SOF Reference_______
  /                               \
[DFLL]==[32MHz RC Osc @ 48MHz]-->[USB]<-->(PC)

[XOSC]-->[PLL]-->[CPU]

Or better accuracy without crystal:

   _______USB SOF Reference_______
  /                               \
[DFLL]==[32MHz RC Osc @ 48MHz]-->[USB]<-->(PC)

[Int 32KHz RC Osc]
  |
  |
[DFLL]==[2MHz RC Osc]-->[PLL]-->[CPU]

Or better accuracy with a 32KHz crystal:

   _______USB SOF Reference_______
  /                               \
[DFLL]==[32MHz RC Osc @ 48MHz]-->[USB]<-->(PC)

[TOSC]
  |
  |
[DFLL]==[2MHz RC Osc]-->[PLL]-->[CPU]

Good accuracy with low power consumption, but slow system clock (24MHz):

   _______USB SOF Reference_______
  /                               \
[DFLL]==[32MHz RC Osc @ 48MHz]-->[USB]<-->(PC)
                |
             [DIV /2]-->[CPU]

Low power consumption with a fast enough (up to 16MHz) external crystal:

   _______USB SOF Reference_______
  /                               \
[DFLL]==[32MHz RC Osc @ 48MHz]-->[USB]<-->(PC)

            [XOSC]-->[CPU]

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Dean,

thanks for the detailed answer. The xmega does have a lot of flexibility for the clock options !

So in general: For USB I don't need a crystal because I can synchronize the USB clock with the USB start of frame. I don't expect my device (the power supply) to be always connected to USB, but when the is no USB connection then I don't need the precision either. Overall, for USB I don't need any special provision, its all built in !

I'm not worried about power consumption (its a power supply). But I will have serial communication too, likely 9600 baud. So the remaining question is if the RC osc, without the USB SOF reference is precise enough for serial communications. As the RC clocks are factory calibrated I think the accuracy is sufficient for my needs.

I may add a crystal footprint to my prototype board, so I can easily add one if find out that I need it.

Thanks Markus

Markus

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

An additional question for clarification:

If I decide to use a fast crystal as source for the system clock I have a lot of choice: I can use a 16Mhz crystal and multiply internally by 2, a 4Mhz crystal and multiply by 16 all combinations work as long as I don't exceed 32Mhz as resulting clock and my crystal is in the range given by the data sheet (400kHz - 16MHz).

Is this correct ?

Markus

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

You can choose a PLL multiplication factor of 1x-31x, which doesn't have to be a binary number -- so you can multiple by a factor of 3 for example. The restrictions are that the PLL output frequency must be in the range of 10MHz-200MHz (the latter would need to be divided down before the CPU bus, obviously).

If you need a CPU speed of less than 10MHz, you either need to supply the exact frequency crystal to the XOSC pins or use the bus dividers to scale down the >10MHz PLL output to <10MHz, as the PLL cannot lock to a frequency below 10MHz.

As long as you stick within the constraints of the XOSC module (400KHz-16MHz), the PLL Module (output 10MHz to 200MHz) and the CPU (maximum of 32MHz it will work.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

While we're talking USB and clocks, I'm having the problem that my Intel Notebook just says "Device not recognized" if I start the USB stack and connect while the 32kHz RC is running with my ASF-CDC code. My AMD pc always connects. Can somebody try this please? I don't know if its a problem with my code or not. I'm using a 32A4u.

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

kderhh - I'm afraid I need a little more information. Are you using the stock ASF-CDC demo? If so, what version of ASF are you using?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I use the latest ASF with custom code. I already posted an example code in the ASF forum section some days ago.
The verdict is, when I comment out the "osc_disable(OSC_ID_RC32KHZ);" command before udc_start() and udc_attach(), it only connects in like 10% of the cases, but if it is there it works every time. I have to reenable the RC at a later point of time. In the example code, there are no interrupts or something like that associated with the 32kHz.

Btw, is the ioport_set_pin_sense_mode function broken or what? Whenever I use it it only resets my pin config? And the low-level detect mode isn't defined.
Is reading the Pinnctrl registers even allowed when using mpcmask?

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

Are you using ASF 3.1? Those sound exactly like some of the bugs we corrected for ASF 3.2 - a bug in the XMEGA pin sense function for IOPORT, and some clocking issues in sysclk. Can you try the demo from the latest ASF release to see if it helps?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Does anyone know why the PLL output frequency must be at least 20MHz? I have used it with a 4x multiplier from the 2MHz RC oscillator over many devices (A1, A4, A3U, D3) over a wide temperature range (-5 to 35C) and it seems to be rock solid.

Of course it might still fail in some extreme conditions, but in such cases Atmel usually gives an acceptable ranges, e.g. minimum voltage for high clock speeds.

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

Quote:

Does anyone know why the PLL output frequency must be at least 20MHz?

On the XMEGAs the lower bound is 10MHz, I believe. I'm not sure of the reason exactly, but I would wager it's to do with either stability, accuracy, or a combination of both.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I'm using the latest ASF 3.2.1
As I'm using a custom board I can't try any example code.
All I know is that using the sense function breaks the pin config like pullups etc. (maybe because or'ing something into multi-write-registers may not work at all? I haven't checked it so it might work anyways) and doing it manually by writing the registers works.

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

kderhh, can you give a code sample showing exactly what IOPORT function you are calling? I've been looking through the current trunk code and can't any anything obvious, so being able to see your test case would be a big help.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Oh damn, I see now - yes, it'll just trash the current contents of pin 0's config as I didn't re-set the MCPMASK register between writes. I'll patch this now.

See: http://asf.atmel.com/bugzilla/sh...

- Dean :twisted:

Edit: Oh god, there's R-M-W sequences using it all over the service. Time to crack out some ugly pointers.

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

abcminiuser wrote:

On the XMEGAs the lower bound is 10MHz, I believe. I'm not sure of the reason exactly, but I would wager it's to do with either stability, accuracy, or a combination of both.

ATxmega D3 manual says 20MHz (section 6.1), but of course you can divide it down.

I did some tests with a 128A1 and found that the PLL running from the 2MHz RC oscillator with 4x multiplication was lower power than the 32MHz oscillator divided by 4. I will eventually get around to doing some tests on the D3 for comparison.

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

Just wanted to say thanks! Excellent info on clocks Dean! Exactly what I was looking for :)

SG

SG