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

48 MHz oscillator problem

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



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

48 MHz oscillator problem
PostPosted: Fri Jan 28, 2011 10:43 am     Reply with quote

Hi all. Wonder if anyone has any suggestion for this problem. I had a new board made, using a PIC18F4553. This is a PIC that can do USB. To do fast USB it needs a 48 MHz clock. I used a 20 MHz crystal, 15 pf caps, and a 330 ohm resistor. The clock statement is:

Code:
#use delay(clock=48M, oscillator=20M)


I also defined a fuse of HSPLL. It won't oscillate. It will oscillate when I use the HS fuse and change it to:

Code:
#use delay(oscillator=20M)


But of course that won't work for USB.

My compiler is 4.083. I know this is old but it works fine for everything I have done so far. Is it possible there is a problem that has been fixed in later compilers? The program compiles, loads, and runs with no errors or warnings.

I'd appreciate any insight to what could be the problem.

Thanks, Russ
Ttelmah



Joined: 11 Mar 2010
Posts: 19504

View user's profile Send private message

PostPosted: Fri Jan 28, 2011 11:01 am     Reply with quote

HSPLL, does not mean 'use the PLL' on a USB chip. The PLL is always enabled for USB. It means take the CPU frequency from the PLL.
Have you tried:

HSPLL, PLL5, CPUDIV1, USBDIV, VREGEN, NOXINST
#use delay(clock=48M)

In fact USB _will still work_, with HS, but you still have to add PLL5, to say that the USB section should use the /5 divider.

So HS, PLL5, CPUDIV1, USBDIV, VREGEN, NOXINST
#use delay (clock=20M)

is also legal, running the CPU at 20MHz, and the USB at 48MHz. Both assuming you do want the USB VREG enabled internally (you are not providing 3.3v externally). Obviously with MCLR, or MOMCLR, according to what you are doing with the MCLR pin.

Obviously, cap and resistor, depend on _your_ crystal, and it's gain. Try reducing the resistor, if the gain is not high. 50R, is fairly common for some 20MHz crystals.

Best Wishes
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

PostPosted: Fri Jan 28, 2011 12:11 pm     Reply with quote

First off, thank you Ttelmah. I used:
Code:
HSPLL, PLL5, CPUDIV1, USBDIV, VREGEN, NOXINST
#use delay(clock=48M)


And the oscillator works just fine and it straightened out some problems I was having with rs232 serial comm and timers.

Next, where does one find out the information on the fuses you specified? I see them in the header file, but no explanation as to their use. I find USBDIV as one of the bits in the CONFIG1L register in the data sheet. But I can find no reference to PLL5, VREGEN and NOXINST in either the data sheet or in the CCS compiler documentation.

I can figure out what PLL5 does, but VREGEN and NOXINST are a mystery to me.

I have never run into having to specify anything more than HS or HSPLL, along with the #use delay statement before. So I had no idea that it was necessary to specifify individual fuses for the divide ratios. I thought the CCS compiler figured all that out for me from the HSPLL and delay statements.

So, thanks again, but I'd really like to be able to figure this all out for myself and I don't know where to learn it.

Russ
gpsmikey



Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA

View user's profile Send private message

PostPosted: Fri Jan 28, 2011 12:59 pm     Reply with quote

Assuming you installed in the standard location, in the C:\Program Files\PICC directory, you will find a text file called "fuses.txt" that lists the fuses and a brief description. Thanks to whomever it was that pointed that out some time ago when I had the same sort of question Laughing

Hope that helps

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Fri Jan 28, 2011 2:40 pm     Reply with quote

Basically, you'll find all informations about fuses in the Microchip datasheet of your processor.
In some cases you may have difficulties to refer CCS fuse names to Microchip ones, as a last resort,
you can utilize MPLAB to figure it out.
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 6:16 am     Reply with quote

Thanks gpsmikey and FvM. I didn't know about the fuses.txt file either, and glad to find it. Very useful.

Now I am wondering about NOXINST. It disables the extended instruction set. Why do this? It seems to me that if a program uses the extended set, then it is used and of not, not. And is there a disadvantage to having it enabled?

FvM suggested MPLAB, and I have been wondering if I should invest in that. I only use the CCS tools so far, but I find the debugger very problematical. It is tantalizingly good, but suffers from a lot of bugs that sometimes drive me crazy. I have been wondering if everyone else notices the same problems. Is MPLAB a lot better, easier to use, or what?

(For an example of the problems in the CCS debugger, try reading the value of a global structure, or it's address. Usually results in an error message. The thing is that it also sometimes works, so I can never know whether I can depend on it. Often when I try to read the value of a variable it gives wrong value. Sometimes with mouse over I will get a execution error when the mouse happens to be over something it doesn't understand. Often the stepping does not work, the debugger steps to the start of the program. If you try to step again, it either just runs, or else will step into one of the interrupt routines. Just frustrating!)

Thanks again, Russ
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 7:26 am     Reply with quote

MPLAB is free, and it would be already worth installing it, if you only use the simulator for some tests.
I'm using MPLAB with Microchip programming/debugging adaptors.

My assumption for XINST would be, that they are unsupported by ´CCS C.
Ttelmah



Joined: 11 Mar 2010
Posts: 19504

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 7:42 am     Reply with quote

Enabling XINST, changes the behaviour of some standard instructions. CCS, does not use XINST, and if it is enabled, the code will almost certainly fail to work as expected. Do not enable it, if you want CCS code to work.

On MPLAB, it's simulator, while limited in some ways, is the best one around. There seem to be some oddities/bugs with the latest version, but probably 95% of people here will have MPLAB, and most 'old hands', _will_ use it in some way, even if only to look at fuses etc..

Best Wishes
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 8:02 am     Reply with quote

FvM wrote:
MPLAB is free, and it would be already worth installing it, if you only use the simulator for some tests.
I'm using MPLAB with Microchip programming/debugging adaptors.


I do all my work from MPLAB too.

I use ICD's and CCS right from MPLAB.

It's a nice setup.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
russk2txb



Joined: 30 Mar 2008
Posts: 109
Location: New Jersey

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 8:25 am     Reply with quote

Thanks Ttelmah, I wonder if not having the ex inst set disabled has anything to do with the unstable operation of the CCS debugger. I will certainly have to try that.

And I guess I better get MPLAB and give it a try.

Thanks to all,
Russ
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 8:28 am     Reply with quote

CCS doesn't support the extended instruction set - period.

NOXINST is what you want and is enabled by default (from what I've seen)

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
temtronic



Joined: 01 Jul 2010
Posts: 9224
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 29, 2011 8:34 am     Reply with quote

If you don't already know when using MPLAB as a 'conduit' to burn PICs with a Picstart Plus programmer(or others), you'll have to change the build option from 'debug' to 'release' and recompile the code THEN download into your PIC.
Currently the default is 'bebug' and cannot be saved as 'release'.
MPLAB dev. team has told me this will be a user option in the next release of MPLAB.When he called , he never knew that anyone programmed PIC the way I do.
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