Go Down

Topic: Arduino with MAX232 not transferring data properly (Read 6667 times) previous topic - next topic


Hi guys,

I'm working with a Modern Device RBBB, and I'm having issues with Serial transfer with the Arduino using a MAX232N chip. I whipped up a quick schematic to show you how I have it hooked up:

(I forgot to add values to the caps in the schematic - they are all 1uF in my circuit.)

This allows data to transfer between the Arduino and my PC through the serial port, but there are issues with the data being transferred. I also have a FTDI usb->serial converter that I normally use, and that transfers data without a problem, but when using the MAX232, I get data that appears to come into the PC out of order. It sounds confusing, so maybe an example will work out better.

Here's my example: I have a sketch that runs for 60 seconds, during which it outputs a line of data, with a line break at the end (using Serial.println() ). During this time, I increment an unsigned long, so that after 60 seconds, I can have the Arduino output the number of samples that were taken during the 60 seconds. Using the FTDI chip, the output looks something like this:

Code: [Select]

Samples Taken: 8014

All data are of the same length before the | symbol - the data after | on the same line is the value returned from millis(). This is the desired output of the data - it's exactly as I want it to be.

A problem occurs when using the MAX232 chip, the samples look something like this:

Code: [Select]

Samples Taken: 8014

I've taken some liberties and snipped excess data out of the MAX232 example, but you should get the idea. You will see that some of the data are out of order (millis is *lower* on a later sample than an earlier sample; The data are not completely written on one line, or in some cases, the data from two samples are on one line). Since this does not happen when using the FTDI chip, I don't believe it's an issue with the Arduino itself, or the sketch that I created - I think the issue is with my MAX232 serial circuit.

Does anyone see why this would be happening? Have I messed up the circuit or is something else amiss? Any help would be greatly appreciated  :)


I'm awesome - this is totally in the wrong forum - can a mod move this over to interfacing?


Just to add more to this: I just hooked up a 3.3V Arduino Pro to this MAX232 circuit, and it's also not outputting the desired format. When using an FTDI chip, the format is correct, but when using the MAX232, the output looks like this:

Code: [Select]

X:376 Y:378 Z:37Z:373
min/max 7:347/434 Y:437 Z:343:343/431
X:376 Y:378 Z:3 Z:373
min/max47/434 Y:3 Y:346/437 Z:343/43:377 XV: YV: Y:377 Z:373
/max X:347:347/434 Y:346/Z:343/431
X:376 XV: 8 Z:374
min/max X:344 Y:346/436/437 Z:343/431377 XV: Y:: Y:378 Z:373
/min/max X:334 Y:346/436/437 Z:343/43:377 XV: YV: Y:377 Z:373
X:376 XV: 8 Z:374
max X:347/347/434 Y:346/4:343/431
X:376 XV: Y Z:374
min/max X:347 Y:346/437/437 Z:343/431
7 XV: Y:37Y:377 Z:373
min/ma347/434 Y:4 Y:346/437 Z:331
X:377 376 XV: Y:377 Z
min/max max X:347/434 Y/437 Z:343:343/431
X:3V: Y:378 Z78 Z:374
min/m:347/434 Y34 Y:346/437 Z:431
X:377:376 XV: Y:377 Z
X:376 Y:378 Z:3 Z:373
min/max47/434 Y:3 Y:346/437 3/431
X:376 XV: Y:3:373

The desired output on this Arduino should look something like this:

Code: [Select]

X XV: Y:378:377 Z:373
min X:347/434 Y:3 Y:346/437 Z:341
X XV: Y:378:377 Z:373
X XV: Y:378:377 Z:373

So, it would appear that there's something up with the circuit itself. Can anyone give me a hand with it? I can't think of any other way to hook this up - I've read/reread the spec sheet, used a MAXIM chip, swapped it out with a TI chip - nothing seems to matter.

I've looked around and found other circuits for use with the Arduino using a M74HC04 Hex inverter, or mimicking the circuit on the original Serial Arduino using a set of BC547 & BC557 transistors, but in the end, these will not output RS232 spec voltages. Anyone have any ideas?


You've got a lot of variables, so I'll throw out some generic guesses.

First, is it exactly the same Arduino code, no changes?

The MAX232 circuit is far easier to get right and more reliable that the transistor or inverter tricks.

Check the MAX232 caps to make sure that none are reversed if you use polarized types.  You specified you're using the 232N variant which will accept 1uF caps (the original required 10uF caps, so this matters).  Make sure there is nothing else shorting or connected to the data lines on either side of the MAX232 (e.g. an FTDI cable still hooked up, stray strands of wire, solder bridges, etc).What elese is hooked up to the circuit - did adding the power draw of the MAX232 cause the voltage to drop?

The MAX232 is a 5V part - it won't work at 3.3V. (I don't recall enough of the data sheet to say if it will accept 3.3V signals as the 5V TTL high it expects, even if you happen to drive it at 5V.)

There are obviously other variables, as you're talking to an rs232 (com) port.  Is it the same computer?  What about the rs232 cabling?  what are you using to read the data, and have you used a terminal app like hyperterm to verify the data is arriving correctly?



kg4wsw: Thanks for getting back to me on this :-) Let me answer your questions:


The caps are as my schematic states. They are polarized, but they should all be wired up properly - they are 1uF caps.  I have also replaced them with new caps and swapped polarity on them with no change in results. It's kind of annoying ;-) I've also switched from R1/T1 to R2/T2 on the chip with no change in results.

One the RBBB, I have a 12-bit ADC communicating to the Arduino using SPI. I also have an accelerometer and two op-amps. It doesn't change the output if I unplug any of these things.

In the Arduino Pro example, I have absolutely nothing hooked up to it. It's just the Arduino Pro board (it's a 3.3V spec, 8Mhz board.) and the MAX232N chip. (as an added data point, the MAXIM chip I'm using is the MAX232CPE - it's functionally equivalent to the Ti MAX232N)

I'm using a computer power supply to supply 5.0V to my breadboard. the voltage on the lines running to the MAX232N chip shows 5.07v. Without the chip, the voltage is 5.09V. There is a slight drop, but there should still be sufficient power for this work work properly.


I'm using the same computer to compare FTDI results to MAX232 results. I've tried using the Arduino IDE, along with a serial program I found compiled using C# - they both output similar data (The C# program outputs extra line breaks here and there, but does not seem to exhibit this buffer-weirdness that the Arduino IDE ) I'm using a known good USB->Serial converter on this machine. I also tried using an actual serial port on another computer with the same results. At this point, it has to be this circuit.

I'm curious about other people are using for their MAX chips - are they 232N's, 220's, 202's or something else? At this point, I am scratching my head. I'm sure it's something simple, too, but I'm not finding it.


My Arduino serial clone board uses a HIN232CP and is using .1mfd caps. Here is the data sheet:




I've used the MAX232 from Maxim, TI's copy, and someone else's copy (ST?) with very good results.  I've used them in the same way you do with no problems.  This is a very widely used part.

Sounds like your circuit is pretty solid.  I went back and read the data sheet for the MAX232, looks like the 3.3V arduino should drive it just fine, so that one should have worked as well.

What's the baud rate?  Try dropping it back to 9600 (or even less).

I'd try hyperterm or some other terminal app to eliminate possible problems there.

Maybe it's a handshaking issue?  e.g. the hardware com port expects the arduino to honor hardware handshaking and dropping characters as a result.

I'm still just guessing, but it soulds like your hardware is good.  I guess conceivably there are noise problems with your PC switcher as a power supply, but that's a bit of a wild guess.



That's a good suggestion. Just wire pins 9 to 10 on the 232 chip together and just use Hyperterminal or other basic PC serial communications program to see if the data loops back properly or not. That should isolate the problem somewhat. Also make sure your serial cable is wired correctly as there are some that are wired as a null modem so they swap send and receive signals. Of course a scope if available would make short work of isolating the problem  ;)



Thanks for the suggestions guys. I did some more poking around and found some peculiar things...

Just more data points: when I was originally having issues, I was trying to run 57600bps - I changed the sketch and dropped it down to 19200bps, but was still having data transfer issues. The following was tested at 57600bps:

I started up the Arduino IDE Serial Monitor, and then started up the Arduino, which went through it's series of incorrect data. Then I unhooked the Arduino from the max232, replacing the TX/RX pins like retrolefty suggested with a jumper, but leaving the Arduino IDE's serial monitor running. Summary: loopback adapter through the MAX232 chip.

I then proceeded to send "12345" through the serial monitor. I did not receive "12345", but I did receive remnants of characters from what I assume to be the data that was from the Arduino. I sent more and more characters through the IDE, but never received the characters that I sent - it would always reply with other data.

Perplexed with that outcome, I power cycled the MAX232, and then tried sending data through the MAX232 circuit. This time, everything I sent was properly echoed back to me in the Arduino IDE. At this point, I started to think that the IDE's serial buffer was somehow getting all funky and/or messed up on some way.

To test that, I opened up my other serial program that I'm using - it's roughly equivalent to hyperterminal. this will also properly echo back whatever is sent to it, although I am unable to send cr/lf to the max232 (this should be irrelevant though, since the MAX232 is just a logic circuit). so, in either configuration, it appears that whatever I send through the MAX232N is working.

So, I went back to hooking up the Arduino to the MAX232 chip - it was time to test the C# program I am using. While I was at it, I realized that I had no resistors inline between the Arduino and the MAX232 chip. I added 100k resistors inline for both RX and TX. The C# program tends to drop/mangle a lot less information than the Arduino IDE's serial monitor. Even still, data is coming in unexpectedly - just like before, but not quite as frequent.

I took kg4wsv's advice and dropped the sketch down to 9600bps and tried again. This time, all data is intact. It works through the Arduino IDE, it works in my c# program, and works on another machine using a built-in serial port. So, the issue appears to be fixed. Sort of.

The new issue is this: 9600 is not adequate for what I need to do with the project that I'm working on. I need to be able to send data at 33600bps or faster. Obviously, 115000 is asking for a bit, but 57600 would be ideal. the max232 should be capable of these speeds without a problem. What else can I use, serial only, that's able to send at these speeds?


~ Clifford Stoll


In your schematic you say you are using pins 2 & 3 for serial.  Is that correct?  If so you must be using software serial.  Is there any reason you can't use the hardware serial on pins 0 & 1?  It is much more reliable and can handle higher speeds in my experience.


Digger, ATmega pins 2 & 3 are Arduino pins 0 and 1.

THe 100k resistors (which sound rather high to me; I think 10k is more appropriate) are not necessary.  They are on the arduino so that you can attach something to the arduino pins 0 and 1 and have the other device and the ATmega overdrive the FTDI chip, effectively ignoring the FTDI without disconnecting it.

There's a problem with baud rate errors that can crop up.  at 56k the 16MHz crystal on the Arduino results in a 2.1% mismatch, which is pretty big.  Try running at 38.4k, which is the ATmega's next lower speed.  It has an error of 0.2% (same as 9600 and 19.2k).  You may have a UART in your computer that is particularly intolerant of baud rate errors.

Another possibility: it seems that soem folks encounter problems when the characters are too close together.  This could be tested if you could insert a small delay (probably 10 to 20 microseconds; 1 bit time is 17.3 microseconds at 56k) between characters. There's a thread running about "consecutive zeroes" that talks about this.

I really believe it's got nothing to do with the MAX232.  I think the FTDI USB/232 IC (which does a great job) is behaving well and that your hardware UART/rs232 driver/etc are not as robust, so they're showing the problem.



Digger: you're right, the schematic is slightly mislabeled - kg4wsv is right - those are actually ATMega pins 2 and 3, which are Arduino's pins 0 and 1.

kg4wsv: I must have fat-fingered that resistor value - they're 10k resistors.

I've started changing baud rates to test them all out, and am still coming across some issues. My Arduino IDE is throwing fits about running at 28800bps, but my C# program is properly receiving data at that speed. Anything I've tried under that speed appears to be working, too. Anything over that speed still exhibits dropped/mangled data - even 38400bps.

I had also thought about potential crystal frequency issues, but had not really dug too deeply into that. The RBBB uses a resonator, which I had originally thought may be part of the issue, but I had not gone through replacing it with a crystal & caps (although I do have all the necessary parts to do that) - Maybe I will try that and see if 38400 works for me.

I will also try adding the microsecond delays you mentioned tonight.

I had already thought about trying something like a MAX3232, and am making an order with an electronics supply place today, so will probably order one up to see if it works any better than the MAX232N.

Thank you guys for all the helpful information :-)


The big difference between the MAX3232 vs the 232 is that it operates on 3.3V or 5V.  If it's a 5V circuit already, it won't buy you anything.  On the other hand, if you do 3.3V and 5V stuff, you can stock one part in your supply to handle either scenario.

I didn't think about the resonator in the BBB.  Resonators aren't terribly accurate - switching to a crystal may help clear things up.



Instead of adding a microsecond delay you could just setup the sender to transmit 2 stop bit.!

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.

Thank you for subscribing!

via Egeo 16
Torino, 10131