![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
Why will 16F1823 not run at 32Mhz off internal RC Osc ? |
Posted: Tue May 31, 2011 2:55 am |
|
|
I have just started with the PIC16F1823 and so the first task was to just get it to blink an LED every 1 second when running at 32Mhz. Should be easy yeh
Having read section 5.2.2.6 of datasheet (http://docs-europe.electrocomponents.com/webdocs/0e24/0900766b80e24f04.pdf) it seemed that it is just a mater of configuring the PIC to select the 8Mhz internal osc and the x4 PLL.
However try as I might I can't get it out of bottom gear into top gear. ie it seems the PLL is not kicking in when OSCCON is setup.
I am using the current demo version 4.120d and the following simple code to test. My LED is blinking every 4 seconds, indicating it is running at 8Mhz instead of 32Mhz.
What could be wrong ?
When debuging with the ICD2 and I halt the program during the main loop I can see that OSCCON has been correctly programmed with 0xF2 which is what I expected the "setup_oscillator(OSC_8MHZ | OSC_INTRC | OSC_PLL_ON)" to do.
I have tried with the PLL config fuse forced on and under software control.
Code: |
#include <16F1823.h>
#device adc=8
//////// Program memory: 2048x14 Data RAM: 112 Stack: 16
//////// I/O: 12 Analog Pins: 8
//////// Data EEPROM: 256
//////// C Scratch area: 20 ID Location: 8000
//////// Fuses: LP,XT,HS,RC,INTRC_IO,ECL,ECM,ECH,NOWDT,WDT_SW,WDT_NOSL,WDT
//////// Fuses: PUT,NOPUT,NOMCLR,MCLR,PROTECT,NOPROTECT,CPD,NOCPD,NOBROWNOUT
//////// Fuses: BROWNOUT_SW,BROWNOUT_NOSL,BROWNOUT,CLKOUT,NOCLKOUT,NOIESO
//////// Fuses: IESO,NOFCMEN,FCMEN,WRT,WRT_EECON400,WRT_EECON200,NOWRT
//////// Fuses: PLL_SW,PLL,NOSTVREN,STVREN,BORV25,BORV19,DEBUG,NODEBUG,NOLVP
//////// Fuses: LVP
////////
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOCPD //No EE protection
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOMCLR //Master Clear pin enabled
#FUSES PUT //Power Up Timer
#FUSES BROWNOUT //Reset when brownout detected
#FUSES NOIESO //Internal External Switch Over mode disabled
//#FUSES IESO //Internal External Switch Over mode enabled
#FUSES NOFCMEN //Fail-safe clock monitor enabled
//#FUSES NODEBUG //No Debug mode for ICD
#FUSES DEBUG //Debug mode for ICD
//#FUSES WDT_NOSL
#FUSES NOWRT //Program Memory Write Protected
//#FUSES PLL // PLL Enabled
#FUSES PLL_SW // PLL under software control, disabled
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES BORV25 //Brownout reset at 2.5V
#FUSES NOCLKOUT //Output clock on OSC2
#define DEBUG_LED PIN_A5
void main()
{
unsigned long li ;
// Switch to internal 32Mhz Osc, ie 4xPLL x 8Mhz = 32Mhz
setup_oscillator(OSC_8MHZ | OSC_INTRC | OSC_PLL_ON);
// setup_oscillator(OSC_8MHZ | OSC_INTRC | OSC_PLL_OFF);
// Turn stuff off
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_dac(DAC_OFF);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(T0_internal);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_ccp1(CCP_OFF);
setup_comparator(NC_NC_NC_NC);
li = 0 ;
while(1)
{
// Blink the LED every second (approx) when running at 32Mhz
// ie 122 cycles * 65536 = 8,000,000 cycles (approx)
output_high(DEBUG_LED);
while(++li) {
delay_cycles(2) ;
}
output_low(DEBUG_LED);
while(++li) {
delay_cycles(120) ;
}
}
}
|
|
|
![](templates/subSilver/images/spacer.gif) |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
|
Posted: Tue May 31, 2011 3:03 am |
|
|
Found the problem.
Seems you have to use "normal" as the clock source not "internal".
ie the following setup works
Code: |
// Switch to internal 32Mhz Osc, ie 4xPLL x 8Mhz = 32Mhz
setup_oscillator(OSC_8MHZ | OSC_NORMAL | OSC_PLL_ON);
|
|
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9171 Location: Greensville,Ontario
|
|
Posted: Tue May 31, 2011 5:27 am |
|
|
also be aware the internal osc is NOT a crystal and NOT accurate or stable for 'time keeping' purposes or precision stuff like PWM, servos,etc. |
|
![](templates/subSilver/images/spacer.gif) |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
|
Posted: Tue May 31, 2011 5:42 am |
|
|
Would accuracy be good enough for high speed UART comms ie 56k ->250k ![Question](images/smiles/icon_question.gif) |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9171 Location: Greensville,Ontario
|
|
Posted: Tue May 31, 2011 6:54 am |
|
|
maybe, and I mean maybe at 56K but probably not at 250K. Check the datasheet to see the numbers as to why.
But it's real easy to prove,just cut an 'echo' program for the PIC,wire up to a MAX232 and to a PC running some type of terminal program. That should take maybe 15 minutes....For a good test , have the 'terminal 'program send data for 10-15 minutes and compare what it receives vs. what it sends, ANY errors will be a failure.
Start at a low baud rate, then go faster. You'll know when it fails.
If this is for a commercial product (or anything that needs to be 100% reliable) you'll need a crystal and 2 caps. |
|
![](templates/subSilver/images/spacer.gif) |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
|
Posted: Tue May 31, 2011 7:12 am |
|
|
I was aiming on getting my application down to the 8 pin DFN chip (12F1822) as the PCB is going to be pretty small with minimum component count. Two extra pins for a crystal would rule out the use of an 8 pin device and push it to a 16pin QFN to get the 5 i/o's I need. However the crystal would use as much pcb area as the PIC.
Do you think custom tweeking the value in OSCTUNE for each circuit could get the accuracy up to an acceptable level ? I am guessing that a lot of the frequency drift would be temperature dependant, althought the datasheet does'nt seem to give a ppm/deg c figure. |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue May 31, 2011 8:39 am |
|
|
Quote: | I am guessing that a lot of the frequency drift would be temperature dependant, althought the datasheet does'nt seem to give a ppm/deg c figure. | Did you notice the HFINTOSC FREQUENCY ACCURACY OVER DEVICE VDD AND TEMPERATURE diagram? |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9171 Location: Greensville,Ontario
|
|
Posted: Tue May 31, 2011 9:24 am |
|
|
Even IF tweaking was possible/acceptable for timing, the LABOUR and TIME for doing so will outweigh the cost of a different PIC and PCB.
Smaller is NOT better, reliability is ! especially for a commercial product where the 'other' guy may grab your market share.
Always try to use the next bigger PIC,customers or yourself will ALWAYS need another pin or feature....save money/labour/design costs now by using a bigger PIC... |
|
![](templates/subSilver/images/spacer.gif) |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
|
Posted: Tue May 31, 2011 9:29 am |
|
|
Looks like +/-2% for my target voltage and temp. Question is how far out does UART timing have to be to cause a frame or overrun error ?
Being 1 bit out would definatley cause the uart to get an error. Thats 10% off based on the assumption of 1 start, 8 data and 1 stop bit (total 10 bits). But would 1/2 or 1/4 bit out still cause an error ? ie 5% or 2.5% respectively.
Perhaps 2% is just enough to scrap under the fence ? |
|
![](templates/subSilver/images/spacer.gif) |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
|
Posted: Tue May 31, 2011 10:05 am |
|
|
This Maxim app not seems to cover the UART error subject http://pdfserv.maxim-ic.com/en/an/AN2141.pdf
I accept the points about "over engineering" things so your design has spare capacity and out performs the required spec.
However sometimes you have try and push to the edges to try and find what is possible.
"A man that never made a mistake never made anything". And I've made plenty of mistakes . |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue May 31, 2011 10:16 am |
|
|
Up to 4.5 % baud error can be accepted with a 8 data bit frame. It has to be shared between transmitter and receiver, so one shouldn't allow more than 2% for one side. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19363
|
|
Posted: Tue May 31, 2011 3:49 pm |
|
|
One thing not mentioned, that can help significantly, is the choice of baud rate.
Key thing is that the PIC only allows a limited number of dividers and prescalers. So (for instance), if you run off a 32MHz clock (8MHz for Fosc/4), and try to work at 115200bps, you want a division by 69.4444. The nearest that can be done is /69, so you start out with a 0.6% error before the clock changes. On many chips, especially with slower clocks, this error can become a significant fraction of the allowable range before the clock itself runs off frequency. Obviously potentially improves the error range in one direction, but makes it worse in the other. Now if you are free to choose baud rates, it is worth starting with one that is directly available from the clock. So for example 100000bps, would potentially be exactly available.
You might also look at the way the clock drifts, and choose a baud rate with an error, that is in the opposite direction....
So if the oscillator tends to slow with rising temperature, and you trim Fosc for the lowest likely temperature, and choose a baud rate/divider that errs on the 'fast' side, this should improve as the temperature rises.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9171 Location: Greensville,Ontario
|
|
Posted: Tue May 31, 2011 7:13 pm |
|
|
I've always had 100% reliability with the 1% rule. Do whatever you need to keep the baud rate clock <= 1% error rate.
Using 'oddball' crystals for exact divisor to get 0 error rate.
Use a faster crystal and descrete divider to improve the timing.
Use a 'canned xtal' for better performance.
Spend a few bucks NOW to save a LOT of grief later..
That way you never have to second guess yourself and wonder , will it work in the field like it does on the bench ! |
|
![](templates/subSilver/images/spacer.gif) |
nurquhar
Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK
|
|
Posted: Wed Jun 01, 2011 2:18 am |
|
|
Just a thought
My PIC application will be lots of circuits on a multi drop comms, so the "master" device can have an accurate crystal clock derived baud rate. Could the Auto-baud detect feature of the EUSART be used periodically to check the error between the actual baud of the PIC and the theoretical baud of the master. The difference could then be used to tweek the OSCTUNE value to bring the baud back to where it should be. ![Question](images/smiles/icon_question.gif) |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|