UART & RS232 are feaking me out!! plzzzzz HELP !!!

[ayoubw]

uart to rs232

hello guyz,

I'm trying to interface a UART with a RS232 port. It's not my first time that i communicate with a microcontroller through a serial port, but this time it's driving me crazy!!
I successfully wrote a firmware for the microcontroller, to continually send letter"A" to the serial port (just for testing purposes now). I'm using visual basic to read the data coming from the UART. The thing is that I'm not getting a stream of continual A's all the time .. sometimes i'm getting a stream of continual P's, orthertimes, a stream of T's, other times i'm getting a stream of *'s .. what could possibly be the problem for this?
note:
1- i tried changing the whole controller board with another one & got the same problem.
2- tried to exchange the UART-to-RS232 cable.. same problems happened ..
3- tried interfacing the board with 2 different computers .. and still SAME PROBLEM!

please.. I would appreciate any kind of help!

cheerz,
AYOUB

 

[SphinX]

Salam,

May be the baud rate is not configured correctly. check it.

Put your transmit and the VB receive codes and the crystal value. I will help you

Bye

 

[eltonjohn]

Ok there are two possilities ..Either is the transmitting circuit or the receiving circuit
Usually the miscaluclation or programming on the microntroller side is the cause .
Assuming that you inverted the signal with a rs232 driver or at least with a transistor ( what about this?) check with the scope if you have a pattern comming out ..does it really look like the letter A?
ok check the a pulse duration of a bit .. ? There is no more !
either your TX line is not inverted with a Rs232 driver or as the last person said your BAUDRATE speed is not right and doesn't mach the one on the PC side .
use a Terminal program to try it and change speeds .. don't use any flow control

good luck

 

[davorin]

Would be good if you would post your serial code from your microcontroller and tell us at what CPU clock it runs...or what baudrate you configured if it has a special UART periphal built-in..


From the bitstream you mention (I assume all uppercase letters APT) I suspect some incorrect timing in start/stop bit...polarity from the 8-bit data seems okay...


But without any further info from you we just can guess (o;

 

[echo47]

Stop pulling your hair out. That's the old "ambiguous start bit" problem common to all serial communication. When you transmit a simple repeating pattern, and you start the receiver after the transmitter (or some noise occurs), the receiver has no way to determine which one of those zero bits is the real start bit.

I have seen many commercial products fail due to this phenomenon. Most engineers are unaware of it.

Try sending semi-random data, where all the data bits occasionally turn 1. Or pause occasionally between bytes. Or send two stop bits. Those tricks help the receiver fall into sync.

 

[ayoubw]

Hello ALL,

I thank you all for your replies ...
OK, now, I'll explain the problem in more details ..
I'm attaching few lines of the UART intialization as received from a team member ..
We use an old microcontroller Motorola MC68k, with the MC68681 UART with 9600 Baudrate.. probably most of you might not be familiar with it, hence I'm going to write what each line does..

Firmware:
---------
START ORG $400400
DUART EQU $A00001
MR1A EQU DUART+0 *Mode Register Port A
MR2A EQU DUART+0 *Mode Register Port A
SRA EQU DUART+2 *Status Register Port A (read only).
CSRA EQU DUART+2 *Clock Select Register Port A (write only)
CRA EQU DUART+4 *Commands Register Port A (write only)
TRBA EQU DUART+6 *Receiver Buffer Port A (read only)
TBA EQU DUART+6 *Transmitter Buffer Port A (write only)
ACR EQU DUART+8 *Auxiliary Control Register

*************************************
* INTIALIZE PORT A FOR TRANSMITTING
*************************************

SETPA MOVE.B #$10,CRA * Reset Mode register pointer to MR1
MOVE.B #$80,ACR * Sets the Auxiliary Register to baud rates Set2 (includes the 9600 baudrate)
MOVE.B #$BB,CSRA * Set to 9600 Baud
MOVE.B #$93,MR1A * Setting Mode Register to 8-Bit , No Parity, RxRTS_Control Enabled, Block Error Mode, RxIRQ =RxRDY
MOVE.B #$37,MR2A * Normal Operation Mode, 1 Stop Bit, Tx RTS Control Enabled, CTS Enables Transmitter=Enabled
MOVE.B #$05,CRA * Enables Tx & Rx on Port A for operation
NOP * Wait
REPEAT MOVE.B #$41,TBA * Send the ASCII for the "A" character to the transmit register
BRA REPEAT * repeat forever just for testing purposes


NOTE: The ready-to-send, and clear-to-send wires are connected directly together ..


Visual Basic Code:
------------------
Private Sub Form_Load()
Timer1.Enabled = True
Timer1.Interval = 500
MSComm1.CommPort = 1
MSComm1.Settings = "9600,n,8,1"
If MSComm1.PortOpen <> True Then MSComm1.PortOpen = True
End Sub

Private Sub Timer1_Timer()
Text1.Text = MSComm1.Input
End Sub



I'm suspecting something to be wrong with the transmitting microcontroller coding, which I couldn't figure out what it would be, probably with handshaking signals. The case i'm facing is that: when I run my VB program, I get a stream of "PPPPP" (instead of "AAAA"), if I close, and run again I get a different stream sometimes it's "AAAA", other times it's "TTTTT" or "******".

echo47 .. thanx for ur reply, you have a point .. we have to try your suggestion, and get back to you..

anyways.. here's the problem with more details, I thank you again for your replies, and more suggestions are welcomed

cheeerz,
AYOUB

 

[Regnum]

Dear ayoubw,

First of all, you're testing the firmware with a software that could be wrong, so it turns out harder to identify the problem source (is it the firmware or software...???)
Rather than the VB application, I'd use any terminal-emulation software to watch what the MCU is sending.
I suggest you to download TeraTerm-Pro from https://www.tucows.com/preview/195282.html

Regards.

 

[echo47]

Your software is probably fine. The bogus P T * characters are strong evidence that you are experiencing the ambiguous start bit phenomenon. Notice that by picking a different 0 start bit, you get those exact bogus characters. I'll bet you also got 0x15 and 0xA8 characters too.

Tx AAAAA  01000001010100000101010000010101000001010100000101
Rx AAAAA  010000010 010000010 010000010 010000010 010000010
Rx PPPPP    000001010 000001010 000001010 000001010 000001010
Rx TTTTT      000101010 000101010 000101010 000101010 000101010
Rx *****       001010100 001010100 001010100 001010100 001010100

I blanked the Rx stop bits because most UARTs ignore stop bits, except maybe to set the framing error flag.

This phenomenon has caused many engineers to go crazy trying to find a non-existant software bug. They never suspect a fundamental flaw in the serial protocol.

 

[Ten Y Dash]

I'm wondering, to solve the the ambiguous start bit problem, you mentioned sending a bunch of 1's first that way the first 0 it the rx recieves should be the start bit of your transmission. Is there an easy way to do this with hardware, i.e. putting a pull-up resistor of some sort before the rx.

thanks

 

[C-Man]

ayoubw,

maybe I am a little late and you have figured out everthing by yourself?

But looking at your code (and I am not an expert for your CPU):
REPEAT MOVE.B #$41,TBA * Send the ASCII for the "A" character to the transmit register
BRA REPEAT * repeat forever just for testing purposes

makes me wonder if you do not have to wait until the USART is ready for the next byte instead of stuffing bytes in an endless loop with much higher speed then the USART can send them out.

I think you get a classic overrun problem as you are giving the USART much more data then it can send out.

hope this helps and best regards

 

[ayoubw]

hello,

echo47 ... u are my saviour !! thanx a lot !! it worked out! just needed to make a delay loop after sending the character .. and it all worked out !!

C-Man .. to tell u the truth i'm not an expert in UARTs, it wasn't me actually who wrote the assembly code in the first place .. but probably what u r saying is true .. what we are doing is that we are connecting the CTS to the RDY pins to simulate the ready to send signal comming .. and with the small delay we placed between the characters, it all worked out..


thanx a lot everyone for the help!

cheerz,
AYOUB

 

[echo47]

I'm wondering, to solve the the ambiguous start bit problem, you mentioned sending a bunch of 1's first that way the first 0 it the rx recieves should be the start bit of your transmission. Is there an easy way to do this with hardware, i.e. putting a pull-up resistor of some sort before the rx.

thanks

Some tricks I've used:
- Occasionally send an 0xFF byte, if the receiving device won't mind.
- Send two stop bits instead of one.
- Pause occasionally between bytes (most systems do this naturally, which is why very few people experience the problem).

 

[otakung]

Excuse me echo47,
I don't understand why

Tx AAAAA 01000001010100000101010000010101000001010100000101

In my thought,
Start bit = 0
A = 41H = 01000001
Stop bit = 1
So it should be 001000001100100000110010000011 repeat and repeat, shouldn't it?

Maybe I miss some informations about RS232 so I don't understand your pattern.
Thank you for answers.

 

[echo47]

otakung, the UART sends the least-significant bit first.

 

[otakung]

arrrr, sorry i forgot it. lease: