Why will 16F1823 not run at 32Mhz off internal RC Osc ?

[nurquhar]

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.

[nurquhar]

Found the problem.

Seems you have to use "normal" as the clock source not "internal".

ie the following setup works

[temtronic]

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.

[nurquhar]

Would accuracy be good enough for high speed UART comms ie 56k ->250k

[temtronic]

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.

[nurquhar]

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.

[FvM]

[temtronic]

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...

[nurquhar]

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 ?

[nurquhar]

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 .

[FvM]

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.

[Ttelmah]

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

[temtronic]

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 !

[nurquhar]

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.