The job was simple: I needed an RS232 interface on a Raspberry Pi so that I could use it to log console output from a misbehaving router (don't ask). I could have picked up one of the millions of USB-to-RS232 converters on eBay (and run the gauntlet of FTDI's clone-bricking updates). However, I have read mixed reports of the stability of the drivers for these adapters in the Raspberry Pi kernel. Besides, there actually is a UART baked into the Pi SoC. The problem is that it only works at 3.3V logic levels so it can't be connected directly to a device that uses RS232 voltages. That's OK...I just picked up one of these and wired it to the appropriate GPIO pins on the Raspberry Pi's I/O connector
Simple, eh? No. It worked just fine talking to a PC, but when I connected it to a Cisco 1841 router, very strange things happened.
When I sent a character from the Raspberry Pi to the router (I think I might have just hit carriage-return), this absolute explosion of characters was the result
Wow...what's going on here ! Out with the oscilloscope. Here is an 'A' being sent from the Pi to the router:-
The blue trace is the Pi's TX line and the yellow trace is the Pi's RX line. So far so good. However, a few moments (about 68ms, to be exact) later, this happens:-
As far as I can see, what is happening is that when the Cisco echos back the character it received (yellow trace), there is crosstalk onto its RX (blue), so the router is seeing an "echo" of its own character (but corrupted). The router echos that character back also, sees another "phantom" character on its RX etc etc.
As I mentioned, Raspberry Pi talking to a PC works just fine. Sure enough, looking at that on the oscilloscope...
...there are little "spikes" evident on the Raspberry Pi TX line, but nothing like as bad and apparently not enough to cause a problem.
So the question was, where (and how) was the crosstalk happening ? A few possibilities:-
- Within the router itself (highly unlikely, or the router wouldn't work with a PC either and would be basically useless)
- Within the console cable (that was my first theory when was using a patch-cable, but I replaced that with a flat-8 cable which keeps the RX and TX lines separated by a few mm and that made no difference)
- On the adapter board somewhere (most likely, but why, then, did I see hardly any crosstalk at all with the RPi talking to a PC or to a switch ?)
To test the theory that the crosstalk was happening on the adapter board, I disconnected the RX from the router from the TX line on the adapter board and used to oscilloscope to watch (a) the (now-disconnected) RX line from the router and (b) the TX line on adapter board separately.
I think it is a question of voltage. The router uses a relatively high voltage on its TX line...around +/-10V. Still perfectly within the RS232 specifications (which allows for +/-12V) but higher than either a Cisco switch I tested or the PC use (both about +/-6V). It looks like the higher voltage breaks down the line-driver. Sure enough, conducting the same experiment with a switch instead of a router...
So it looks like the MAX3232 line-driver doesn't like +/- 10V on the RS232 side. It should - according to the data-sheet it should be good for +/- 25V:-
I did one more test to confirm the theory: I put a couple of back-to-back 3.3V zener diodes in between the router TX and the adapter RX. This has the effect of dropping the voltage that the adapter sees by about 4V.
Sure enough, the problem goes away (I didn't bother saving an oscilloscope trace but - trust me - it was perfect: no signal at all leaking onto the adapter TX). Its really looking like its the voltage that is causing the problem.
So at what voltage does the problem kick in? If I feed a square wave to the RX pin on RS232 side while watching what appears on the TX pin (nothing should) and gradually crank up the voltage, we should be able to find out. In each of the screen-captures below, the yellow traces is the signal being fed to the RX pin and the blue trace is what is coming out of the TX pin.
Starting with 19.2V peak-to-peak...
No problem so far. Increasing to 19.4V peak-to-peak...
...and 19.6V peak-to-peak...
...by now we would probably be seeing problems. Increasing the voltage to 20.6V peak-to-peak...
...and we would definitely be seeing problems.
If a real MAX3232 IC (mis)behaves like this, I'll eat my hat. I have looked closely at the IC on the adapter and - to my untrained eye - it looks fine (decent enough quality moulding, quality of laser etching looks OK) but I'm willing to bet that these are fakes.
I would really love to get a known-genuine MAX3232 IC from a reputable supplier and use it to replace the suspect one on the adapter, but they only seem to be available in quantities of 2500 (at about €1 each). Sorry, but I'm just not that interested. However, if someone wants to send me a few genuine MAX3232s (you will need to pinkie-swear that they are definitely the real thing) I'll be happy to do the test and report the results here.
PS: An interesting thing I learnt in the course of doing this project is that the Raspberry Pi (the Raspbian image, anyway) runs a serial console on its built-in UART. A serial terminal emulator connected at 115,200 baud will receive a login prompt through which you can log in to the Raspberry Pi. You never know when that will come in handy.
what i suspect is the newer adapter have extra caps and some resistors which r required to overcome this crosstalk thats y this 4 cap circuits dont work properly as they lack few extra coponentsReplyDelete
i also seem to have this issue, actually i use a usb to ttl adapter to connect to PC, then ttl to rs232 and then a null modem cable to conenct to a box running pfsense, the issue happens when i boot pfsense, during boot it waits for some commands for 5 seconds to goto shell, during that period nothing should goto pfsense but it seems the crosstalk makes it auto type some characters.ReplyDelete
for me the issue is when i have the adapter conenct to PC and then i reboot pfsense with PC powered on then it will reboot but if PC is off with no power so no power on usb to ttl as well as this adapter then there is crosstalk and pfsense wont boot unless i remove the serial cable. So its like there is crosstalk when there is no power in the max3232 chip.
I had the sam issue with a different chinese MAX3232 board.
Around five minutes after power up, every character sent to board was echoed and it was corrupted.
First I thougth that the chip has been destroyed by ESD and I used a new board (I bought 4). It worked, but only for five to ten minutes too.
So I ordered genuine MAX3232's and soldered them onto the board. They work without any problems. When looking to the genuine MAXIM chip yould will notice that it looks much better. The laser etching is deeper and the modling is much sharper. But when I was looking to fake chip for the first time, it seemed to be fine.
It's funny, that the chinese industry is able to make working FTDI clones but unable to make a simple MAX3232.
I think the MAX3232 is more complex than an FTDI. You can build an FTDI with a microcontroller and firmware, you cannot do the same with the MAX3232.Delete
Thanks for sharing! I was trying everything I could to eliminate and diagnose cross talk,, and I never suspected the chip itself to be fake. Just changing it to a genuine unit, even the regular 5V version, helped!ReplyDelete
WOW. Just WOW. I spent hours diagnosing this issue, thought it was my wiring bad. I will order genuine MAX3232 to replace and see if it works. Thanks a lot man!ReplyDelete
Hi, Do you think that putting a voltage divider would work as well as the zener diodes you are using? Thank you. I have been pulling my hair out to find why I get no RS232 comms...ReplyDelete
I wouldn't absolutely count on a resistor divider doing the trick. The problem is that you have no certainty about the "stiffness" (output impedance) of the source nor the input impedance of the destination. This means that the usual resistor-divider calculation (which assumes a low output impedance and a high input input impedance) won't necessarily produce the result you want. You would need to find a balance between making the resistor values high enough that they won't load down the output too much yet low enough that they can supply adequate current to the destination. It might be a fine balance. The diodes have the advantage of not being affected by either of those things.Delete
Hah! Right you are sir! I got no satisfaction with the voltage divider (was too impatient to wait for a response). I tried large resistors and small resistors. Unlike Goldilocks, I could not find the right one. The funny thing is that the voltages are +/- 9.6 or so volts-not terrible high. I checked the rs232 adapter with a loopback and by connecting them back to back. Everything works until the voltages become "high (9V)". Now where to find legit MAXIM adapters...Delete
Ok. I'm looking to use these for a prototype electric vehicle, so I'd rather not risk it going crazy after a few minutes. Not with an actual driver on board in any case.ReplyDelete
I too just fell into this trap ... had a batch of MAX3232 chips from China for a custom board ... worked fine with an earlier prototype (and MAX232), but with the new chips it also showed the echo ... same behavior ...ReplyDelete
Will try the trick with the Zener and see if that helps ... anyway, on the chips I have, even a moderate voltage of +-7V causes the echo (which comes out at about +6 to -2V, weirdly)
I'm using Chinese MAX3232 boards without DB9. When connected to raspberry pi's 3.3 volts the charge pump circuit doesn't pump anything (No +- 6v). With a different supply, it works most of the time.ReplyDelete
Thanks a lot for the article! I face the same issue...ReplyDelete
Now I need to find a solution...
I wanted to buy this version with a different architecture (with dismountable chip) so then replace the chip by the official one. The module is available here:
But still a problem : Where can I get the official chip with the same case ? It seems to be out of stock on TI website.
Or is it possible that even if it's still a copy, this kind of chip will work better than the SMD version?
Anyone has a simpler solution to propose me?