MAX3221: With RS232 - Not working

The two schematics are essentially identical.

The default (idle) state of the UART protocol is high for logic-level signals and negative for RS-232 bus signals.

The third link is not accessible.

Can you please elaborate on this.

If condition I have are right or wrong?

Hi Hitesh,

I don't necessarily see a problem with the schematics. 

Hitesh Bajaj said:

We tried to Signal Probe both of them - For Console UART - By default state is low while for RS232 on its high, Attaching the snapshot.

This sounds like it's behaving as we would expect. On the TTL side a logic high will result in a negative voltage on the RS232 side. A logic low on the TTL side will result in a logic high on the RS232 side. It's basically inversed. 

As Clemens pointed out, I can't see the scopeshot either. Can you upload the scopeshot to the forum? 

Ideally we should look at the R output, D input, and the RS232 signal all in one scopeshot to see if it's toggling correctly and the voltages are swinging to the correct amplitudes. 

Hitesh Bajaj said:

Console UART is passing, while other one with RS232 is failing.

Did you perform the loopback test on both boards? I assume what you're saying is when you connect the two boards together is when you see a failure occur.

-Bobby

Hi Team,

We have Sam9x60 - And Using Two UARTS  (MAX3221)

1) Console UART 

2) RS232

BOBBY said:

As Clemens pointed out, I can't see the scopeshot either. Can you upload the scopeshot to the forum? 

Following is the Signal Probe on both UARTs (MAX3221 - Pin 9)

SCOPE PROBE - R9 PIN

BOBBY said:

Did you perform the loopback test on both boards? I assume what you're saying is when you connect the two boards together is when you see a failure occur.

- I am performing a loopback test by Shorting RX/TX pins on both UARTS.

- For Console UART - RX/TX is shorted

-For RS232 - Pin2 & Pin3 of RS232 Port is shorted.

Attached is the output of the echo test .

Upper 2 Terminals are Console UART - 1) cat /dev/ttyS4 2) echo "" >/dev/ttyS4

Bottom 2 Terminals are RS232 UART - 1) cat /dev/ttyS6 2) echo "" >/dev/ttyS4

Echo Test Snapshot Both UARTS

You can see we are not getting the output on the bottom left terminal ( we ideally should be getting the output).

There are no two boards - Both (Max3211) is on same board - With Sam9x60 and Linux running on it.

Please show an oscilloscope trace of pins 11 and 13 of the console UART transceiver when you are sending something, and zoom in far enough so that some individual bits can be seen.

Are there any other components connected to the line at pin 13?

Hi Hitesh,

As Clemen's pointed out. We want to see the individual bits of the signal on both the TX TTL side and the RS232 side. Currently we are zoomed too far out to actually observe the bits toggling. I would also like to point out that you should be using an analog scope to observe these signals and not a digital scope. We want to verify the analog portion of the signal looks okay.

-Bobby

Hi Team,

For Console UART - Please find the attached snapshot of the Logic Analyser Output - Analog.

Console UART Pins Probe

It shows probe for Pins 8,9,11,13

In this, I have ShortConsole UART Pins Probeed the RX/TX Pin. And did echo "1" > /dev/ttyS4

Console UART Seems to be working for us.

RS232 is not working. Please let me know if you need anything on this.

Hi Team,

I am checking pin10 (Invert INVALID) - For Console UART - its 3.3v while for RS232 UART - its 0V. What can be the reason?

Hi Hitesh,

Hitesh Bajaj said:

I am checking pin10 (Invert INVALID) - For Console UART - its 3.3v while for RS232 UART - its 0V. What can be the reason?

The invalid pin going low means that the RIN (pin 8) is seeing a voltage between -0.3V and +0.3V. In RS232, generally an active or live bus is at a logic level of +/-5V. It sounds like the device is going into the power down state. 

Are you sure the RIN pin of the device is making proper connection to the Dout pin of the other RS232 device? 

Can you also verify that the FORCEON and FORCEOFF pins are tied together and to Vcc using a digital multimeter (using continuity test)? Do this with the device powered off.

The scopeshot of pinout of the device you're measuring is seeing an RS232 voltage (RIN pin 8). 

Everything seems to look like it's swinging to the correct voltages. (the resolution is very bad though). Is the scopeshot you have during the loopback test? We want to see the scopeshot of the 'not working' set up to see if the voltages are swinging correctly during the non-working case. I would also recommend sending one byte and zooming into that one byte to verify the bits of the byte are sent on the RS232 side.

-Bobby

BOBBY said:

Are you sure the RIN pin of the device is making proper connection to the Dout pin of the other RS232 device? 

I short the pins 2 & 3 of RS232 Connector, And I am unable to see the echo test passing.

When I tried Shorting pin 13 (DOUT) & pin 8 (RIN) directly, I was able to see the echo test passing.

I will try to Short Pin 2 & Pin 3 of RS232 Connector with new wire and carry out experiment.

BOBBY said:

Can you also verify that the FORCEON and FORCEOFF pins are tied together and to Vcc using a digital multimeter (using continuity test)? Do this with the device powered off.

Yes, they are tied togather, Continuity Test is passing on them

For Me:

BOBBY said:

Can you also verify that the FORCEON and FORCEOFF pins are tied together and to Vcc using a digital multimeter (using continuity test)? Do this with the device powered off.

Will Lookinto this.

2. Echo test - Onebyte & get scopeshot for the same.

Also One More Observation:

1) On Console UART -

When Shorting the RX/TX pins Console UART - Voltage Levels on Pin13 ~ (5.5V-6.0V) which also is same on Pin 8 ~ (5.5V-6.0V). I am attaching the snapshot.

ScopeShot-ConsoleUART

2) On RS232 Connetor UART

When Shorting the RX/TX pins (Pin 2/3) on  RS232 Connector UART  - Voltage Levels on Pin13 is ~ (5.5V-6.0V) while on  Pin 8 ~ (0.4V-0.6V). Which is not same as Pin13. I am attaching the snapshot.

ScopeShot-RS232UART

Is this can be an issue?

Also Please find the below

BOBBY said:

We want to see the scopeshot of the 'not working' set up to see if the voltages are swinging correctly during the non-working case. I would also recommend sending one byte and zooming into that one byte to verify the bits of the byte are sent on the RS232 side.

RS232-ScopeShot-Onebyte

ConsoleUART_ScopeShot_onebyte

Hi Team,

Echo Test for RS232 Is Passing Now. Attaching the snapshot of one byte echo test.

RS232_Scopeshot_OneByte_Working

Passing the echotest.

However, I am unable to communicate via tera-term Windows - My Board . Following is My Setup.

1) Connected USB-RS232 Cable

2) On Sam9x60 Linux did following

stty -F /dev/ttyS6 115200 cs8 -cstopb -parenb -echo

3) Created following script

#!/bin/bash

# Send a single byte (ASCII 'A') every 5 seconds, 5 times
for i in {1..5}; do
echo -n "A" > /dev/ttyS6
sleep 5
done

4) Under Device Manager Can see Com6 attaching snapshot Device Manager - Com6

5) Open TeraTerm on Windows PC - Com6 selected with following settings

Set the baud rate to 115200, data bits to 8, parity to None, stop bits to 1, and flow control to None

6) Run the script on linux, created in step 3.

Nothing is received on teratom. Attaching the snapshot of sending data

SendData_RS232_Cable

7) Also when i type on teraterm, nothing can been seen on Scopes as well as on cat /dev/ttys6

What can be wrong here?

Hitesh Bajaj said:

When Shorting the RX/TX pins Console UART - Voltage Levels on Pin13 ~ (5.5V-6.0V) which also is same on Pin 8 ~ (5.5V-6.0V). I am attaching the snapshot.

This is what we should expect.

Hitesh Bajaj said:

When Shorting the RX/TX pins (Pin 2/3) on  RS232 Connector UART  - Voltage Levels on Pin13 is ~ (5.5V-6.0V) while on  Pin 8 ~ (0.4V-0.6V). Which is not same as Pin13. I am attaching the snapshot.

This means they are not actually connected/shorted together. This could be an issue with the traces not connecting to the jumper/counter you're using or the device's pin is not making good contact with the board.

This seems like some kind of hardware problem.

Hitesh Bajaj said:

Echo Test for RS232 Is Passing Now. Attaching the snapshot of one byte echo test.

RS232_Scopeshot_OneByte_Working

Passing the echotest.

What exactly did you change to fix this? Were you able to find the root cause of the disconnect?

Hitesh Bajaj said:

1) Connected USB-RS232 Cable

2) On Sam9x60 Linux did following

stty -F /dev/ttyS6 115200 cs8 -cstopb -parenb -echo

3) Created following script

#!/bin/bash

# Send a single byte (ASCII 'A') every 5 seconds, 5 times
for i in {1..5}; do
echo -n "A" > /dev/ttyS6
sleep 5
done

4) Under Device Manager Can see Com6 attaching snapshot Device Manager - Com6

5) Open TeraTerm on Windows PC - Com6 selected with following settings

Set the baud rate to 115200, data bits to 8, parity to None, stop bits to 1, and flow control to None

6) Run the script on linux, created in step 3.

Nothing is received on teratom. Attaching the snapshot of sending data

SendData_RS232_Cable

7) Also when i type on teraterm, nothing can been seen on Scopes as well as on cat /dev/ttys6

What can be wrong here?

I'm not very famillar with the software/programming side of what you're seeing.

I would suggest verifying on the scope of the 'A' character is being sent properly/received on the Rout pin and sent on the Din pin.

-Bobby

BOBBY said:

Passing the echotest.

What exactly did you change to fix this? Were you able to find the root cause of the disconnect?

Yes, Actually On the RS232 Connector, I was shorting the Pins(2/3) from Left to Right, but the pins starts#1 from Right to left.

BOBBY said:

Nothing is received on teratom. Attaching the snapshot of sending data

SendData_RS232_Cable

When I send data, You can see above snapshot of Sending data, Do you think that is Right? Activity seen on Pin 11(DIN) & Pin 13 (DOUT), but nothing is recieved on Teraterm.

BOBBY said:

I'm not very famillar with the software/programming side of what you're seeing.

Can you please point some one from your team who can confirm this?

Hitesh Bajaj said:

BOBBY said:

Passing the echotest.

What exactly did you change to fix this? Were you able to find the root cause of the disconnect?

Yes, Actually On the RS232 Connector, I was shorting the Pins(2/3) from Left to Right, but the pins starts#1 from Right to left.

Gotcha, this would definitely explain the waveform we saw.

Hitesh Bajaj said:

When I send data, You can see above snapshot of Sending data, Do you think that is Right? Activity seen on Pin 11(DIN) & Pin 13 (DOUT), but nothing is recieved on Teraterm.

No, there should be 8 bits being flipped when you send an ASCII character 'A'. You may just be triggering incorrectly on your scope/tool or the hardware is not actually sending the data out.

Hitesh Bajaj said:

I'm not very famillar with the software/programming side of what you're seeing.

Can you please point some one from your team who can confirm this?

Our team focuses on analog support for our products like the RS232 transceivers. We don't provide the digital support for using the device, this ultimately is the customer's responsibility since the amount of software/interfaces that RS232 can be used with is vast.

-Bobby

Hi Bobyy,

Please find the Scopeshot of Sending a byte on two scenarios.

1) With Pin 2/3 Shorted on RS232 Connector - ScopeShot_ShortedRX_TX_Sendbyte

2) With RS232 Cable Connected (DB9) on board to PC (USB) -  ScopeShot_RS232Cable_Sendbyte

Scenario#1, It's an echo test, and I can see the byte received on another terminal (cat /dev/ttyS6)

For Scenario#2 - I cannot get anything on the PC tera term.

Let me know what is seen wrong here.

BOBBY said:

No, there should be 8 bits being flipped when you send an ASCII character 'A'. You may just be triggering incorrectly on your scope/tool or the hardware is not actually sending the data out.

So, You mean to say there must be eight times flipping going on the scope? Currently its DMA transfer.

For your reference the Following code is used to send data:

#!/bin/bash

# Configure the serial port /dev/ttyS4
stty -F /dev/ttyS6 115200 cs8 -cstopb -parenb -echo

# Function to send a single byte
send_byte() {
local port=$1
local byte=$2
echo "$byte" > $port
}

# Send the byte 5 times with 5-second intervals
for i in {1..5}; do
send_byte /dev/ttyS6 "\x41" # Send the byte representing 'A'
printf "Sent byte 'A' (0x41) to /dev/ttyS6\n"
sleep 5
done

Hitesh Bajaj said:

1) With Pin 2/3 Shorted on RS232 Connector - ScopeShot_ShortedRX_TX_Sendbyte

You're zoomed too close, this looks like one bit I think. Definitely doesn't look like an ASCII 'A'

Hitesh Bajaj said:

2) With RS232 Cable Connected (DB9) on board to PC (USB) -  ScopeShot_RS232Cable_Sendbyte

The signal here doesn't look right. The signal send send 0100 0001 for ASCII 'A' 

DOUT is stuck at 1V for some reason. RIN is GND, it seems like the pin connected to an DOUT signal. This seems like a hardware problem.

Hitesh Bajaj said:

So, You mean to say there must be eight times flipping going on the scope? Currently its DMA transfer.

ASCII A is a HEX 0x41 or binary 0100 0001 so you should see 4 bits flip in your scope shot for an ASCII byte of 'A'

-Bobby

BOBBY said:

1) With Pin 2/3 Shorted on RS232 Connector - ScopeShot_ShortedRX_TX_Sendbyte

You're zoomed too close, this looks like one bit I think. Definitely doesn't look like an ASCII 'A'

For the echo test, it is passing- When we do cat /dev/ttyS6 - the Ascii byte is received.

Please See the attached snapshot Pin2/3 Shorted Byte Received

In the above screenshot, On Right hand side, we have a script which sends byte 'A' and on left side (cat /dev/ttyS6) - it can been seen that '\x41' is recieved.

Can the scope shot seem one bit because it's a dma transfer? Following is seen on linux screen

root@itm509-prod:~# atmel_usart_serial atmel_usart_serial.3.auto: using dma0chan4 for rx DMA transfers
atmel_usart_serial atmel_usart_serial.3.auto: using dma0chan5 for tx DMA transfers

BOBBY said:

DOUT is stuck at 1V for some reason. RIN is GND, it seems like the pin connected to an DOUT signal. This seems like a hardware problem.

Can you elaborate on what should be the DOUT Default Value?  What can be the problem?

Hitesh Bajaj said:

Can the scope shot seem one bit because it's a dma transfer? Following is seen on linux screen

I don't know what a DMA transfer is. If you are sending the data out, it should appear on the Din pin (your input) and then appear on the Dout pin. If you are doing a loop back then it should then appear on the Rin pin and then appear on the Rout pin. In the loopback case, the Dout and Rin should look the same. Rout and Din should also look the same but maybe with a slight time delay/shift.

Hitesh Bajaj said:

Can you elaborate on what should be the DOUT Default Value?  What can be the problem?

If you are in an idle state (TX is logic high) then DIN should be a logic high and Dout should be -5V or so. If the driver is disabled, then I suspect you will see the signal around GND/0V.

-Bobby

BOBBY said:

If you are sending the data out, it should appear on the Din pin (your input) and then appear on the Dout pin. If you are doing a loop back then it should then appear on the Rin pin and then appear on the Rout pin. In the loopback case, the Dout and Rin should look the same. Rout and Din should also look the same but maybe with a slight time delay/shift.

Hi Bobby, 

As you mentioned - Highlighted in the quote above, the Attached Snapshot has the same behavior.ScopeShot_ShortedRX_TX_Sendbyte

RS232(8) -RIN has the same scopehot as RS232 (13) - DOUT.

RS232(9) - ROUT has the same scopeshot as RS23(11) - DIN.

Please confirm, if you feel the same. Scopeshots are the same for the above pins as mentioned. The only thing worry for me, is you mentioned for 1byte - there should be a flip for 4-bit flip in scope. Which I am unable to see. 

With the Echo test (Shorted pin 2/3 on RS232 Connector) - I receive on (cat /dev/ttyS6) whatever I send on (echo /dev/ttyS6) .

Should I consider this echo test pass or failed? I am getting data but scopeshot is not showing 4bit flip. But Scopeshot has same behaviour as you mentioned.

BOBBY said:

ASCII A is a HEX 0x41 or binary 0100 0001 so you should see 4 bits flip in your scope shot for an ASCII byte of 'A'

With RS232 Cable Connected - Its not working. What can be the issue?

Hitesh Bajaj said:

As you mentioned - Highlighted in the quote above, the Attached Snapshot has the same behavior.ScopeShot_ShortedRX_TX_Sendbyte

RS232(8) -RIN has the same scopehot as RS232 (13) - DOUT.

RS232(9) - ROUT has the same scopeshot as RS23(11) - DIN.

Please confirm, if you feel the same. Scopeshots are the same for the above pins as mentioned. The only thing worry for me, is you mentioned for 1byte - there should be a flip for 4-bit flip in scope. Which I am unable to see. 

I think you might be zoomed too close into the waveform. You probably need to adjust the horizontal scaling. I think we may be looking at one bit instead of 8. 

One thing that confuses me is the DIN pin (pin 11 of scopeshot label) is showing it goes to 1V when I think the logic high should be 5V like the Rout looks like. I'm not sure if your o-scope  is incorrectly labeling the Y axis here the probe is causing an issue but the dip we're seeing might not be real since the other signals look like they are toggling the way we expect. 

Hitesh Bajaj said:

With the Echo test (Shorted pin 2/3 on RS232 Connector) - I receive on (cat /dev/ttyS6) whatever I send on (echo /dev/ttyS6) .

Should I consider this echo test pass or failed? I am getting data but scopeshot is not showing 4bit flip. But Scopeshot has same behaviour as you mentioned.

BOBBY said:

ASCII A is a HEX 0x41 or binary 0100 0001 so you should see 4 bits flip in your scope shot for an ASCII byte of 'A'

With RS232 Cable Connected - Its not working. What can be the issue?

If the terminal shows it's receiving the byte correctly then it means the data did go through, no denying that. I think this is just the scope isn't properly adjusted on the Y-axis or your triggering on the wrong byte. 

-Bobby

BOBBY said:

If the terminal shows it's receiving the byte correctly then it means the data did go through, no denying that. I think this is just the scope isn't properly adjusted on the Y-axis or your triggering on the wrong byte. 

Scopeshot for Echo Test: ScopeShot_ShortedRX_TX_Sendbyte (ECHO TEST) - I am receiving what I Send - Seems passsing.

But with RS232 Cable Connected : ScopeShot_RS232Cable_Sendbyte - Unable to See anything on Teraterm on Windows - Seems Failing.

So, What can be wrong with RS232 - a USB Cable Connected with a Windows PC? I have already updated this scenario above.

Following is the scenario 

1) Connected USB-RS232 Cable

2) On Sam9x60 Linux did following

stty -F /dev/ttyS6 115200 cs8 -cstopb -parenb -echo

3) Created following script

#!/bin/bash

# Send a single byte (ASCII 'A') every 5 seconds, 5 times
for i in {1..5}; do
echo -n "A" > /dev/ttyS6
sleep 5
done

4) Under Device Manager Can see Com6 attaching snapshot Device Manager - Com6

5) Open TeraTerm on Windows PC - Com6 selected with the following settings

Set the baud rate to 115200, data bits to 8, parity to None, stop bits to 1, and flow control to None

6) Run the script on linux, created in step 3.

Nothing is received on teratom. Attaching the snapshot of sending data SendData_RS232_Cable

Hi Bobby,

Please find the attached scopeshots for echo test - (RX/TX - Pin3/2 - Shorted on RS232 Connector)

1) Sampling Rate - 50S/s - Board3_ScopeShot_RS232Connector_Shorted_SendByte - 50S/s - 

2) Sampling Rate - 6.25kS/S - Board3_ScopeShot_RS232Connector_Shorted_SendByte_625KSS - (Flips can be seen)

3) Sampling Rate - 15.625kS/S - Board3_ScopeShot_RS232Connector_Shorted_SendByte_15_625KSS.PNG (Flips can be seen)

The Echo Test is Passing. Let me know if the Sampling Rate -15.625ks/S for Capture is OK.

Sending the data with the following configuration (Baud Rate: 115200)

stty -F /dev/ttyS6 115200 cs8 -cstopb -parenb -echo

Still unable to communicate when putting RS232 -USB cable to the connector.

Hitesh Bajaj said:

1) Sampling Rate - 50S/s - Board3_ScopeShot_RS232Connector_Shorted_SendByte - 50S/s - 

2) Sampling Rate - 6.25kS/S - Board3_ScopeShot_RS232Connector_Shorted_SendByte_625KSS - (Flips can be seen)

3) Sampling Rate - 15.625kS/S - Board3_ScopeShot_RS232Connector_Shorted_SendByte_15_625KSS.PNG (Flips can be seen)

I think based on the last scope, you're first two scopeshots at the lower speeds not flipping because you are zoomed in too close so we only see a single bit. You will need to modify the X-Axis to be able to see all the bits. 

The last scopeshot looks close to what we want but it seems like the scope you are using is way too low resolution so we end up seeing an aliased signal. (signal is undersampled by the scope). If you're under sampling it is better to use a lower speed and then just zoom out then to use a fast speed with under sampling. 

My guess is because you're using some kind of logic analyzer with lower scope capabilities. It would be easier if you had a dedicated analog scope to perform the measurements.

Hitesh Bajaj said:

But with RS232 Cable Connected : ScopeShot_RS232Cable_Sendbyte - Unable to See anything on Teraterm on Windows - Seems Failing.

Something is definitely wrong with the signal here, Dout should not be 1V and RIN should not be GND if you connected this to another RS232 transceiver with a cable. I think something might be wrong with the cable or the connection to the other board.

-Bobby

Hi Team,

We got UART Working with RS232 Cable.

Created a NULL Modem and its working now.

In Design, We have to change DOUT going to PIN 2 now (Currently PIN3) on Connector and RIN going to PIN3(Currently PIN2) on Connector.