Frozen RS232 device with ESP32 + TTL Converter

[digsub]

Hi,

I have a SparkFun ESP32 Thing and MAX3232 Converter Module with wiring and code as shown. Of course, I'm just trying to read off RS232 and do something after each 0x7e20 is received. But, the data device keeps getting hung and no serial reading takes place. Swapping Arduino UNO/SoftwareSerial (additional code below) with the same data device and MAX3232 works fine.

The data device just won't work with the ESP32 Thing despite different HardwareSerial combinations of UART and "safer" RX/TX (e.g. 16, 17) pins as well as a 4400mAh 3.7v to rule out excessive Wifi power drain. I've also unsuccessfully tried the ESP32 Thing with ESP SoftwareSerial (https://github.com/jdollar/espsoftwareserial/)

So, any hardware or software advice as to why my ESP32 Thing setup fails where the Arduino UNO succeeds will be GREATLY appreciated.

Untitled.png (300.09 KiB) Viewed 12740 times

... with this code

Code: Select all

/*  ESP32 Thing code */
HardwareSerial Serial1(1);
#define SERIAL1_RXPIN 13
#define SERIAL1_TXPIN 12

void setup() {
  
  Serial.begin(115200);
  Serial1.begin(1200, SERIAL_8N1, SERIAL1_RXPIN, SERIAL1_TXPIN);

}

void loop() {

  while(Serial1.available()<2);
  if (Serial1.read() == 0x7e && Serial1.read() == 0x20) {
    Serial.println("Header received!");
  }
  
}

Code: Select all

/*  Arduino UNO code */
#include <SoftwareSerial.h>

SoftwareSerial Serial1(13,12);  // RX, TX

void setup() {

   Serial.begin(115200);
   Serial1.begin(1200);

}

void loop() {

  while(Serial1.available()<2);
  if (Serial1.read() == 0x7e && Serial1.read() == 0x20) {
    Serial.println("Header received!");
  }
  
}

[digsub]

According to http://support.iteadstudio.com/support/ ... 1000014882, GPIO12 has a flash conflict for the ESP32 Thing. I also discovered TX on the Converter going LOW (e.g. transiently during ESP32 reset) caused the RS232 device to freeze. I only care about RX so my new working wiring and code are as follows... Though seemingly solved, any thoughts?

Untitled.png (323.6 KiB) Viewed 12726 times

Code: Select all

HardwareSerial Serial2(2); // pin 16=RX, pin 17=TX

void setup() {
 
 Serial.begin(115200);
 Serial2.begin(1200);
}

void loop() {

 while(Serial2.available()<2);
  if (Serial2.read() == 0x7e && Serial2.read() == 0x20) {
    Serial.println("Header received!");
  }
  
}

[cmorgan]

Is there hardware flow control on the RS232 device? I've seen cases where the flow control wasn't connected and depending on environmental factors, temperature, humidity etc, the floating flow control lines would cause communications to stop in one direction or the other.

[digsub]

Hi cmorgan,

Hardware flow control is not connected per the following data device pin-outs. Maybe the ESP32 Thing (during reset) causing transient LOW on the Converter Module TX results in those unconnected flow control lines floating differently and thus the RS232 freeze? Correspondingly, the Arduino seems to work because it doesn't cause the LOW.

Adapter DB9 pin-outs:
Pin 1 N/C
Pin 2 receive data into the PC
Pin 3 transmit data from the PC
Pin 4 N/C
Pin 5 GROUND
Pins 6,7, and 8 are N/C

My solution for the ESP32 Thing to connect the Converter Module TX to 3.3v feels kludgy, so I'd rather understand exactly where/how/why the ESP32 Thing causes the transient LOW in the first place... and then maybe control it in software? For example, I tried this code but the ESP32 Thing's pin 22 still goes LOW during reset.

Code: Select all

HardwareSerial Serial1(1);
#define SERIAL1_RXPIN 23 
#define SERIAL1_TXPIN 22 

void setup() {

 pinMode(SERIAL1_TXPIN, OUTPUT);
 digitalWrite(SERIAL1_TXPIN, HIGH);

 // also tried pinMode(SERIAL1_TXPIN, INPUT_PULLUP);
  
 Serial.begin(115200);
 Serial1.begin(1200, SERIAL_8N1, SERIAL1_RXPIN, SERIAL1_TXPIN);
}

void loop() {

  while(Serial1.available()<2);
  if (Serial1.read() == 0x7e && Serial1.read() == 0x20) {
    Serial.println("Header received!");
  }
}

[cmorgan]

It doesn't look like the MAX3232 has any enable/disable or flow control support although maybe the digital inputs are intended for that purpose. So I'm thinking it isn't the MAX3232 causing the issue, is the other end of the device expecting flow control (a computer?) I don't see how strapping that line low/high fixes the issue.

Are you configuring the ESP32 to run without flow control? I looked briefly at the source code you posted but didn't see anything there.

[Robissaum]

Up.Same problem.