I am facing some embarrassing problems recently.
After some trouble-shooting, I found that: We have Board-A and Board-B. Board-A and Board-B communicate to each other with a UART TTL Level Communication. The communication cable is around 80cm long. During the communication, I got a lot of UART errors.
My mission is to build a more reliable communication between Board-A and Board-B; but not allowed to modify the hardware design and baud-rate.
To me, it is not wise to use a UART TTL Level Communication between two boards. However, I am being told that, it is very popular to us to use a UART TTL Level Communication between two boards.
I tried to find some articles/documentation to convince the involved people, that, they should not use a UART TTL Level Communication between two boards. But I can not find anything useful. What I could find is something like: The UART usually does not directly generate or receive the external signals used between different items of equipment.
My question is: Where can I find some convincing articles/documentation to convince the involved people? (This is to avoid the future problems.) If I am not allowed to modify the hardware design and baud-rate, what choices do I have to build a more reliable communication?
Not that this has anything at all to do with Keil...
"I got a lot of UART errors"
What kind of "UART errors", exactly? There are plenty of things that could cause errors besides the use of TTL signals...
Possible problems are: Noise pickup; Cable capacitance; Grounding problems.
You should be able to see them with an oscilloscope. If the signal is "clean" at the receiving end, then you have some other problem...
Hi Andy,
Many thanks for your help.
Most UART errors are Framing errors at the receiving end. (UART Framing error flag == 1)
With an oscilloscope, I can see that, at the transmitting end, the signal at MCU tx pin is clean (frequency 19.2xxkHz, square ware), but the signal at the middle junction of the cable is not clean (frequency 20.xxxkHz, wave with rounded corners).
"at the transmitting end ... frequency 19.2xxkHz ... at the middle junction of the cable ... frequency 20.xxxkHz"
How can just a cable change the frequency??!!
"the middle junction of the cable"
What do you mean by that? What is this "junction"?
"not clean"
What, exactly, do you mean by that?
As the late, great Bob Pease used to say, "if something is 'funny', record 'amount of funny'"
I guess the damaged flanks of the signal makes it hard to measure the baudrate, so trying to measure a single bit gives enough measurement errors to make it seem like 20kHz.
Baudrate should always be measured by spanning as many bits as possible.
Sorry for my bad descriptions.
At the transmitting end (Board-A), if I directly measure the tx-pin of the MCU, calculate the width of one single bit (a bit 1), the oscilloscope shows [ 1/delta-X == 19.2xxkHz ], and the signal of this bit is a perfect square wave.
Board-A has Cable-A, and Board-B has Cable-B, the connection between Board-A and Board-B is actually [ Cable-A <-> Cable-B ]. Cable-A and Cable-B connect to each other with a connector. Cable-B has branched hooks for measurement purposes.
If I measure the hook of Board-B/Cable-B, the oscilloscope shows [ 1/delta-X == 20.xxxkHz ], and the signal is a wave with rounded left corner.
Sorry for my bad descriptions, again.
We measured several damaged bits (bit 1), all of them were [ 1/delta-X == 20.xxxkHz ].
No, I did not talk about measuring several damaged bits, one-by-one.
I talked about emasuring the total time spanned by multiple sequential bits. Measuring over 5 bits means that any round-off errors from guestimating the specific measurement position of a potentially bad flank gets divided by 5, giving less measurements errors.
In the end, there will always be the same baudrate, but the quality of the individual bits will be worse with distance.
How does it work with a shorter cable?
Do you have any differential in your PCB grounds or are there things injecting current spikes in the power leads?
TTL 19.2k baud should not be a problem over 80cm.
For reflash and calibration purposes, I have had 40 foot or longer 18 ga cable for a 5v TTL RS-232 at 115.2kbaud without any communication problems.
The drive circuits were a simple CPU -> resistor -> transistor base. Transistor emitter was grounded. Collector had a pullup resistor to +5. Collector was also the controller TX output. Rx circuit was the same except backwards and had base pulldown resistor. A 2N3904 was used. Note, when a 2n2222 was used, certain PCB's had errors at high baud rates due distorted waveforms.
If you can't modify the design or baud rate it sounds like choices are slim if the problem is in the design or UARTs. Perhaps a cable that can clean up any noise or ground potential? Send out some 0x55 or 0xaa's and see what the bits look like.
Chad
The OP:After some trouble-shooting, I found that: We have Board-A and Board-B. Board-A and Board-B communicate to each other with a UART TTL Level Communication. The communication cable is around 80cm long. During the communication, I got a lot of UART errors. which uC all letters and numbers, please which type of cable you speak of middle of cable - avoid connections if you can how small a resistor do you have, to pull up the signals to Vcc, I'd use a R as small as the chips pin max Io allows.
Send out some 0x55 or 0xaa's and see what the bits look like. I'd use 'U' and get a regular square wave
erik
Indeed not!
These are 180cm - and work well over 115200 baud at TTL levels!
www.ftdichip.com/.../USBTTLSerial.htm
Many thanks to everyone.
I am a software engineer, and almost don't know anything about hardware. So I am sorry for that I am not able to provide precise and enough information about the hardware design.
As far as I know, Board-B's (the receiving end) reset circuit is unreliable (a confirmed known issue). When powers on Board-B; there is quite high percentage that, Board-B will fail to work/reset.
Now I understand that, my original assumption is incorrect. TTL Level Communication should NOT be a problem. And since no one mentions software solution in this thread, I think a software solution is not feasible. I will keep Chad's suggestion in mind (a cable that can clean up any noise or ground potential), and wait to see what will be our next step. It seems that we have decided to close this communication error issue.
One more question.
May I assume that, for external communications, RS232 provides a more reliable communication quality than TTL level; so, it provides more tolerance for bad hardware design and cables?
Yes, RS232 is more tolerant, because of the changed voltage levels used as one and zero. With TTL-level signals, you do not have much margin if you fail to keep the two grounds together firmly. That is a reason why RS-232 is specified for up to 15 meters.
Per, many thanks.
Is it?
See: www.8052.com/.../57828
I seem to have lost my copy of the RS232 specification, so I can't re-check that just now - but I'm pretty sure that it was a direct quote from the spec.