# Problems with homemade RS232-to-TTL converter board based on TI's MAX232

I've designed an RS232-to-TTL converter board based on TI's MAX232 IC that I plan to use to program a few custom Arduino boards that I have. However, I'm having trouble with the board and I'm hoping that someone can help me debug it.

First, let me show you my setup, below.

Here's a brief description of what's in the picture:

• Target Board (A): it's a custom standalone ATmega328P board (a clock) that I intend to program using serial programming and the Arduino IDE. It's connected to the Board B through a FTD-like cable through Connector (H).

• RS232-to-TTL Converter Board (B): it's the MAX232 based RS232-to-TTL converter board I designed and am trying to debug. It's the main topic of this question. It's connected to the Target Board (A) with the FTDI-like cable through Connector (G) and to the USB-to-RS232 Cable (C) through a Female DB9 Connector (F).

• USB-to-RS232 cable (C): I don't have a proper COM port on my PC, so that's what I use to get a Serial Port instead. It's connected to the PC through an USB connector (D) and to the Board B through a Male DB9 Connector (E).

The schematics of Board B are below.

The programming header schematics on Target Board (A) is shown below.

First thing I realized is that the USB-to-RS232 Cable (C) is of the cheap kind. Instead of delivering RS232 standard signal levels in the -12V/+12V range, it delivers 0V/5V instead. I figured that using the following test: I connected the USB-to-RS232 Cable (C) to the PC and disconnected Male DB9 Connector (E) from the Converter Board (B) and probed pin 3 from the Male DB9 Connector (E) while I was sending a series of ASCII char 'A' through the serial monitor. Below is the scope shot resulting of this test.

Incidentally, I've noticed that the various MAX232 IC's made by various vendors are designed to cope with this violation of RS232 signal levels and accept 0V/5V signals as well. Below are two scope shots that I used to prove it. In the first shot I applied a 0V/5V square wave into MAX232 pin 13 (while inserted and powered by my converter board) with my homemade function generator (noisy, yes) - that's the yellow trace - and checked the output of pin 12 (TTL level RX - green trace). To my surprise, TI's MAX232 respond with the correct TTL signals. The second shot is a correct RS232 -6V/+6V signal simulated by a square wave I inserted into the same pin. Both yield the same results.

I did some other measurements on my Converter Board (B) to the point I was satisfied with it. For example, pin 2 on MAX232 shows +9.5V while pin 6 shows -9.5V. The scope shows the voltage doubler and inverter are working fine as well, with a nice and steady 40kHz square wave in each case. I've also applied 0/5V square wave of about 68kHz to pin 10 of the MAX232 and scoped pin 7 of MAX232. I got a nice and clean inverted -6V/+6V RS232 signal (images not shown here).

Then I tested serial monitor echo shorting the TX/RX pins at various points. The results where:

1. Without MAX232 IC in its socket I shorted pins 2 and 3 on DB9. Echo ok.
2. Placed MAX232 IC on the board and shorted its pins 11 and 12. Echo ok.
3. With ATmega328P off its socket, I shorted pins 2 and 3. Echo ok.

Then I connected the setup to program my ATmega328P Target Board (A). The avr-dude output is shown at the end of this post. Below is a summary with just the error message:

...
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
...
avrdude: stk500_cmd(): protocol error


During this programming attempt, I measured the signals below. The yellow trace is data being sent to the MCU while the green trace is data being received by it:

When I get the error, there's a sudden interruption in the communication. From one attempt to the next, the problem happens at different points during communication.

Finally, I replaced my MAX232 board with an older one that I have, that uses the transistor trick instead of the MAX232 IC, and all starts to work properly. With the old board I can get the target board programmed. Below is the scope shot showing the successful communication during programming of the target board in this case.

I'm certainly overlooking something, but I cannot tell what it is. So my question is: what's wrong with my setup? What else can I check or measure to figure out the problem?

Here's the Arduino IDE and avr-dude output:

Binary sketch size: 9.946 bytes (of a 32.256 byte maximum)
C:\Users\Ricardo\Documents\arduino-1.0.5\hardware/tools/avr/bin/avrdude -CC:\Users\Ricardo\Documents\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P\\.\COM5 -b115200 -D -Uflash:w:C:\Users\Ricardo\AppData\Local\Temp\build2465731745810216807.tmp\DefusableClock_v2.cpp.hex:i

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "C:\Users\Ricardo\Documents\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf"

Using Port                    : \\.\COM5
Using Programmer              : arduino
Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
AVR Part                      : ATMEGA328P
Chip Erase delay              : 9000 us
PAGEL                         : PD7
BS2                           : PC2
RESET disposition             : dedicated
RETRY pulse                   : SCK
serial program mode           : yes
parallel program mode         : yes
Timeout                       : 200
StabDelay                     : 100
CmdexeDelay                   : 25
SyncLoops                     : 32
ByteDelay                     : 0
PollIndex                     : 3
PollValue                     : 0x53
Memory Detail                 :

Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
Block Poll               Page                       Polled
Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

Programmer Type : Arduino
Description     : Arduino
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [83]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [84]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [90]

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
avrdude: Send: A [41] . [98]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
Hardware Version: 131
Firmware Version: 132.1077487570
avrdude: Send: A [41] . [84]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [85]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [86]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [90]

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x90
avrdude: Send: A [41] . [87]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [89]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [83]
avrdude: Recv: . [10]
Vtarget         : 0.3 V
Varef           : 0.3 V
Oscillator      : 921.600 kHz
SCK period      : 142.2 us

avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: P [50]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv: . [14] . [1e] . [95] . [0f] . [10]
################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: Send: V [56] . [a0] . [03] . [fc] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [fd] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [fe] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [ff] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [90]
avrdude: stk500_cmd(): protocol error

• Nicely documented. – tcrosley Mar 28 '14 at 3:50
• @tcrosley Thanks! I tried my best, but there were still some obscure points that I tried to clarify with my last edit. – Ricardo Mar 28 '14 at 12:12
• Is there a reason the "reset" line is at RS232 voltages and not run through the converter? Does the Arduino need a higher voltage to program or something? – markrages Mar 28 '14 at 14:47
• While the reset circuit you have might be able to absorb the voltage of the RS232 driver without damage, a perhaps overlooked issue is that RS232 drivers and receivers traditionally invert. So the logic of the reset line may be backwards from what the software expects. You have an unused receiver channel, perhaps you should use that. Also make sure the software is driving the one of the RTS or DTR possibilities that you are wired for. If you can pre-program a sketch that would interact on the serial you can do some additional validation. – Chris Stratton Mar 28 '14 at 15:16
• See for example ftdichip.com/Support/Documents/DataSheets/Cables/DS_UC232R.pdf where the data and status lines go through identical channels of the level converter. I believe when people use that USB-serial chip with an Arduino and no level shifting, they don't invert the reset, so when it's gone through one inverter in the level shifter of your cable it will need to go through another in your circuit or else it will end up opposite of its usual sense. – Chris Stratton Mar 28 '14 at 17:32

Your question was way to long to read, but it seems you are having some problems with a MAX232-type of converter circuit. I have made what seems to be a very similar circuit using one of the TI variants of the chip, and even sell it as a product. Go to www.embedinc.com/products/rslink2 and you can see all the documentation, from a picture to the board layout to the schematic. Perhaps you can see what you are doing differently.

One thing I noticed while skimming your question is that you are using electrolytic caps. Double check that the polarity of each is correct. Another issue is that some COM ports, particularly USB to RS-232 converters, won't work without RTS/CTS, whether this is enabled in software or not. Note how I have pins 7 and 8 connected to each other on the DB9-F connector.

• I didn't know how to shorten the question as I don't know where the problem is. So I decided to show all I have in detail. – Ricardo Mar 28 '14 at 13:15
• Also, while studying the subject, I did come across your product page and the schematics linked from there. Really nice! But I didn't study it in more detail because the IC you used didn't seem pin compatible with mine. But I'll take a closer look. Thanks for your help! +1 – Ricardo Mar 28 '14 at 13:18
• This is the closest to an answer that I got on this, so I'm accepting it. Thanks!! I've narrowed down the problem: it relates to an increase in errors (due to noise or crystal sync) at 115200 bps, that do not occur at 57600 bps. See my other question for details. – Ricardo Apr 1 '14 at 12:15

You say you scoped pin 3 of the DB9 and saw 0-5V. Pin 3 is receive data from the outside world, and is driven by your USB-to-TTL serial cable.

The MAX232 receives RS-232 levels on pins 8 and 13, converting them to TTL levels on pins 9 and 12, respectively. The MAX232 receives TTL levels on pins 10 and 11, driving RS-232 levels on pins 7 and 14, respectively.

To paraphrase Dr. Indiana Jones, the noted professor of archaeology, you're looking at the wrong pins.

Run a simple 555 pulse train generator off of +5, apply it to pin 10 of the MAX232 (not connected on your schematic), scope pin 7 of the MAX232, and see what you get.

• Sorry, I may have not been clear enough. I don't have a USB-to_TTL serial cable. I'm trying to simulate one by using a USB-to-RS232 cable connected to this RS232-to-TTL converter I made. – Ricardo Mar 28 '14 at 2:23
• In the check you mentioned in your first paragraph, I connected the USB-to-RS232 cable to my computer and left the DB2 unconnected. Then I probed pin 3 while sending data through the terminal. Then I got the 0V/5V signal and concluded that the cable doesn't follow RS232 standards. According to this picture, pin 3 is TXD on the male DB9 connector. Or am I just confused? – Ricardo Mar 28 '14 at 2:23
• So, pin 3 on male DB9 is transmit data from the computer and drives data into the RS232-to-TTL converter, right? It's the opposite of what you said in your first paragraph. – Ricardo Mar 28 '14 at 2:24
• Also, I've done what you suggested on the last paragraph of your answer. I applied 0/5V square wave of about 68kHz to pin 10 of the MAX232 and scoped pin 7 of MAX232. I got a nice and clean inverted -6V/+6V RS232 signal. – Ricardo Mar 28 '14 at 2:27
• @JohnR.Strohm However the OP said he was able to short pins 11 and 12 on the MAX232, and connect the MAX232 to a cable coming from a PC using the DB9. That means the DB9 has to be wired correctly, or the transmitter/receiver in the MAX232 wouldn't be connected to the TX/RX pins on the DB9 properly. – tcrosley Mar 28 '14 at 5:29