Using a MAX3232 with old 8-bit computer

Question

Let me start by saying I'm not an electronics engineer, I just "dabble" so open to anyone pointing out the obvious.

I'm attempting to connect an old 8-bit computer's serial (RS232) port to a micro-controller using a MAX3232 to perform the level shifting. I've wired it up essentially as per the data-sheet (using just RX/TX lines through 1 of the transceiver pairs) and when attached to a USB/serial adaptor works fine.

However when connected to the 8-bit micro, when it transmits a block of data it also can receive "echoes" back on the receive lines. Fundamentally I think what's happening is that it is causing fluctuations on the charge pumps which can then result in mirrors of the data on the RX. Aside from being able to see the voltage fluctuate with a multi-meter, I am also planning on using the other transceiver for the control lines (RTS/CTS). If I wire this up, with RTS de-asserted on the 232 side (-12V), the charge pumps measure ~+/-6V. However once I assert RTS (+12V), the voltage collapses to ~+/-2V and stays that way. Unsurprisingly then, nothing works properly after that.

Here's what I've tried:

• adding a series resistor between 1-2k on the TX line definitely improves things, there is less voltage fluctuations however it's still not perfect.
• increasing the charge pump capacitors from 0.1uf to 1uf. Didn't really expect this to help and it didn't.
• measuring the current draw from RTS when connected to R2IN on the MAX. This was interesting in that when de-asserted it's ~1mA however when asserted, is ~16mA - which feels like a lot...

My Internet forages thus far haven't yielded anything helpful (other than noting this chip has been known to overheat, that doesn't appear to be the case here, it's running quite cool).

Some additional info:

Here is a schematic of the circuit: schematic of the circuit.

The 8-bit micro in question is a Dragon 64. For some reason, they chose to bring out DTR instead of RTS but I'm treating it as basically the same. Voltage on the TX line at idle is -9.6V, same with DTR. When asserted, the latter goes to +12V. The ground connection seems good, buzzed that through.

This is the serial circuitry inside the Dragon:

serial circuitry inside the Dragon

UPDATE:

I've now hooked a scope up on the lines, this first one shows a burst of RS232 transmits and the fluctuations that occur on the V+ (charge pump) pin during that period:

tx-charge-pump

This next trace shows the end of a legitimate burst of receive data (green), then the start of another transmit cycle. There is NO legitimate data being received during this period however the receive line is fluctuating, more or less in tandem with the transmits. I believe this is as a result of the charge pump behaviour which manifests as the "echo" behaviour I described earlier.

tx-rx-behaviour

For reference - trace with MAX circuit connected to USB/serial adaptor, behaviour as expected:

max-usb-serial

Trace with 8-bit micro connected to USB/serial adaptor, behaviour also as expected:

d64-usb-serial

FURTHER UPDATE.

To try and highlight some differences between a working and failing scenario since they both work independently.

On the control lines, the USB/serial adaptor has voltages of -6.2/5.6V. The Dragon has -9.5/12.7V. I mentioned before about the current draw when DTR is connected to R2IN being ~16mA when asserted (12V). This makes no sense to me when looking at the datasheet, there is an internal 5K pull down to 0V on the serial inputs which means at most this should only ever draw ~2.5mA. I feel this is significant in terms of the behaviour (particularly in it apparently disrupting the charge pump voltage) I'm seeing. In contrast, the USB/serial adaptor only shows ~1.1mA and does NOT disrupt the charge pump.

More recently, I've got hold of a desktop PC with onboard serial. This has a voltage of -11.3/+11.5V on the control lines. It also shows a significant current draw of 11.6mA when connected to R2IN. And here's a scope trace showing tx traffic to the MAX circuit (this is me sending a string of 0 bytes out):

dell-pc-serial-tx

It's noteworthy (I think) that the RX line is showing similar (but less pronounced) behaviour to that when connected to the Dragon. I've not yet had a chance to see what the receiver software makes of this but it may still be working enough to not be detected as valid state changes.

• Spehro 'speff' Pefhany: A schematic would be helpful. Are you sure the '8-bit micro" is actually operating at true RS-232 levels? What voltages do you measure at idle?
• Justme: Please show the schematics of the MAX3232 and the connections you made. Also state which old 8-bit computer that is and to which port on it you connected and with which wiring. As long as the circuit is done "by the book" (or rather the data sheet) and connected properly between MCU and the old computer, it should just work.
• jonathanjo: Hello and welcome. Certainly there's nothing wrong with the overall plan, so must be somewhere in the execution. A diagram and a photo would really help us help you.
• Lundin: The usual suspects: missing signal ground or mixing up Tx and Rx. UART Rx/Tx are always mixed up no matter how much thinking or planning you do, they follow Murphy's Law.
• Hearth: The serial circuitry shown in your link (please do inline those images, by the way) only includes the transmit portion. What about the receive lines?

Answer 1

This issue was purely down to faulty (counterfeit?) MAX3232 chips, as noted in one of my comments above, the two I'd tried were from a batch of 5 bought from EBay direct from China. When replaced with a chip bought from a reputable UK distributor, the software started functioning correctly and there were no signs of signal fluctuations on the receive lines OR charge pumps.

Pictured: dodgy chip on left, working chip on right. Notable that the one on the left lacks the "Maxim" name.

max3232-chips

I suspect for most people, given it does appear to work correctly with USB/serial adapters (which for the most part have probably superseded onboard devices), they wouldn't see a problem.

In conclusion - you get what you pay for!

• Justme: It might have been faulty/counterfeit but it cannot be ruled out that it got damaged with ESD or some other issue in your tests. Also MAX3232 is made by many vendors so the missing Maxim logo does not mean anything. The part is made with MAX3232 name by TI and Analog which did bought Maxim.
• fridgemagnet: This seems unlikely. I took ESD precautions and when swapping out the chips, literally touched NOTHING else and (in the case of the 2nd one of first batch) got exactly the same behaviour, yet with the Maxim part, worked fine straight away.