UC3 Cycling Power with Crystal Oscillator

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 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?

  • 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.

  • 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.

  • 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?

  • 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

 

 

 

 

  • 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.

  • 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.

  • 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

 

 

 

 

  • 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

  • 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.

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

Glad to be of service. :)

Letting the smoke out since 1978