| Author |
Message |
|
|
 Posted: Apr 05, 2012 - 10:30 PM |
|
Joined: Feb 19, 2012
Posts: 17
Location: United States
|
|
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? |
|
|
| |
|
|
|
|
|
|
Posted: Apr 06, 2012 - 09:02 AM |
|
Joined: Aug 19, 2003
Posts: 403
Location: Australia
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 06, 2012 - 02:12 PM |
|
Joined: Feb 19, 2012
Posts: 17
Location: United States
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 09, 2012 - 01:54 PM |
|
Joined: Feb 19, 2012
Posts: 17
Location: United States
|
|
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? |
|
|
| |
|
|
|
|
|
|
Posted: Apr 10, 2012 - 12:05 AM |
|
Joined: Nov 01, 2008
Posts: 192
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Apr 10, 2012 - 01:59 AM |
|
Joined: Feb 19, 2012
Posts: 17
Location: United States
|
|
|
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):
Code:
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 10, 2012 - 02:25 PM |
|
Joined: Feb 19, 2012
Posts: 17
Location: United States
|
|
| 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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 10, 2012 - 03:19 PM |
|
Joined: Nov 01, 2008
Posts: 192
|
|
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
|
| |
|
|
|
|
|
|
Posted: Apr 10, 2012 - 04:43 PM |
|
Joined: Oct 10, 2007
Posts: 395
Location: Valls, Spain
|
|
| 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.lear.com
|
| |
|
|
|
|
|
|
Posted: Apr 10, 2012 - 11:55 PM |
|
Joined: Feb 19, 2012
Posts: 17
Location: United States
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 11, 2012 - 01:09 AM |
|
Joined: Nov 01, 2008
Posts: 192
|
|
Glad to be of service.  |
_________________
Letting the smoke out since 1978
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
