CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
18F2550 timing problem....

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
John Morley



Joined: 09 Aug 2004
Posts: 97

View user's profile Send private message

18F2550 timing problem....
PostPosted: Thu Sep 22, 2011 7:09 am     Reply with quote
Hi All,

I'm working on an 18F2550 based project, which has been plagued by an intermittent timing problem. Some of the time the project works exactly as expected (USB connectivity is working, and all software features are functional), but most of the time, the PIC seems to be operating in some sort of ultra slow mode. For instance, I have this test program running now:

Code:


#include <18F2550.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)

#define Pwr_LED Pin_C1

//======================================
void main(void)
{
   while(1)
     {
         output_high(Pwr_LED);
         delay_ms(500);
         output_low(Pwr_LED);
         delay_ms(500);
     }

}



My LED is blinking, but the On and Off periods are exactly 24 seconds instead of 0.5 seconds, or 1/48 th of the programmed speed. This value strikes me as "interesting" because internally the chip is supposed to be clocked at 48 MHz, so it really appears to be running at 1 MHz?

It will work like this for a while, and then several hours later I might reset it, and then it works just fine with 0.5 sec On/Off periods. This is without changing the code, or even reprogramming the PIC, just cycling the power.

Ordinarily, I would think this was some sort of a hardware issue, but I can't quite conceive of a problem that would always allow the chip to work, but to operate at a slow speed some of the time? The board I'm using for my test is a custom design that is populated with only the PIC, a 20 MHz crystal, two 27pf load capacitors, an LED with current limiting resistor, a 10K pullup on MCLR, a USB connector, a Vusb capacitor, and a couple of filter/decoupling capacitors. The PIC is being powered by +5V from the USB connection.

Compiler is v4.121

Ideas?

John
_________________
John Morley
Ttelmah



Joined: 11 Mar 2010
Posts: 19504

View user's profile Send private message

PostPosted: Thu Sep 22, 2011 9:24 am     Reply with quote
I'd try one thing.
Add NOFCMEN to your fuses.
My guess is you will then find the unit doesn't work at all some of the time!....
If so, it identifies the problem. Your clock is not starting sometimes.

FCMEN, is the 'fail safe clock monitor'. If the main oscillator doesn't start, the chip runs off the internal RC oscillator at 31KHz. This is the default behaviour.

Now, reasons for the oscillator not starting, can be various. Low crystal gain is the obvious one, or your loading capacitance may be well outside spec (depends particularly on leakage capacitance on the board....).
Look at Microchip AN949, particularly page 3. I'd suggest trying a 1MR resistor between the oscillator pins on the PIC as a 'first thing to try'. This will help the oscillator start if the gain is a little 'borderline'.
You will get less RF noise, and find the oscillator is more likely to start reliably, by changing to an 8MHz crystal, and PLL2.

Best Wishes
John Morley



Joined: 09 Aug 2004
Posts: 97

View user's profile Send private message

PostPosted: Thu Sep 22, 2011 2:02 pm     Reply with quote
Hi Ttelmah,

It looks like your advise was spot on - the main oscillator was apparently not starting reliably! After thinking about that for a while, a similar occurrence about 6 months ago came to mind where I could not get a 16F876A project to work at all. In that case, the main oscillator was also not starting. Through much trial and error, I determined that the problem was being caused by a minute amount of water soluble flux residue left on the board after cleaning. All of our prototypes are hand-soldered with water soluble flux for the past year or so, and we've seen a couple of problems related to incomplete cleaning. A vigorous cleaning of my board seems to have cured the problem!

Thanks for pointing me in the right direction!

John
_________________
John Morley
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group