MAX232 help!

firestorm.v1

I'm about to rip my hair out on this one.

I'm using a Max232 chip I received from TI and I can't get the receivers to work. I've written a small program to receive data from the I/O pin connected to the receiver on the chip and print that character out using DEBUG.

' {$STAMP BS2}
' {$PBASIC 2.5}

sData VAR Byte

Main:
SEROUT 0,396,[noparse][[/noparse]"Enter Prompt"]
SERIN 1, 396, [noparse][[/noparse]sData] ' baudmode set for BS2
DEBUG "Received=",sdata,CR

END

The program was derived from the help manual and I added the debug statement.

I have pin 0 connected up to pin 11 or 10 (I've tested both with the same result) and the transmitters seem to work becuase I get "Enter Prompt" in my hyperterminal window. at 9600 baud, no parity, 8 data bits/

I have pin 1 to receive a character from either pins 9 or 12 and the receivers don't work at all resulting in garbage text. I have tried disconnecting all the RS-232 leads (14,7,13,8) from the max232 with no change in results. I hit the reset button and the BS2 doesn't stay running long at all, the power light just "blips" and I get "received=" and some garbage character. I've checked my baud rate and made sure I was sending at 9600. I've tried at 2400 baud to 9600 baud each with the same result.

What am I doing wrong? I've checked three chips, all with the same effect. I've checked my serial port wiring a dozen times and I can't get this to work.

This is the datasheet of the max232 I'm working, specifically I'm using the max232ECN
http://focus.ti.com/docs/prod/folders/print/max232e.html

As always any assistance with this is greatly appreciated!

Bruce Bates

firestorm -

I suspect it's not as bad as you may think it is. Chances are it's nothing but a timing problem. From a time sequence point of view, here's what's happening:

·············· From Stamp········································At Hyperterminal

1.·Transmit characters "Enter Prompt"··········· Receive data "Enter Prompt"

2. Read one BYTE of data transmitted··<==*· Display "Enter Prompt"

3. Display "Received =" <nothing!>···············Transmit data entered

Data transmitted from Hyperterminal·has been·lost·at this point by a premature read.

* "<==" is where the timing problem actually occurs

To fix this we'll add an arbitrary rule. Whenever we send data from Hyperterminal to the Stamp we will prefix the data with a special character; arbitrarily we will choose a ":" (colon). Now we can change the original program just slightly as follows -

' {$STAMP BS2}
' {$PBASIC 2.5}
'Note - Received data MUST be preceeded by a colon (":")

sData VAR Byte

Main:
SEROUT 0,396,[noparse][[/noparse]"Enter Prompt"]
SERIN 1, 396, [noparse][[/noparse]WAIT(":"), sData] ' baudmode set for BS2· <<== NOTE WAIT sub-parameter added
DEBUG "Received=",sdata,CR

END

Simple enough, and now the Stamp will wait forever until it sees a ":" and then it will accept one BYTE of data after that character, and subsequently display that one BYTE of data.

Regards,

Bruce Bates


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There is no pleasure in having nothing to do;
the fun is in having lots to do, and not doing it!

firestorm.v1

Normally I would be inclined to agree with you however I tried again using port 16 (the debug port) and the program works as advertised. THe only change I made is replace the "DEBUG" command on the last line with a SEROUT command as the debug command changes the baudrate to 9600.

I tested it half a dozen times, sometimes letting the BS2 sit idle for 10 mins without touching the console. It has never timed out, returned garbage or ended unexpectedly.

Here's the modified code:
' {$STAMP BS2}
' {$PBASIC 2.5}

sData VAR Byte

Main:
SEROUT 16,396,[noparse][[/noparse]"Enter Prompt"]
SERIN 16, 396, [noparse][[/noparse]sData] ' baudmode set for BS2
SEROUT 16,396,[noparse][[/noparse]"Received=",sdata]
END


Here's what it returned, I used the "a" key.
Enter PromptaReceived=a

This output is expected, I forgot to send the carriage return command at the end of the SEROUT statements.

The garbage is coming from somewhere in the circuit but I am lost as to where. I have tried breadboarding several other ICs with the exact results.

Something odd I noticed is that with nothing connected to the I/O pin, it will time out at a somewhat random time and yield garbage characters again. Am I missing a resistor or two that could be causing it to pick up extraneous signals?

Franklin

Could you draw a diagram of your wiring between the max and the stamp?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

firestorm.v1

Forgive my horrid MS-paint picture, but here's how I have it wired up:

I have hooked it up this morning and now RXD doesn't receive anything, the chip just sits and waits. I don't know if I have the receiver hooked up backwards, but now instead of timing out it doesn't get any input at all.

I'm using one of those Radio shack RS-232 signal checkers and I can see that the TxD (to the BS2) light is flashing it just doesn't show up on the stamp itself. Does anyone know of how I could wire up an LED and resistor to the RXD pin to ensure I'm getting anything from the serial port? (in case of a loose connector haunting me?)

Here's the updated code, note that I'm using 2400,n,8,1,true for my serial port pins 0,1.

' {$STAMP BS2}
' {$PBASIC 2.5}

sData VAR Byte

Main:
SEROUT 0,396,[noparse][[/noparse]"Enter Prompt"]
SERIN 0, 396, [noparse][[/noparse]sData] ' baudmode set for BS2
'SEROUT 0,396,[noparse][[/noparse]"Received=",sdata]
DEBUG "Received=",sdata
END

PJAllen

In your drawing you've noted a 25-pin connector is in use, presumably your terminal·(how old is that?).·

If it's male, on the terminal/computer/DTE: pin 2 (TD) is output, if idle it should present a negative voltage [noparse][[/noparse]-3 to -24V]; pin 3 (RD) is input

(with a 9-pin it's just the opposite, 2 is RD and 3 is TD)

Post Edit --> 25-p extra clarification



Post Edited (PJ Allen) : 2/10/2008 10:59:01 PM GMT

firestorm.v1

Well. this is interesting..

Apparently I know how to use an oscilliscope beyond hooking it up to my stereo and "watching" the sound...


I connected the oscope to the RS232 side of the receiver and laid into a key with Hyperterminal. The scope showed the rs232 signals coming above the 0v line (I don't know if that's what it's called). On a hunch, I connected it to the BS-2 side of the max232, and the line appeared below the 0v line! If I am reading this thing correctly, this means that I'm getting a negative voltage on the pin between the BS2 and the MAX232. Would that affect serial operation epecially considering since connecting the scope to the IO pin producing the "Enter Prompt" produces similar positive lines?

I measured the voltage of the TX/RX pins coming out of the USB to serial adapter and it's 4v when transmitting on pin 2 and -1v on pin 3 on the DB9 connector.

The reason I was using a 25 pin connection is because my serial port tester and my RS232 breakout adapter are both 25 pin and easier to work with.

Curiouser and curiouser......

terry_bear

You may need to back up and start over with Hyperterm. Your code is set for 2400 baud and you mentioned Hyperterm being set at 9600 baud. With a baud rate conflict the symptoms can be anywhere from garbage characters to none at all. Also, your original code seems to indicate that you are using Hyperterm and the Debug port at the same time. Do you have two Com ports on your PC? Your original connections look OK, but in the heat of troubleshooting, you may have moved one or more (how would I know THAT? <grin>) Also, recheck all of your parameters for the same reason...

Terry

firestorm.v1

Ok, Now I've seen it all!

I have three serial ports, COM1 is a physical RS-232 port hardwired to the computer's motherboard.
Com 3 is a USB dongle as is COM4.

Add to that horse mess the fact that I have two (supposed to be) cross compatible Max232 chips, one by Ti (Max232ECN) and one by Maxim-IC (MAX232CPE).

For all intensive purposes, COM4 is the debug port that stays at 9600. I do not use it in my input, it is there only to tell me what the BS2 is receiving.

I connected the Ti chip up and that's what started this thread was the fact that "junk" was coming in off of the USB serial port (COM3) and that SERIN didn't appear to be working as expected.

I was really confused and even went so far as to bust out the old o-scope to see if I could identify the cause of the issue. I even went so far as to connect the two USB ports up together using a chain of adapters (yes, a chain about a foot long) and setting up two hyperterminals, one on COM3 and the other on COM4 to ensure that I didn't have a bad serial port. Both were set at 2400,n,8,1 as that's how it's set in my program.

After the hypertrm test showed that both USB adapters were operating normally, I continued to bash my head in trying to get this to work. I tried swapping between the Ti chip and the Maxim chip with no avail. All the time I had been using the 2nd set of xcvrs because they were right across the IC from each other and I didn't want to miswire it. I had remembered that there were other topics in this forum saying that the USB adapters don't put out the "proper" RS-232 signalling voltages so I grabbed the original cable from the WAM kit and connected that to the hardwired port on my motherboard.

No, not done yet.

I took out the Ti chip and replaced it with the Maxim chip,wired it up to use the first set of transceivers connected the true serial port (COM1) to my franken-serial-adapter and pressed reset. The words "Enter Prompt" came across the screen, and the light on the homework board remained green. I said some prayers and pressed the letter "D", and the light went out. I checked the debug window and lo and behold I saw "Received=D" in the window! Shocked and astounded, I did this several more times to prove it wasn't a fluke.

Thinking that I was in the clear, I swapped back to the USB port and hit the reset button. Instead of getting the "Enter Prompt" in the window, I instead got garbage. I reprogrammed a DO... LOOP command into my program and tried it again with the same result. Swapped back to COM1 (the real serial port) returned full functionality!

Now that I have it working with the Maxim chip, my next project is to figure out why the Ti chip is so different and what the difference is between the USB serial ports and the "real" serial ports are.

This continues to freak me out! Any suggestions as I'd really like to use the USB serial ports, I bought them specifically for this project and have had no problems with the DEBUG usb serial port.


I guess this is proof that not all USB adapters are created equal nor are MAX232 chips?

Post Edited (firestorm.v1) : 2/11/2008 3:32:47 AM GMT

terry_bear

Well, a possible suggestion...

The reason for the max232 chip in the first place is because "true" EIA RS-232 has much greater voltage transitions than are supplied by serial ports on micro-controllers. Some PCs adhere to the standard; some don't. The USB-serial adapter probably does not. None of this would explain why the TI chip doesn't work, but might explain why the Maxim chip does when connected to the true serial port. By the way USB-serial adapters are NOT all created equal when it comes to signal lines. Apparently a lot of them will not allow programming a Stamp.

Anyway, it is good to know that you're making progress...

Terry