Async serial receive (getc()) problem ...

Thomas Blake · Guest

... with PCM 3.092, ICEing with Tech-Tools Mathias 5.1.1.

16F873, internal SCI. 8 or 9 bit configurations have the identical problem, except of course involving RX9D when 9-bit is coded.

The low nibbles of received data are always correct. The high nibbles are garbled, i.e. 0x83 received as 0x33 and 0xC0 as 0x80, so it's not just a shift. I implemented a simple incrementing program on the sending computer and this problem is absolutely stable and predictable. There are no errors reported in RCSTA, and when I purposefully forced a framing error it was properly reported, so RCSTA seems to be telling the truth.

I checked SPBRG and it contains the proper value of 2 for baud=19200. In fact the entire receive sequence looks OK in the compiler output. I have also tried 3 different baud rates. It is now simplified to 9600-N-8-1 for testing. The serial send is from a Windows PC.

Yes, the serial information coming in is good, unfortunately. :( I'm using SerialTap98 on a second computer to snoop the line and a scope to check levels and transition times.

I realize this probably isn't CCS's fault, but can anyone shed some light on this?? Thanks ....
___________________________
This message was ported from CCS's old forum
Original Post ID: 10878

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

:=... with PCM 3.092, ICEing with Tech-Tools Mathias 5.1.1.
:=
:=16F873, internal SCI. 8 or 9 bit configurations have the identical problem, except of course involving RX9D when 9-bit is coded.
:=
:=The low nibbles of received data are always correct. The high nibbles are garbled, i.e. 0x83 received as 0x33 and 0xC0 as 0x80, so it's not just a shift. I implemented a simple incrementing program on the sending computer and this problem is absolutely stable and predictable. There are no errors reported in RCSTA, and when I purposefully forced a framing error it was properly reported, so RCSTA seems to be telling the truth.
:=
:=I checked SPBRG and it contains the proper value of 2 for baud=19200. In fact the entire receive sequence looks OK in the compiler output. I have also tried 3 different baud rates. It is now simplified to 9600-N-8-1 for testing. The serial send is from a Windows PC.
:=
:=Yes, the serial information coming in is good, unfortunately. <img src="http://www.ccsinfo.com/pix/forum/sad.gif" border="0"> I'm using SerialTap98 on a second computer to snoop the line and a scope to check levels and transition times.
:=
:=I realize this probably isn't CCS's fault, but can anyone shed some light on this?? Thanks ....
-------------------------------------------------------

Post a small, complete program that demonstrates the problem.
Be sure to post the #fuse statement, #use RS232 statement,
#include statements, etc. Don't leave anything out.

Also, tell us what you're using to provide the PIC's clock.
Is it a crystal, or a resonator ? If a resonator, give the
manufacturer and part number.

What chip are you using as an RS-232 level translator ?
___________________________
This message was ported from CCS's old forum
Original Post ID: 10879

Neutone · Joined: 08 Sep 2003 Posts: 839 Location: Houston

:=... with PCM 3.092, ICEing with Tech-Tools Mathias 5.1.1.
:=
:=16F873, internal SCI. 8 or 9 bit configurations have the identical problem, except of course involving RX9D when 9-bit is coded.
:=
:=The low nibbles of received data are always correct. The high nibbles are garbled, i.e. 0x83 received as 0x33 and 0xC0 as 0x80, so it's not just a shift. I implemented a simple incrementing program on the sending computer and this problem is absolutely stable and predictable. There are no errors reported in RCSTA, and when I purposefully forced a framing error it was properly reported, so RCSTA seems to be telling the truth.
:=
:=I checked SPBRG and it contains the proper value of 2 for baud=19200. In fact the entire receive sequence looks OK in the compiler output. I have also tried 3 different baud rates. It is now simplified to 9600-N-8-1 for testing. The serial send is from a Windows PC.
:=
:=Yes, the serial information coming in is good, unfortunately. <img src="http://www.ccsinfo.com/pix/forum/sad.gif" border="0"> I'm using SerialTap98 on a second computer to snoop the line and a scope to check levels and transition times.
:=
:=I realize this probably isn't CCS's fault, but can anyone shed some light on this?? Thanks ....

Is your crystal really what you think it is? If your crystal is out of spec it might explain the problem you are seeing.
___________________________
This message was ported from CCS's old forum
Original Post ID: 10889

Thomas Blake · Guest

That gave me pause ... so I put a frequency counter on it. It's a TCXO module and it measures within 20ppm of the specified frequency. However, I'm dumbing out here because I already have two commercial products containing F873s using SCI so I know it works perfectly well. I implemented a small loopback program, you know, putc(getc());, and found that the emulator is actually performing more-or-less correctly but reporting the wrong values. There are more framing errors than one would want but on the whole I'm laying this at the door of the Tech-Tools ICE, because the other two SCI-containing projects I mentioned weren't debugged with this tool. Does anyone else here use Tech-Tools Mathias?
___________________________
This message was ported from CCS's old forum
Original Post ID: 10957

Thomas Blake · Guest

The ICE doesn't use the target clock and its own clock was set to 4 MHz rather than the 3.6864 of the target ...
___________________________
This message was ported from CCS's old forum
Original Post ID: 10973