More RS232 handshake woes

[Kevin Boone]

Hi folks

I appreciate that this is another obscure one, but folks who look at this forum seem to be OK with obscure, so I hope you won't object to another one.

I'm trying to fit my RC2014 system (with SC130 motherboard) with real RS232 ports. I want eventually to be able to connect a real serial terminal using a real null modem cable. I also in the meantime need to be able to connect a terminal emulator via a USB->RS232 adapter, which also needs a null modem cable.

I'm using a pair of MAX232 chips to do the level conversion. I have one MAX232 doing Tx/Rx, and another (I thought) doing CTS/RTS.

The basic sending and receiving of data (Tx/Rx) works fine, but hardware flow control does not. I'm using the 'com0' (console) serial port on the SC130, because I'm aware that the com1 port does have any hardware flow control support. The com0 port does flow control perfectly fine with the FTDI-style serial-USB adapter supplied with the SC130 board, so I'm sure that set-up, software, etc. is fine. But my 5V->RS232 converter is not fine, despite hours and hours of checking and fiddling. The fact that the Rx/Tx part works fine suggests to me that I haven't just misunderstood how to use the MAX232.

In my converter, I wire the Tx, Rx, CTS, and RTS lines straight through, because they are correspondingly swapped in the null modem cable. That is, Rx/Tx, RTS/CTS, and DSR/DTR are swapped. So far as I know, this is the conventional arrangement of such a cable.

Anyway, after several hours of beating my face against the bench in frustration, I thought I'd check how the original serial->USB adapter was wired, because this works fine.

On the SC130, the terminals of the serial ports are labeled 0V, Rt, 5V, Rx, Tx, Ct. I presumed (but am now not sure) that 'Rt' and 'Ct' are 'RTS' and 'CTS'. Rx on the SC130 goes to Tx on the USB adapter, and vice versa. Rt on the SC130 goes to CTS. So far, this is what I expected.

But...

The pin on the SC130 labeled 'Ct' does not go to the 'RTS' pin on the USB adapter. Instead it goes to the DTR pin.

I really don't understand this. I expect RTS/CTS to form a pair, and DSR/DTR to form a pair. Why is the 'Ct' pin, which I took to mean 'CTS' paired with DTR?

I'm concerned that the SC130 board, or the RomWBW BIOS, has been designed to work with a particular kind of USB->serial adapter board, and won't actually work properly with real RS232 cables.

Or have I just misunderstood what 'Ct' and 'Rt' stand for? Or is the wiring RTS/CTS + CTS/DTR now conventional?

Better yet -- has anybody actually gotten an SC130 or similar to work with real RS232, including flow control, using conventional wiring, and would be willing to explain?

Best wishes

Kevin

[Phil G]

It works with the FTDI  so you've proven that all is well with the SIO port and the way romwbw handles it.

After that its just level conversion and handshakeing-mix-&match, so you're almost there :)

I remember when every comms engineer had at least one RS232 breakout box, often that was the only way to find 

the right combination before hard wiring a D plug. Our RJ -> D shells were supplied uncommitted (plug in pins) for that reason.

Some devices have a subset of the signals, ie may have dsr or cts but not both,  and again or dtr or rts but not both.

Using dtr/cts is quite common.  Not much help I know but sometimes a mug of tea and a breakout box is the only way :)

Cheers

Phil

[Wayne Warthen]

At the risk of being redundant with Phil's response, I'll just reiterate a couple things.

RomWBW does nothing special to handle the ASCI serial ports on the SC130 (or any other Z180-based system).  It manipulates the chip pins TXA0/RXA0/CTS0/RTS0 (for the first serial port) and does nothing beyond that and has no concept of how the pins are connected to the remote system.

The SC130 does essentially nothing with these signals other than bring them out to the 6-pin header.  It does run the signals through 2K2 resistors which you could bypass if the signals are going directly to a MAX232.  Although I would not expect them to cause a problem.

The SC130 does swap both the RX/TX signals and the RTS/CTS signals compared to the FTDI datasheet.  This is correct because both sides of the connection consider themselves to be DTE.  As far as I can tell, the FTDI TTL-234X-5V does not have a DTR pin, so I wonder what you are looking at?

Not sure it will be helpful, but I am attaching a schematic of a board called the Mark IV.  The board is an SBC and a little more complicated than the SC130, but if you look at the last page you will see how it is connecting the Z180 ASCI0 pins to a level shifter.  In this case, a MAX233 is used, but it is essentially the same as a MAX232.  The MAX233 just incorporates the capacitors internally.

Thanks,

Wayne

[Kevin Boone]

Hi Wayne

Thanks. I've wired my RS232 pretty much exactly as in your schematic, except that I'm using MAX232s.

I've attached a photo of my FTDI-type board; I have two of these from different vendors, and they both have the same pin labeling. Unless I'm really missing something (always possible for me) the bottom of the six pins is labeled DTR.

Maybe it's just mislabeled? But there is actually a 'RTS' connection on the board -- it just isn't brought out to a pin.

Perhaps it doesn't matter where the Z180's CTS pin is connected, because it will never need to be asserted? I mean, the Z180 is likely to be the slower partner in the communication, when using the console port, so the Z180 will probably never have to slow down. The 'real' FTDI cable with the six-pin header does, as you say, have 'RTS' where my board has 'DTR'. So probably I'm using a board that only works by good luck. At least I am now confident that the TX/RX and CTS/RTS swaps ought to work.

I suspect that my flow control is working to some extent because I can get reliable, large file transfers at 38400 baud. Maybe it would go faster, but my Linux machine doesn't offer anything between 38400 and 115200. But the FTDI-style adapter worked fine at 115200. But perhaps that was just good luck?

It's possible, I guess, that I have a USB->RS232 adapter that doesn't do flow control very well. There's a comment from Alan in some other thread about how this might be the case. It seems that some of these adapters do hardware flow control, but they respond so slowly to CTS being asserted that they've send a load of data before they realise they have to stop. Maybe running slower relieves this latency problem somewhat?

I suppose if I can get reliable data transfer at 38400, I should be content with that.

Best wishes

Kevin

PS. While I was fiddling about with the connections on my MAX232s, one of them went into that weird latch-up where they get really hot. This seems to be a well-documented problem whose cause is not obvious. I would be interested to know whether anybody else has seen the same thing, and has a definitive solution.

[Wayne Warthen]

Hi Kevin,

On Wednesday, June 28, 2023 at 12:53:41 PM UTC-7 Kevin Boone wrote:

I've attached a photo of my FTDI-type board; I have two of these from different vendors, and they both have the same pin labeling. Unless I'm really missing something (always possible for me) the bottom of the six pins is labeled DTR.

Maybe it's just mislabeled? But there is actually a 'RTS' connection on the board -- it just isn't brought out to a pin.

OK, so I have seen these adapters before.  I "think" they are geared toward connection to an Arduino.  I believe that the DTR signal coming from a PC (USB side) is used to reset the Arduino.  So, in fact, there is no RTS pin made available for these.  But the pinout of these is for a different purpose, so I don't think you can use that pinout to compare with the FTDI pinout.

Perhaps it doesn't matter where the Z180's CTS pin is connected, because it will never need to be asserted? I mean, the Z180 is likely to be the slower partner in the communication, when using the console port, so the Z180 will probably never have to slow down. The 'real' FTDI cable with the six-pin header does, as you say, have 'RTS' where my board has 'DTR'. So probably I'm using a board that only works by good luck. At least I am now confident that the TX/RX and CTS/RTS swaps ought to work.

I have heard a variety of things about these Arduino-style adapters.  I have heard at least one person claim they don't actually do any flow control at all even though they do seem to indicate a CTS pin.  I have no idea about yours or if what I've heard is accurate.

 

I suspect that my flow control is working to some extent because I can get reliable, large file transfers at 38400 baud. Maybe it would go faster, but my Linux machine doesn't offer anything between

38400 and 115200. But the FTDI-style adapter worked fine at 115200. But perhaps that was just good luck?

I think a Z180 running at 18.432 MHz under RomWBW will keep up with 38400 baud even when there is no flow control active.  So, indeed, you may just be lucky at 38400.

It's possible, I guess, that I have a USB->RS232 adapter that doesn't do flow control very well. There's a comment from Alan in some other thread about how this might be the case. It seems that some of these adapters do hardware flow control, but they respond so slowly to CTS being asserted that they've send a load of data before they realise they have to stop. Maybe running slower relieves this latency problem somewhat?

No idea on this.

 

PS. While I was fiddling about with the connections on my MAX232s, one of them went into that weird latch-up where they get really hot. This seems to be a well-documented problem whose cause is not obvious. I would be interested to know whether anybody else has seen the same thing, and has a definitive solution.

Interesting.  I have definitely read about this, but never personally experienced it.  As you say, it is a documented issue.  I think there is an errata from Maxim that describes how to work around this, but I don't have it handy.

Thanks,

Wayne

[Alan Cox]

Does your device use RTS/CTS or expect DSR/DTR signalling. Printers in
particular sometimes seem to expect to flow control using DTR.

Alan

[Kevin Boone]

Hi Wayne

A thought occurs to me...

I appreciate that I could look this up (eventually), so don't put any effort into answering. Do you know whether there's a way in code to toggle the state of the RTS pin on the Z180's serial port artificially? Even if it breaks communication? Maybe there's a way to do this using RomWBW calls, or perhaps directly on the hardware?

If I could toggle this pin at, say, one second intervals, I could easily trace where the voltage is changing, from one end of the communications link to the other.

At present, it's really only RTS I care about (I think). In the longer term I need the RTS/CTS pair to work, but getting even one half to work would be step forward.

If the problem turns out to be in the cheap RS232-USB converter I have attached to my PC, at least I'll know it's worth shopping for a better one.

Best wishes

Kevin

[Wayne Warthen]

On Thursday, June 29, 2023 at 3:57:24 AM UTC-7 Kevin Boone wrote:

I appreciate that I could look this up (eventually), so don't put any effort into answering. Do you know whether there's a way in code to toggle the state of the RTS pin on the Z180's serial port artificially? Even if it breaks communication? Maybe there's a way to do this using RomWBW calls, or perhaps directly on the hardware?

If I could toggle this pin at, say, one second intervals, I could easily trace where the voltage is changing, from one end of the communications link to the other.

Yes, the state of RTS for ASCI 0 is managed by bit 4 of the CNTLA0 port.  That port will be at  0xC0 once RomWBW initializes the Z180.  You may have some trouble doing this because the RomWBW interrupt driven serial port will constantly be changing this bit as you send/receive characters on the primary port.

Thanks,

Wayne

[Kevin Boone]

Thanks. I have to admit, though, that it didn't work. I wrote a loop in assembly language that just sets 0xC0 to 0x10 and 0 alternately at five-second intervals. It also writes the front-panel LEDs so I can be sure the loop is actually running, because I disconnect the serial hardware completely, in an attempt to avoid anything interrupting.

But the voltage on the 'Rt' pin on the SC130 remains steadfastly 0V.

Is 0V the 'go ahead' state on these flow control pins? The Rx and Tx pins idle at 5V. Could the RTS and CTS outputs of the board be open-collector thingies that need to be pulled up?

Best wishes

Kevin

[Wayne Warthen]

On Thursday, June 29, 2023 at 12:24:30 PM UTC-7 Kevin Boone wrote:

Thanks. I have to admit, though, that it didn't work. I wrote a loop in assembly language that just sets 0xC0 to 0x10 and 0 alternately at five-second intervals. It also writes the front-panel LEDs so I can be sure the loop is actually running, because I disconnect the serial hardware completely, in an attempt to avoid anything interrupting. 

But the voltage on the 'Rt' pin on the SC130 remains steadfastly 0V.

Hmmm... I tried it and it worked for me.  In my case, I just used the RomWBW monitor.  I read the value of port 0xC0, added 0x10 to the value, then wrote that value back to port 0xC0.  My digital probe showed the Rt pin change state from low to high when I did this.  At this point I lost control of my console because my PC now thought that flow control was inhibiting any new characters.  However, it was enough of a test to prove I could toggle the Rt pin on my SC130 by manipulating bit 4 of port 0xC0.

Is 0V the 'go ahead' state on these flow control pins? The Rx and Tx pins idle at 5V. Could the RTS and CTS outputs of the board be open-collector thingies that need to be pulled up?

The TTL output of RTS from the Z180 uses high for "stop sending data".  Note that this is opposite of the RS-232 signal where a negative voltage means "stop sending data".  The MAX232 inverts the signals.  The TTL output of the Z180 is not open collector.

Thanks,

Wayne

[Kevin Boone]

Thank you for the continued help.

I didn't realize I could read port 0xC0. When I add 16 to the value, the RTS line changes state, and the change traces all the way back to my Linux machine. The statserial utility shows that the CTS line (as it is on that side of the null modem) has changed state.

And yet... flow control still doesn't work. The USB->RS232 adapter is based on a CH341 chip. I think other people have reported problems with this in Linux.

With the FTDI adapter, when I change the state of RTS the statserial utility does _not_ report that the state of CTS has changed, and yet flow control works fine.

This looks like a bug, or at least an inconsistency, in the CH341 driver. I guess I'll have to shop for a different USB->RS232 adapter. If anybody knows one that works properly with Linux, including hardware flow control, that would be helpful.

Best wishes
Kevin

[Wayne Warthen]

On Thursday, June 29, 2023 at 2:48:50 PM UTC-7 Kevin Boone wrote:

I didn't realize I could read port 0xC0. When I add 16 to the value, the RTS line changes state, and the change traces all the way back to my Linux machine. The statserial utility shows that the CTS line (as it is on that side of the null modem) has changed state.

OK, progress!

And yet... flow control still doesn't work. The USB->RS232 adapter is based on a CH341 chip. I think other people have reported problems with this in Linux.

With the FTDI adapter, when I change the state of RTS the statserial utility does _not_ report that the state of CTS has changed, and yet flow control works fine.

Very strange.  No clue what is happening here.

Thanks,

Wayne

[Kevin Boone]

Well, since I couldn't face the thought of debugging the Linux CH341 driver, I bought a different UBS->RS232 cable that uses an FTDI chip. I'm pleased to say everything works fine.

Thanks to all who responded.

Best wishes
Kevin