Xmega256a3bu USB CDC issue

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

Hi Everyone,

 

I am having problems with USB Virtual com port .

 

I made a new hardware which is a replica of  Xmega256a4bu demo board with one minor change is USB VBUS connection.

 

I am not using USB VBUS and left it floating, I connected on board power supply to the ESD protecting device.

 

When I am trying to communicate with PC, My hardware sometime doesn't work properly whereas XMEGA256A3BU demo board always works.

 

Can anyone help me please ?

satya venkata

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

Line 42 of your source code?

 

Pin 42 of the XMEGA?

 

If you're not going to post your code and a schematic, no one is able to help you.

Greg Muth

Portland, OR, US

Atmel Studio 7.0 on Windows 10

Xplained/Pro/Mini Boards mostly

 

 

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

If you aren't using a crystal, your 32kHz RC osc. may need some tweaking.

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

I see you have the a3bu.  I've got that Xplained board.  Congratulations, the crystal on that board can't be used for DFLL. 

 

I have some software here that could help you adjust the 32kHz RC osc. frequency.  Do you have a frequency measuring device?  If not, you could get the sweet spot by trial and error.

 

 

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

I've found that it's best to use either a high frequency crystal (12 or 16 MHz) or DFLL with the USB SOF. It never seems to work very well when calibrated against the 32kHz oscillator, even when you have a very accurate TCXO.

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

I find USB works okay using a properly adjusted 32kHz RC oscillator as a DFLL reference.  However not all 32kHz RC oscillators come from the factory with the frequency adjusted properly.

 
I have a little Xmega program that uses this osc. as the DFLL reference for the system clock, and will export the divided down PER (peripheral) clock on a port pin.   The user can specify how much to divide it down (/10, /100, or /1000) and what pin to export it to.  The program also has a function that allows the user to specify how much to increment/decrement the factory supplied frequency setting.  This should make it easy to find the correct adjustment.

 

In my experience, the factory setting is within 2 of the correct setting. Each increment of the 32kHz osc. frequency adj. register changes it's frequency by about 0.5%.  So you should be able to get it right with a maximum of 5 attempts.

 

I also have a simple program that uses USB CDC and has this 32kHz osc. frequency adjustment function.  So if you can't measure the frequency, you should be able to figure it out by trying various adjustments until you find one that works for the USB.

 

I agree that for boards sold commercially, using a crystal is probably the way to go because you don't have to tinker with the 32kHz RC osc. frequency adjustment.  It would also allow the board to work when the temperature varies a lot from room temperature.

 

I haven't tested the use of SOF thoroughly.  A bit of testing seemed to indicate that if the original frequency wasn't good enough for the USB to work, that our USB wouldn't even see the SOF.  Maybe more testing would find otherwise.

  

Last Edited: Thu. Oct 26, 2017 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did some more testing of the USB clock frequency.

 

I found the 32kHz RC osc. frequency adjustment register is not "regular".  Normally when the register value is incremented by one, the frequency goes up and vice versa.  However sometimes with some register values, when I increment the register by one the frequency goes down, and vice versa.  The end result is it may take incrementing or decrementing the register by 4 or 5 to get the frequency to go where you want it to go.

 

The second thing I learned is that I wasn't dreaming when I had previously found that my PC USB would work okay when the Xmega USB clock was off by 4%.  Apparently there are a lot of PCs that are much more particular.

 

The third thing is that if I switch to DFLL when the original clock is way off, but still usable, I have to see a lot of SOF before I switch.  I'm counting 500 before I switch.  If I switch after seeing only 2 SOF, the DFLL makes the clock much worse and unusable for USB.  Apparently the DFLL drives the clock adjustment to the extreme end of the range in this case.  

 

For boards that are powered by USB, this technique is easy.  For boards that are self powered, when plugged into USB and the DFLL is switched to SOF, and then the board is unplugged, the DFLL will throw off the frequency a lot.  I guess 5% or so.  If the chip can monitor VBUS, the fix is simple.  Otherwise a timer needs to be employed to switch the DFLL back to the 32kHz oscillator when SOF is lost, or it must be rebooted if such an error is unacceptable.

Last Edited: Thu. Oct 26, 2017 - 08:56 PM