MAX3232 RS232 Rx working but TX not working?

[thejoggingmat]

I have a problem interfacing via RS232 to my arduino. Basically, I've bought one of these modules (https://daverobertson63.files.wordpress.com/2013/06/t2k60xxmhoxxxxxxxx_12774208.jpg). I set up a development board to test out, with one arduino receiving RS232 data (I will call this 'module 1') and another arduino emulating send of RS232 data & responding to the ACK signal (I will call this 'module 2').
It works and module 1 can receive module 2 data, which then sends out an ACK signal (0x06) to module 2 which then lights up module 2's D13.

However, when I tried to test out on my client's real-life module which transmits via RS232, my module 1 can receive the stream and print the data on a 20x4 LCD. However, my client's module cannot receive the ACK signal and thus keeps spamming the same stream over and over (thus I know it's not working with my arduino).

The original module plugs into PC COM port, and I have previously developed a Windows program for my client to receive the RS232 streams. It works exactly as expected when I send 0x06 on the PC. It just doesn't work on the MAX3232. Despite sending 0x06 from my Arduino it still continues to receive the same data from my client's module indicating the latter didn't receive the ACK it needs.

Why is this so? My main theory is that the RS232 TX/RX voltage isn't high enough. However, I don't have a scope to test my theory out. What else can I do? Is there any other theory as to why this mystery is there?

[retrolefty]

Well first thing you could do is to measure the RS232 levels (both tx & rx) while plugged into your customers unit AND there is no data being sent in either direction and tell us the values.

[thejoggingmat]

Well first thing you could do is to measure the RS232 levels (both tx & rx) while plugged into your customers unit AND there is no data being sent in either direction and tell us the values.

Should I measure the TX relative to ground (and RX as well), or probe TX to RX?

[retrolefty]

Well first thing you could do is to measure the RS232 levels (both tx & rx) while plugged into your customers unit AND there is no data being sent in either direction and tell us the values.

Should I measure the TX relative to ground (and RX as well), or probe TX to RX?

 Relative to ground, two measurements.

[TinkerFan]

Have you checked the code for possible errors yet?
It could be for example that you keep sending to the LCD in the loop or so...

[Pack34]

If you don't have a scope, can you use a USB to TTL cable, connect the Rx of the cable to the Tx pin on your system (before the RS232 chip) to check to see if you're sending what you think you're sending to the chip? It could be a programming issue and nothing to do with the MAX3232.

[thejoggingmat]

Have you checked the code for possible errors yet?
It could be for example that you keep sending to the LCD in the loop or so...

I doubt my code has any errors; but since I haven't added anything 'sensitive' yet I might as well show it here:

Code: [Select]

#include <Wire.h>
#include <LiquidCrystal_I2C.h>


// Initialises 20x4 display
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

// Serial initialisations
char buffer[1000];
int  bufferIndex = 0;

void setup() {
  Serial.begin(9600);
  lcd.begin(20,4); // 20x4 display
  lcd.backlight(); // Enables backlight

  pinMode(13, OUTPUT); // LED D13 Pin
 
  //Serial.write(0x07); // 0x07 chosen to indicate Arduino is ready

  lcd.setCursor(0,4);
  lcd.print("Ready");
}

void loop() {
  // put your main code here, to run repeatedly:
  if( Serial.available())
 {
   char ch = Serial.read();
   if( ch == '\r')  // is this the terminating carriage return
   {
     buffer[ bufferIndex ] = 0; // terminate the string with a 0
     bufferIndex = 0;  // reset the index ready for another string
     // do something with the string
    Serial.print("This just in ... ");
    Serial.println(buffer);
    Serial.write(0x06); // ACK signal

    // Now print on LCD
    lcd.setCursor(0,0);
    lcd.print("Received String:");
    lcd.print(buffer);
   }
   else
     buffer[ bufferIndex++ ] = ch; // add the character into the buffer
 }
}


[thejoggingmat]

If you don't have a scope, can you use a USB to TTL cable, connect the Rx of the cable to the Tx pin on your system (before the RS232 chip) to check to see if you're sending what you think you're sending to the chip? It could be a programming issue and nothing to do with the MAX3232.

I will do a check later, but currently I programmed D13 of module 2 (the Arduino which I'm emulating my client's RS232 portion) to light up if it receives 0x06, which it does.

[thejoggingmat]

Well first thing you could do is to measure the RS232 levels (both tx & rx) while plugged into your customers unit AND there is no data being sent in either direction and tell us the values.

Should I measure the TX relative to ground (and RX as well), or probe TX to RX?

 Relative to ground, two measurements.

Alright, I just got the voltage readings:

TX-RX: 5.6V
TX-GND: 0V
RX-GND: -5.6V

Nothing is being transmitted from my customer's module.

[retrolefty]

Well first thing you could do is to measure the RS232 levels (both tx & rx) while plugged into your customers unit AND there is no data being sent in either direction and tell us the values.

Should I measure the TX relative to ground (and RX as well), or probe TX to RX?

 Relative to ground, two measurements.

Alright, I just got the voltage readings:

TX-RX: 5.6V
TX-GND: 0V
RX-GND: -5.6V

Nothing is being transmitted from my customer's module.

  0 volts is not a 'legal' RS-232 voltage level, so either device damage or mis-wiring is to be suspected.

 Relative to ground, two measurements.

[thejoggingmat]

Well first thing you could do is to measure the RS232 levels (both tx & rx) while plugged into your customers unit AND there is no data being sent in either direction and tell us the values.

Should I measure the TX relative to ground (and RX as well), or probe TX to RX?

 Relative to ground, two measurements.

Alright, I just got the voltage readings:

TX-RX: 5.6V
TX-GND: 0V
RX-GND: -5.6V

Nothing is being transmitted from my customer's module.

  0 volts is not a 'legal' RS-232 voltage level, so either device damage or mis-wiring is to be suspected.

 Relative to ground, two measurements.

My client's module works fine when I connect the RS232 to the PC (either with a DB9 cable or just 3 bare jumpers). I'm hoping this indicates I can rule out device damage and miswiring...... The canadian company manufacturing the module has thicker employees than hardened epoxy.

Should the 'legal' voltage level without any transmission be a good +ve voltage (like say +5.6V)?

[retrolefty]

From the Wiki:

Voltage levels[edit]

Diagrammatic oscilloscope trace of voltage levels for an ASCII "K" character (0x4B) with 1 start bit, 8 data bits, 1 stop bit. This is typical for start-stop communications, but the standard does not dictate a character format or bit order.

RS-232 data line on the terminals of the receiver side (RxD) probed by an oscilloscope (for an ASCII "K" character (0x4B) with 1 start bit, 8 data bits, 1 stop bit, and no parity bits).
The RS-232 standard defines the voltage levels that correspond to logical one and logical zero levels for the data transmission and the control signal lines. Valid signals are either in the range of +3 to +15 volts or the range ?3 to ?15 volts with respect to the "Common Ground" (GND) pin; consequently, the range between ?3 to +3 volts is not a valid RS-232 level. For data transmission lines (TxD, RxD, and their secondary channel equivalents), logic one is defined as a negative voltage, the signal condition is called "mark". Logic zero is positive and the signal condition is termed "space". Control signals have the opposite polarity: the asserted or active state is positive voltage and the deasserted or inactive state is negative voltage. Examples of control lines include request to send (RTS), clear to send (CTS), data terminal ready (DTR), and data set ready (DSR).

[Pack34]

Have you verified that you are sending out what you think you are? If you're using an Arduino, it's probably likely that you have everything jumpered together. Perhaps triple check your wiring and probe on the input  pin on the MAX3232.

You could have the TX1 and TX2 pins mixed up. If you've assembled anything yourself there's always the possibility of a bad soldering job. Maybe you burned out the pin somehow? Try switching the circuits on the chip (move from TX/RX 1 to TX/RX2). Have you tried swapping out the chip altogether?

[thejoggingmat]

Have you verified that you are sending out what you think you are? If you're using an Arduino, it's probably likely that you have everything jumpered together. Perhaps triple check your wiring and probe on the input  pin on the MAX3232.

You could have the TX1 and TX2 pins mixed up. If you've assembled anything yourself there's always the possibility of a bad soldering job. Maybe you burned out the pin somehow? Try switching the circuits on the chip (move from TX/RX 1 to TX/RX2). Have you tried swapping out the chip altogether?

I've triple checked that I am indeed sending out the correct signal by taking out the 2 MAX3232s, twisting the RS232 side TX/RX together and at the other end have a USB-TTL adapter. The opposite side is one arduino which blinks D13 and sends back 0x06 when receiving another 0x06. I fired up the manufacturer's COMPort debugging tool and fired the ACK signal. Everything works as they should. I've just swapped out with 2 fresh unsoldered modules. Same effect.

Right now, things I haven't tried yet:
-Plugging my 'dev board' with my client's PC native COM port to see if it works
-Logic analysing the serial signals maybe?

I've got 1 week to compile as many tests as possible to concoct and narrow down the problem as its an extended public holiday right here (Chinese new year). Is there anything else I can do to narrow down this problem?

[davebb]

Hi Check the rx and tx and gnd pins on the chip are correctly marked to the marking on the board, also a good test to do is connect tx and rx together on the ttl side of the board and use a terminal program it should echo what you type if it does not do the same with the rs232 level,
As I had a problem with the same chip from china, the board had a max3232 and a DB9 plug mounted on the board and a Header for rx,tx,gnd, 3.3-5v, I was trying to program a Tait radio but could not connect, then I linked tx and rx together and tested the chip in windows terminal and the chip was working,so I put a scope on the tx pin,and got nothing when I sent text, put the scope on the rx pin when I sent text and got the TTL levels, so the problem was the screen printing on the pcb was wrong the rx pin was maked as the tx pin, and tx was rx,
so just look up the data sheet on the MAX3232 chip,
Dave

[rufogil]

HI, I just bought 4 cheap modules (MAX3232ESE+ in a PCB with capacitors and a DB9) from ebay china ($1.26 each), only one worked for 5 minutes. Then bought 4 more modules from digikey ($4.11 each) with the same problem: RX ok and TX not working. In some of the modules the IC gets hot (I'm using 3.3V). In others forums affirm that there are A LOT of fake MAX3232 around. The genuine MAX3232ESE+ only cost $5.85 at digikey... In the end, cheap stuff costs more expensive. 

[mikerj]

99.9% certainty that the 'MAX3232' is a Chinese clone, and they tend to have a high failure rate.

https://www.eevblog.com/forum/reviews/fake-max3232-any-additional-details/

[@rt]

Isn’t MAX232 supposed to be + or - 10V or so? Why use a MAX232 for 0/5V when the Arduino already does that?

Something to try might be sending the serial pin high some time before the serial routine is started in code.

Another might be to introduce a delay between the characters your device is sending (character pacing).

[Psi]

double check your clients module really does output RS232 and not 5v uart.

Just because it plugged into a COM port doesn't rule out it being a 5V uart signal. Some com ports were quite happy reading a 0-5V uart direct

your Max232 will probably be able to read a 0-5V signal instead of a -12 +12 signal
But his module wont be able to receive your rs232 signal.

[DJohn]

Do you have /SHDN connected to VCC and /EN connected to GND?  It's possible to have transmitters are disabled while the receivers still work.

[cdev]

Only one out of four worked?

Is this the one they have? This one has worked for me. This is the hook up I used.

[TechieTX]

I see one thing that might be causing problems.  Your V+ charge pump cap is returned to VCC instead of GND.  We had a problem 20+ years ago with that exact circuit, directly out of the Maxim datasheet and app notes.  The Maxim apps engineer said "but you can use a cheaper cap with lower working voltage by doing that..." and my response was "Yeah, but if we continue to have 2% to 5% field failures, then the cost of repairing or replacing JUST ONE of those dead units eats up any penny saving you'll get from that variation. 

20 years ago, Maxim was one of the few manufacturers of that chip showing the V+ cap returned to +5V.  Every other manufacturer showed the V+ cap returned to ground in their app schematics.  I contacted the couple of vendors that showed that same mistake, and everyone corrected it.  Nearly.  I just looked at MaximIntegrated.com, and they're STILL showing that brain-damaged connection.  Folks, don't do it that way, trust me: I've researched the heck out of this particular issue.  We were making hundreds of PCBs at a time, tweaking the mix as we went along to improve the reliability.  Returning that particular cap to ground reduced our field failure rates to < 0.3%, and we were able to push it even lower by switching to the Teledyne Semiconductor TSC232 (sadly no longer manufactured).  After fixing that one cap and using the TSC232, we flat didn't have ANY field failures of the '232 translator chips unless they got hit by lightning or were crossed on AC phases, neither of which was covered by the warranty. 

Happy customers = better reputation and more sales.

[cdev]

This explains a problem Ive had and seen others write about.

 Thank you for this info.