|
|
View previous topic :: View next topic |
Author |
Message |
pkeberly
Joined: 28 Feb 2009 Posts: 3 Location: Michigan
|
Silly Serial Error? |
Posted: Sat Feb 28, 2009 5:22 pm |
|
|
I've been working on a project that need a serial link between 2 PICs, I just can't seem to shake the errors out?
I fell back to a basic RDA isr to echo test from a PC, but still a few errors? I doesn't appear to be hardware as the edges look great.
18F4431, 40Mhz (10 Mhz resonator w/PLL) MAX232N (from TI).
10 feet of 3 conductor Belden shielded wire, Pins 2,3,5 shielded on the PC side.
Solid 5V power supply, bypass caps on regulator, micro & MAX.
Checked the grounds, flashed and removed the ICD.
For the test I'm using a Windoze terminal (Bray Terminal) to spew out a dozen '5's.
Most of the time it works, too often(1 out of 3) I get an error or 2, sometimes more?
Even if I spew 2 chars, the error rate goes way down, but still there.
I've tried 19.2K & 9600, no real diff in the number of errors.
There has to be something silly I've overlooked!
Any thoughts?
Code: |
//************************************************************************
// serial_Test.c
//
// 02-2009 Paul Keberly copyright 2009 BloomLakeFarms.com
// Warning! Unauthorized copying or distribution of this material is just plain foolish!
//************************************************************************
#include "18f4431.h"
#device ADC=10
#device WRITE_EEPROM=ASYNC
#device HIGH_INTS=TRUE
#fuses HS,NOWDT,NOPROTECT,NODEBUG, MCLR, PUT
#use delay(osc=10M, clock=40M)
#use fast_io (a)
#use fast_io (b)
#use fast_io (c)
#use fast_io (d)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
void main(void){
int16 test;
set_tris_a(0xFF);
set_tris_b(0x00);
set_tris_c(0xDF);
set_tris_d(0xDF);
enable_interrupts(INT_RDA); // RS232 interrupt
enable_interrupts(GLOBAL); //
while(1){
test++; // do something?
}// end of while()
}// end of main()
#INT_RDA
void RDA_isr(){
char key;
key = getc();
if(key=='5'){
putc('6');
}
else{
putc('X');
}
}// end of RDA_isr()
|
|
|
|
Guest
|
|
Posted: Sat Feb 28, 2009 6:59 pm |
|
|
Have you tried it with the PLL set to 1 (disabled)? Maybe there is some timing jitter? Are you using an external resonator? |
|
|
pkeberly
Joined: 28 Feb 2009 Posts: 3 Location: Michigan
|
|
|
Ttelmah Guest
|
|
Posted: Sun Mar 01, 2009 3:26 am |
|
|
Get rid of the line 'high_ints=true'. This should not be used, unless you are using high priority interrupts, and can generate some really odd errors.
Your resonator looks as if it should be OK. Personally, I'd still use the 'old' nomenaclature, and simply specify HSPLL, and clock=40000000. However this appears to be wrking.
On purely 'avoid assuming anything' grounds, I'd actually specify the word length, and parity settings.
The description though sounds like some form of noise, or timing tolerance problem. I'd look carefully at the layout round the resonator. How good is the ground etc., and how close is it to the PIC?. Look at the Microchip application notes about PCB layout round this area, especially removing the ground plane under the actual oscillator pins. You mention bypass caps on regulatator, but what about a bypass cap on the PIC itself. You have to remember that the logic switching inside these at 40MHz, generates tiny transients, that need to be supressed close to the chip.
Try with the PLL turned off. If this works, add a series resistor between the CLKIN pin and the resonator. The PLL on some PICs (mainly older models than yours), can exhibit 'oddities', if overdriven. The gain of the resonator is not specified, and it might be quite high.
You can test your 'real' clock rate, by doing a simple 'output_high', wait for perhaps ten seconds, then output_low, and test the actual pulse time with a stopwatch. If it is not within 9.9 to 10.1 seconds, then you have found the problem...
Best Wishes |
|
|
pkeberly
Joined: 28 Feb 2009 Posts: 3 Location: Michigan
|
|
Posted: Sun Mar 01, 2009 8:30 am |
|
|
Guest, Thanks.
This morning I tried running w/o the PLL, that worked!
I just sent 20K chars without a miss, I can live with that.
Now I see why the resonators are $0.28 each.
Ttelmah, Thanks to you too.
I thought the resonator looked good also?
You are correct, the problem felt like a timing issue, but the slow baud rate errors didn't line up with noise, and didn't scale with speed. I've used CCS & PIC combo for years now without issues like this.
This project is wired on a Vector board, no ground planes. I am very careful about a bypass on everybody, I've chased the "maybe" glitches before.
Good trick on the long pulse, I wish I had thought of that! I don't have enough resolution on my home 'scope to see any wiggle in 10Mhz.
Instead of the stopwatch, I could use the 1 PPS output from my GPS receiver to compare.
I'll try the resistor in series, I have a bag of these resonator and hate to send them to the landfill.
Thanks all!!
Paul |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Sun Mar 01, 2009 9:14 am |
|
|
Look into a series resistor for your resonator. The resonators themselves are probably fine. It is the PICs with PLLs that are finicky about drive levels. I didn't see much on the resonator datasheet, but study the clock section of the PIC datasheet. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Guest
|
|
Posted: Sun Mar 01, 2009 9:24 am |
|
|
Glad to help, especially for a fellow Michigander
I'm no expert on PLL's, but here is what I think was happening. The PLL is trying to generate a high speed clock and sync it to the incoming pulses from the resonator. If the incoming clock has some jitter, then the PLL gets confused and amplifies the jitter (oscillates?)
If you need the speed, I would suggest a crystal or a canned resonator for more accuracy. Also, pay close attention to the layout and lead spacing, as the previous poster mentioned. Breadboards and stripboards don't make it any easier.
I've been having similar issues trying to do rs232 with the internal oscillator. The overall timing looks very good, but I get lot's of errors. |
|
|
Ttelmah Guest
|
|
Posted: Sun Mar 01, 2009 10:45 am |
|
|
I'd say that the overdrive is the most likely thing.
Unless poorly designed, a PLL, won't worry about a little jitter. In fact this is the great thing about them for many applications, where you can (for instance), track the fundamental frequency of a FM signal, despite the frequency being modulated.
What seems to happen, is that if the PLL input is overdriven, it tries to lock onto harmonics produced by the clipping. It then has trouble maintaining lock, and frequencies become unstable.
Best Wishes |
|
|
Guest
|
|
Posted: Sun Mar 01, 2009 12:16 pm |
|
|
Good info, thanks... |
|
|
|
|
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
|