485 comm, problem found

[new2pic]

I am swapping out a 17C756 with a 18F4610. There are no errors with the 17C756. With the 18F4610 I will however get "comm errors" about 10% of the time. The other 90% of the time everything works fine. I have also found that sending certain byte combinations can increase these "comm errors" to more like 50% of the time. I have a slave board that has one of its outputs connected to one of its inputs, so when the output is on, the input is on. I tell it to turn the output on, it turns it on, then i ask it if the input is on and it tells me yes (most of the time). These are the comm errors (when i ask it if the input is on and it is on but it tells me that it is not). My registers are as follows:
TXSTA = 0x26;
RCSTA = 0x90;
BAUDCON = 0x00;
SPBRG = 15;
ADCON1 = 0x0F;
PORTC = 0x00; // clear portc
TRISC = 0x9D;
(also I read/clear the RCREG upon initialization)
I have a 14.7456MHz clock, and Buad Rate of 57.6kHz. I have confirmed my baud rate and consulted the data and errata sheets to the best of my ability. I have noticed an inconsistancy between the 17C756 and the 18F4610. With the following code:

Transmit(0xFE); DelayIt(20);
Transmit(0xFE); DelayIt(20);
Transmit(0xFE); DelayIt(20);
Transmit(0xFE); DelayIt(20);
Transmit(0xFE); DelayIt(20);
Transmit(0xFE); DelayIt(20);
void DelayIt(unsigned char time)
{
while (time > 0)
time--;
}

//For the 17C756

void Transmit(unsigned char data)
{
BSR = 4;
while(!TRMT2);
TXREG2 = data;
}

//For the 18f4610
void Transmit(unsigned char data)
{
while(!TRMT);
TXREG = data;
}

When I look at the TX line of the scope I notice a convenient difference between the two . I do not know what is causing this but believe it has something to do with the errors that I am getting. Do you know what may be the explanation for this?

Unfortunately I can not figure out how to add an attachment but the basic picture shows that for the 17C, the line is high, goes low for 35microseconds, high for 139microseconds, low for 35 microseconds,.....
However, the 18f, is high, goes low for 35microseconds, then high for 156microseconds, low 35...
and (156-139)micro=(1/57.6k)
Any help or ideas would be greatly appreciated. I apalogize ahead of time if I dont fully understand your replies, im kinda new2pic among other things.

[Ttelmah]

Firstly, neither scope 'timing' is right. However this may well be innaccuracy in the scope, unless this have been accurately calibrated recently....
'FE', should have seven bit times low. At 57600bps, this is:

7/57600 second. 121.5uSec

Now if I assume that the scope is 14% out of calibration, and therefore is showing '139uSec', for a 'real' value of 121.5uSec, then the 156uSec 'reading', is actually 136uSec. This is far enough 'out of spec', to give serial errors (12.2%).
You say you have 'checked the baud rate'. Do you mean that you have actually stuck a frequency meter on the output, and tested the frequency being generated?. Alternatively, try a simple program, that uses a simple long time delay, and toggles a pin. Check this with a stopwatch. I suspect you are going to find that the chip is running perhaps 12% 'off frequency'.
One possibility is that your crystal has too much gain. The oscillator on latter chips like the 18F4610, has higher gain than that on the older chips. When these chips first appeared, there were a _lot_ of people who had problems getting the chips to run 'on frequency'. This has declined with latter releases, but may still apply to some chips. The solution most commonly used, is to add a series resistor to the crystal, to reduce the signal fed back into the chip.

Best Wishes

[new2pic]

are there any other things that could cause this, perhaps with the chip configuration, not a hardware problem or scope problem or osillator problem or any other external problem?

[Humberto]

[new2pic]

I dont understand what is meant by this? Toggle a pin on and off to make a square wave? how do you toggle it, from a timer interrupt program? I do not know how to create an accurate delay program unless it is using a timer.

[new2pic]

I think the long 'high' stretch is 8 long, not 7 becuase it has the stop bit, is this correct?

[Humberto]

[new2pic]

still I dont have an accurate way to tell time. I have not been able to find a solid delay routine. I have checked my clock chip and its frequency is correct, if I transmit 1010 1010 with a leading low start bit and ending low end bit shouldnt this give me 57.6kHz?

[Humberto]

[new2pic]

is the code in assembly?
also
delay_ms(10000) is a function right? wouldnt i need the function definition and prototype?

[new2pic]

I have been looking at my tx and rx lines on the scope. I am comparing the readings from the 18f4610 to the ones on its predecesor, the 17c756(which is proven communication). On the transmit, either the stop bit is twice is long or there is a 1 bit wide idle time for some reason, this is odd but should not create any errors only slow me down. So I transmit to my slave (the18f242 that was previously the slave when the 17c756 was the master) asking it if its input is on, it responds and on my rcv line i get the correct response (4 bytes long). The input is off and so the 4th bit should be a zero which it is, however, sometimes my 18f4610 says that it is a zero and sometimes it says that it is not. Any ideas

[Humberto]

Well, we didn�t get any feedback of the suggested actions.

[new2pic]

If TX9 (9-bit Transmit enable bit) and RX9 (9-bit Receive Enable bit) are both set to zero = Selects 8-bit transmission/reception. How could I be sending 9-bits, and how would that 9th bit be set high? Im not sure what you mean by the suggestions, you suggested a time delay test but did not tell me how to do it. All of this stemmed from buad rate. If I am comparing the 18 to the 17, the 17 is perfect, so if the 18 looks identical to the 17 but stays high at the end for 1 bit longer, then the 18 is transmitting just fine but takes 1 bit longer between bytes. I think we have determined that the scope is not off and niether is my baud rate generation as the bits are consistantly all exactly as wide as they should be, right?

[Ttelmah]

The 'time delay test', is so basic, that I don't think anyone can believe you don't know how to do it. Delays are available as standard operations in CCS C, so it is just a matter of (for example), writing:

[new2pic]

im using regular c in hitide, so there is no premade delay_ms function. but if my pulse/bits are correct (correct width in seconds), there isnt a need to do a delay check to see if my clock is correct. right?