UC3 Cycling Power with Crystal Oscillator

Log in or register to post comments
Go To Last Post
11 posts / 0 new
Author
Message
musquirt
musquirt's picture
Level: New Member
Joined: Sun. Feb 19, 2012
Posts: 17 View posts
Location: United States
#1
Posted by musquirt: Thu. Apr 5, 2012 - 09:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm having a problem where my serial output is no longer accurate after a power cycle. When I first program my board (with a Dragon), everything works fine. However, performing a reset by cycling power causes all output to be garbage. I'm using a 12MHz crystal oscillator with the specified capacitors.

Has anyone experienced an issue like this before? Do I need to set fuses? I don't see anything in the fuse editor that looks like it would help.

EDIT: Through further testing, I found that after programming I could get a clean waveform when I toggle a GPIO pin; after a power cycle, the waveform varies like crazy. What could cause this?

Tags:

Tools, Evaluation and Development Kits (AVR-related)
Top
mikech
mikech's picture
Level: Posting Freak
Joined: Mon. Aug 18, 2003
Posts: 1591 View posts
Location: Australia
Posted by mikech: Fri. Apr 6, 2012 - 08:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've also experienced 'odd' behaviour., seems to be mainly on the UC3L and only in release mode.
Everything operates correctly immediately after a re-program, but the chip will continuously restart after a power re-cycle.
I'm thinking it might be related to the watchdog.

Top
musquirt
musquirt's picture
Level: New Member
Joined: Sun. Feb 19, 2012
Posts: 17 View posts
Location: United States
Posted by musquirt: Fri. Apr 6, 2012 - 01:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll try disabling the watchdog the next chance I get.

It could also be a software problem, I guess; possibly having to do with crystal startup time. But then I'm not sure the described behavior makes sense, unless me oscillator is unable to put out a "clean" waveform when not given enough time to start up.

Top
musquirt
musquirt's picture
Level: New Member
Joined: Sun. Feb 19, 2012
Posts: 17 View posts
Location: United States
Posted by musquirt: Mon. Apr 9, 2012 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good news! The problem has progressed such that now all output from this particular oscillator circuit is unstable regardless of whether or not I reprogram it.

So, this must be a solder problem, right?

Top
digitalDan
digitalDan's picture
Level: Resident
Joined: Sat. Nov 1, 2008
Posts: 614 View posts
Posted by digitalDan: Mon. Apr 9, 2012 - 11:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

musquirt wrote:
So, this must be a solder problem, right?

Maybe, but why not post your clock init code. I'd be happy to take a look at it and tell you if I see anything suspicious.

Letting the smoke out since 1978

 

 

 

 

Top
musquirt
musquirt's picture
Level: New Member
Joined: Sun. Feb 19, 2012
Posts: 17 View posts
Location: United States
Posted by musquirt: Tue. Apr 10, 2012 - 12:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Maybe, but why not post your clock init code. I'd be happy to take a look at it and tell you if I see anything suspicious.

For my clock initialization, I simply use the power manager to switch over to my oscillator. I've burned down the code in a separate project to confirm where the problem comes in, and this is the meat (without includes, etc):

volatile avr32_pm_t *ourPM;
ourPM = AVR32_PM_ADDRESS;
pm_switch_to_osc0(ourPM, 12000000, 500000);

while (true) {
  gpio_toggle_pin(AVR32_PIN_PA26);
}

As said previously, the GPIO pin being toggled is stable at about 200 kHz after a reprogram, but is unstable around that frequency (however pretty much immeasurable) after a manual reset or power cycle. I initially found the problem when my serial output was initially good, but then garbage after a power cycle.

Any help/advice will be greatly appreciated.

Top
musquirt
musquirt's picture
Level: New Member
Joined: Sun. Feb 19, 2012
Posts: 17 View posts
Location: United States
Posted by musquirt: Tue. Apr 10, 2012 - 01:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It may also be useful to note that the output on the GPIO pin is always stable (reprogram, power cycle, reset, etc) when using the internal RC oscillator (115200Hz). Unfortunately, I need to run the PWM with a frequency of about 38.2kHz.

Top
digitalDan
digitalDan's picture
Level: Resident
Joined: Sat. Nov 1, 2008
Posts: 614 View posts
Posted by digitalDan: Tue. Apr 10, 2012 - 02:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The third parameter to pm_switch_to_osc0() isn't right. The startup field is only 3 bits wide so it can only take a value 0 to 7. The startup parameter is expected to be one of the AVR32_PM_OSCCTRL0_STARTUP_* defined values. I've used AVR32_PM_OSCCTRL0_STARTUP_2048_RCOSC with a 12Mhz crystal with no problems.
Note that since the value you supplied (500000) won't fit into the destination bit field, you are actually programming the startup value as 0; this gives no startup delay and could very well be the cause of your problem.

Letting the smoke out since 1978

 

 

 

 

Top
danicampora
danicampora's picture
Level: Hangaround
Joined: Tue. Oct 9, 2007
Posts: 398 View posts
Location: Eindhoven, The Netherlands
Posted by danicampora: Tue. Apr 10, 2012 - 03:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I really wonder why people decides to put their own "calculated" parameters when the ASF already has definitions for all the possible valid values...

Daniel Campora http://www.wipy.io

Top
musquirt
musquirt's picture
Level: New Member
Joined: Sun. Feb 19, 2012
Posts: 17 View posts
Location: United States
Posted by musquirt: Tue. Apr 10, 2012 - 10:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The third parameter to pm_switch_to_osc0() isn't right. The startup field is only 3 bits wide so it can only take a value 0 to 7. The startup parameter is expected to be one of the AVR32_PM_OSCCTRL0_STARTUP_* defined values. I've used AVR32_PM_OSCCTRL0_STARTUP_2048_RCOSC with a 12Mhz crystal with no problems.
Note that since the value you supplied (500000) won't fit into the destination bit field, you are actually programming the startup value as 0; this gives no startup delay and could very well be the cause of your problem.

This solution worked! Thanks so much for pointing out that fatal flaw in my reading skills.

Quote:
I really wonder why people decides to put their own "calculated" parameters when the ASF already has definitions for all the possible valid values...

The parameter in the function call is "unsigned int." If it were to be defined as, say some enum, then I would have more naturally figured out what enumerated types I was supposed to use. However, if I had taken a closer inspection of the API I might have realized this sooner.

Top
digitalDan
digitalDan's picture
Level: Resident
Joined: Sat. Nov 1, 2008
Posts: 614 View posts
Posted by digitalDan: Wed. Apr 11, 2012 - 12:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad to be of service. :)

Letting the smoke out since 1978

 

 

 

 

Top