RS232 comm problems.

[shipleyg]

Using MPLAB V8.4
CCS PCM V4.071
PIC 16F877
Windows 7
Labview V9.0 code running on PC.

Using UART RC7 as RX and RC6 as TX 9600 8N1

Labview code sends ascii string to PIC, PIC reads it in via rda interrupt and then echos back for an acknowledgement. Problem is, sometimes the acknowledgement does not happen. Most of the time it does. I have ERRORS placed in the rs232 call.
Any thoughts on this? Perhaps a timing problem? sending back to windows too fast? I think the Labview code is solid. Just seeing if I am missing something on the PIC side.

[Mike Walne]

Hook up a digital 'scope to PIC RX and TX, trigger on PIC RX.

Set 'scope to normal trigger mode, and time-base slow enough to capture both RX and corresponding TX.

Get lab-view to send characters repeatedly, and stop when no return signal.

The 'scope will tell you where to look after lab-view stops.

Mike

[Ttelmah]

Problem is that with a scope, it'd might be quite easy to miss the odd time when the event goes wrong. It is (for instance) possible that the fault is triggered by the packet 'before'.
If you have access to an inline RS232 monitor box, or a digital logic analyser, use this instead. Or you can parallel another serial port on another PC to monitor the lines.

Difficult to 'know' without knowing what you do in the serial code, but some 'for instance' scenarios may apply:

1) Is Labview possibly asserting a handshake for a moment, saying 'hold it', and if your PIC doesn't handle this, it could be sending when it shouldn't. You might need to watch this line, and stop your transmission.
2) When the PIC sends the data back. What would happen if a second lot of data was arriving at the same time?.

Seriously, with interrupt driven RX _and_ TX, and properly designed hardware you should be able to have comm's that are 99.99999% reliable. There are many applications out there using the PIC, that have run successfully for years without losing a single character. It is down to design _at every level_. For instance, have you considered something like including a checksum, and having the PIC send back an 'OK' of this is correct, or a 'retransmit' request, rather than just echoing the data back, if something is wrong in this?.

Best Wsihes

[temtronic]

Other hardware checks include

1) proper ground connections.

2) correct caps for the MAX232 chip.

3) adequate +5 power supply for the PIC.

4) what else is the PC doing?

If possible, try a hardware loopback test. If the PC fails it's NOT a PIC problem !