| View previous topic :: View next topic |
| Author |
Message |
Allan
Joined: 20 Dec 2009
Posts: 23
|
| Can't turn on PLL without micro locking. |
 Posted: Fri Jul 09, 2010 10:08 am |
 |
|
Hi Everybody,
I'm using a 18f2321 with V4.109 compiler. I'm using a 10 mHz crystal.
When I configure the oscillator using this code the system works fine:
| Code: |
#use delay (clock = 10M, oscillator = 10M)
|
When I try to increase the clock speed by using the 4x PPL the microprocessor locks when I run this code
| Code: |
#use delay (clock = 40M, oscillator = 10M)
|
I know I've see a forum posting about this but I can't find it.
Any Advice?
Thanks. Al |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Jul 09, 2010 12:11 pm |
|
|
Post a short but complete test program that shows the lock-up. Maybe
just blink an LED. Post the #include for the PIC, #fuses, #use delay()
and main(). Are you testing this in hardware or in Proteus ? |
|
|
Allan
Joined: 20 Dec 2009
Posts: 23
|
|
| Posted: Fri Jul 16, 2010 9:24 am |
|
|
Hi Everybody,
It took me a few days to isolate exactly why my programs locks. This code demonstrates the problem: | Code: |
#include <18f2321.h>
#define UpArrowKey PIN_A6 //Up arrow
#define DownArrowKey PIN_B2 //Down arrow
#define FanDrive PIN_A0
#define Pressed 0 //Pull up resisters in use results in negative logic
#define Released 1 //so a button press returns a low.
#fuses PUT
#use delay (clock=40M,oscillator=10M)
void main()
{
while(1)
{
output_low(FanDrive);
delay_ms(10);
if (input_state(UpArrowKey) == Pressed)
{
output_high(FanDrive);
delay_ms(5);
output_low(FanDrive);
}
if (input_state(DownArrowKey) == Pressed)
{
output_high(FanDrive);
delay_ms(25);
output_low(FanDrive);
}
}
}
|
When I run this program with clock = 10M it does exactly what I expect - I can press the buttons and get the correct pulse output with excellent accuracy.
When I run this code with clock = 40M to enable the 4X PLL the first test is always true and I get a constant 5 mSec pulses. Pressing the 'Up Arrow' key has no effect and pressing the 'Down Arrow' key gives me a 30mSec pulse with a slight glitch between the two pulses.
I've run this on 2 different boards with the same date code chip (0929QDG), and both behave the same way. I'll try a different date code chip this afternoon.
There is nothing unusual about the support hardware - the output goes to a 74HC14 inverter and the inputs have a 4.7k resistor to +5 volts and a .1 uF cap to ground.
I've tried setting the H4 bit manually and other ways to configure the oscillator and the behavior does not change. I've used structures other than a while loop
Why would the clock frequency affect the first if statement?
Thank,
Al |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Fri Jul 16, 2010 11:17 am |
|
|
I just did this recently... and I found what worked was to switch to the secondary oscillator (I have T1OSC running at 32KHz)... enable the PLL and then switch back to the primary after a small delay....
Keep in mind, doing this mucks up things like the BRG settings -- so if (like me) you're using RS232, you'll see garbage unless you properly set the BRG's again.
I'm using a PIC18F46j11 and go through setting the system speed and then re-setting the BRG's for 40MHz....
Then when the function sets the system back to 10MHz, the BRG's are set again.
In my routine that sets the system speed, I tried using the #use delay again (as the docs say you can) but I think in the grand scheme, it's not a single function that's running fast or slow, I speed up the whole system and then slow it down -- so I don't think the #use delay is applicable for me.
delay_ms gets all mess up in the meantime because they are CCS calls.
Anyway... you get the idea. I do plan on calling them to ask how to maybe do this better in CCS... but I thought I'd share what I know already.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Fri Jul 16, 2010 1:48 pm |
|
|
Update:
I spoke with CCS a little more to confirm my own thoughts on how to handle this...
One solution for time delays (that use delay_xx() ) is to write your own that test for the PLLEN bit and then use one delay value or another.
This is where it's a little tricky -- we know that #use statements are valid for everything that follows... so with that in mind, we need to be careful to think about what we want.
An example of this might be:
| Code: |
void my_delay_ms ( size_t value ) {
if (PLLEN) {
#use delay (clock=40M)
delay_ms(value);
} else {
#use delay (clock=10M)
delay_ms(value);
}
#use delay (clock=10M)
}
|
I haven't tested this yet -- but it's about where I'd start.
As for things like hardware RS232 or I2C/SPI, I already have fixed that by resetting the Baud Rate Generators as needed and that works fine.
For software RS232 or I2C/SPI, a custom function would need to be made like the above with the inclusion of the #use rs232|i2c|spi
along with the routine that sends the information.
So I wouldn't call streams anymore, I would use printf(my_putc, "string");
And my_putc would include the fprintf to a channel.
Anyway - Hope all this helps you.
It's fun having a PIC that can save when in a battery powered environment, but not hog lots of power when mostly idle.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Allan
Joined: 20 Dec 2009
Posts: 23
|
|
| Posted: Fri Jul 16, 2010 8:43 pm |
|
|
Hi bkamen,
My friend / supervisor has been in touch with Microchip and the first thing they told him was to make sure the chip is certified for 40 mHz operation at the voltage used to run the chip - you may want to do the same.
My friend also saw a microchip forum post saying that the power needs to be cycled when the clock speed is changed - I'm not sure if that means inside a running program like you do or between programming and running the chip. I'll test that tomorrow.
I ran a different date code chip today and it also fails in the same way - that points towards a configuration issue.
Microchip want us to run a few other tests - I'll post any interesting results.
Al |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Fri Jul 16, 2010 9:22 pm |
|
|
Thanks for the tips.
I know the chip will run at 40MHz...
And no - there is no reset needed. I've successfully been running this on my bench for days now. So that poster on MCHP is probably not doing something right.
The idea behind being able to change clock speeds is to save power. (I know we all know that.) I bring it up only as a point that the XLP lines of PIC have this as a key feature.
In my case, Chp.3 - Low-Power Modes talks about this specifically.
I'm not having problems. I just have questions desiring a little more clarification concerning the compiler in use.
Right now, my system dynamically switches back and for from IDLE to running mode @ 10MHz and then up to 40MHz with no problems. It's grand.
If I'm asked to save more power, I'll probably ratchet down to sec-idle which will run the CPU at 32.768KHz. I laugh thinking about it.
Cheers,
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
