Serial Comms

[David_UCT]

Hello

I'm using an MCF51JM128.  I have a strange problem with my serial comms.  I am sending data through a max232N chip to a PC serial port.

I have the SCI module set up at 9600 baud with no parity.

I am sending 0x1F repeatedly and I have checked using a scope to see if the data I'm sending is being sent correctly which it is.  However when I open a comms terminal on the PC side the data received will not always be correct. 

I will receive 0xF4, if I close the port and open the port numerous times I will receive the correct data eventually.  Does anyone know why this would be the case?

[TomE · Accepted solution]

> I am sending 0x1F repeatedly and I have checked using a scope to see if

> the data I'm sending is being sent correctly which it is.  However when I

> open a comms terminal on the PC side the data received will not always be correct.

If you open the comms program and THEN start sending the data, is it then OK?

If you are sending continuous asynchronous data and THEN open the comms program, how is the comms port meant to work out which bit in the data stream is the start bit? This is an ASYNCHRONOUS data transfer without any "framing patterns" of "flag bytes" (like hdlc and friends). There are only two things that determine which bit in the data stream is the start bit, and they are:

1 - The first bit after at least 10 bits of an idle line - of nothing being sent (with 8 bits, one start, one stop format).

2 - The receiver is properly synced up on the previous byte and has just seen its stop bit. The next low bit is the start bit of the next byte.

If you have to be able to start the serial comms while the embedded device is continuously transmitting, then have the latter add some gaps in transmission (of at least one whole byte time and preferably longer) every now and then. You should do this for robustmess even if you are synced up in case some noise on the line gets the receiver out of sync.

Tom

[David_UCT]

Thanks Tom

That sorted the issue out.

[TomE]

You could probably also get it synced up in a continuous data stream if it had a long enough run of non-start bits in it.

it is always tricky trying to remember the polarity of the data, start and stop bits, but this is a good example:

http://en.wikipedia.org/wiki/File:Rs232_oscilloscope_trace.svg

RS-232 levels (and not the opposite polarity "5V levels" that comes out of the chips) idles at a negative voltage, which is also the "ones" data bit values. The Start bit has the same polarity as a zero data bit.

So RS232 "idles at ones" so if you can send all-ones (0xff) bytes every now and then either without parity or with the right parity (odd, to result in a "1" parity bit) as part of the "framing" it should allow the PC receiver to re-sync.

Tom

[Balcer]

I do not know your actual setup but I can confirm weird transfer results using M52235EVB and an old Dell notebook with WinXP's default terminal app. Using hardware handshake (and no timeouts) I got few communication freezes after a day or two of transfer (my transfer normally took over 4 days to collect all data since it was slow BBS generator). Changing the app to RealTerm (or to Mac OS X CoolTerm) showed no more problems. I saw no difference in connection speed (most time using 19200 or 115k) vs quality. So in first (and easiest) shot my advice is to check the app you're using on the receiver side. 

[David_UCT]

Hi

Thanks for your response.  I have tried a number of different receiver programs including realterm and all produce the same results.

[stzari]

Hi,

without more information I can give just a few general tips.

- try using another terminal (Personally, I prefer Teraterm)

- try using another PC

- are you using a USB2Serial adaptor or a real serial port. If the first, try another type (we had real problems with quite a few of those adaptors)

- check the connections (Rx, Tx, GND) and try with a 3-wire connection first

- check the voltages (are they high/low enough ?)

- look at the signal on a scope and verify with what is to be sent

HTH

  Stamatis