• Please review our updated Terms and Rules here

RS-232 External Loopback Test for TxD/RxD

T

the3dfxdude

Experienced Member
Joined
Jan 11, 2019
Messages
258
Location
US
Hi,

I am testing a QuadRam card with a 8250 UART serial port that I previously could not use due to no data being exchanged in programs. The loopback testing information and program used is thanks to modem7 in a recent posting:

Having this port working is nice so I do not have to swap cards to have a working serial port in my 5150 when the quadram card should do. The internal loopback tests all pass.

For the external loopback tests, the TxD/RxD test fails, but all other pins pass. Tracing the pin 2/3 on the port, I found line driver XR1488N and line receiver XR1489AN which are the level converters here for RS232, which I suppose are compatible with MC1488 and MC1489A.

I remembered probing pin 2 in the past not seeing anything come across on a scope, I decided today to try the external loopback test program and my scope on a working card. In that test, I see that for the working card, that the output from pin 2 drives a low voltage level (In this case, a low voltage means a negative voltage level, not zero. I didn't check the exact level.), and high voltage level pulses when the test sends data. It is otherwise low when idle. So I checked the bad port one more time, now knowing how it should look during the test. When testing the quadram card, the TxD pin appears to be driving the output always at a high level, never switching. This means the driver is stuck outputting high, and a bad driver. Is this a good enough conclusion?

In this loopback test, I appear to have a bad 1488 driver. This current situation does not appear to tell me if the 1489A chip is ok for the RxD pin. I do remember when using the port previously, that I was able to see some data going in one direction, but that was with a crudely written program where I was trying to identify the culprit.

I will be ordering some chips to solve this eventually since I don't have these laying around. Hopefully I do not also need to buy the receiver chip. Do you have any experiences to share on which of these chips go bad usually?
 
Before assuming the transmitter buffer is faulty, check the input to the buffer to see if there is observable transmit data there. If not, it is unlikely that it is the buffer that is faulty.

Dave
 
Right. I'll be checking that to be sure. It will be a few days before I respond if the UART is outputting the data.
 
This is what I've determined today. I looked more at the WD8250-PL.

1. After switching the computer on pin 2 of the db25 is low, and loading the SERTEST.EXE program, pin 2 switches high before any test in the menu is executed. Is this 8250 initializing and activating its own output drivers?
2. The levels seen on other outputs from the 1488 is between -10 V and +10V, and they toggle during the loopback test.
3. On pin 11 of the 8250 (sout), the output is high before starting the external loopback test in the menu and drops once momentarily during the test. The inverted signal is not seen on the output of the 1488 between +/-10V, and it always +10V.
4. The levels on pin 11 of the 8250 are between 0V and 3.99V. Hmm. It's at 3.97V on the input to the 1488. Vcc on the 8250 is 5V.

The 8250 is not reaching high enough voltage for TTL on pin 11? That seems odd. The other outputs must be fine.
 
1488/1489 getting toasted by ESD was one of the more common serial port failures on the PC. I've killed a couple myself on cold, dry days. That's where I'd start.

Interestingly, products using the TI line driver/receiver combo (e.g. 75150 and 75154) seemed to be less prone to ESD damage.
 
the3dfxdude said:
This is what I've determined today. I looked more at the WD8250-PL.
1. After switching the computer on pin 2 of the db25 is low, and loading the SERTEST.EXE program, pin 2 switches high before any test in the menu is executed. Is this 8250 initializing and activating its own output drivers?
Click to expand...
Looking at the source code for SERTEST.EXE, when SERTEST loads, all that SERTEST does is look in the BIOS Data Area for what ports were discovered by the POST, then SERTEST displays those ports on-screen.

If one then, say, chooses '[1] Run tests on COM1', then SERTEST will do two things before the Diagnostic Menu for COM1 is presented:
1. Get the UART at COM1 to disable its interrupt generation (in case on).
2. Get the UART at COM1 to disable its loopback mode (in case on).

It must be one of those steps that is resulting in the behaviour that you observe.

the3dfxdude said:
3. On pin 11 of the 8250 (sout), the output is high before starting the external loopback test in the menu and drops once momentarily during the test. The inverted signal is not seen on the output of the 1488 between +/-10V, and it always +10V.
Click to expand...
the3dfxdude said:
4. The levels on pin 11 of the 8250 are between 0V and 3.99V. Hmm. It's at 3.97V on the input to the 1488. Vcc on the 8250 is 5V.

The 8250 is not reaching high enough voltage for TTL on pin 11? That seems odd. The other outputs must be fine.
Click to expand...
Refer to [here].
3.97V falls within the voltage range for TTL HIGH.
 
Chuck(G) said:
Why not just make a loopback plug? (on a DB25 plug, jumper 2-3, 4-5 and 6-8-20). The run a comms program and see if it echoes.
Click to expand...
He's done that with the external loopback test of SERTEST.EXE (quote: "For the external loopback tests, the TxD/RxD test fails, but all other pins pass.")

( SERTEST.EXE also checks 'Ring indicator', and so its DB25 loopback connector is: 2-3 and 4-5 and 6-8-20-22 )

Everything now points to a level-converter failure.
 
Yes, I did open a comm program a long while back and could not get an echo. Modem7's test procedures helped isolate the problem further to make sure the UART chip is ok.

The TTL levels are understood. I was questioning why the XR1488 was not seeing an edge on input or still driving out a high when it was supposed to be low. It should see the TTL compatible signal as the UART seems to be ok. I guess the test procedure was testing writing a "zero" or is halting early because I saw the start signal only.

Chuck(G) said:
1488/1489 getting toasted by ESD was one of the more common serial port failures on the PC. I've killed a couple myself on cold, dry days. That's where I'd start.

Interestingly, products using the TI line driver/receiver combo (e.g. 75150 and 75154) seemed to be less prone to ESD damage.
Click to expand...

That's good to hear about TI as I found TI parts MC1488/MC1489A a couple days ago ready to order.
 
The TI parts are just licensed clones of the Motorola ones. The SN75xxx series was TI's own design with different pinout/packaging from the Moto parts.
 
So the SN75188 shares the same datasheet as MC1488 at TI. Just because it is prefixed with SN, does that really mean it is TI's own design? I can't be sure they are really any different.

There is also SN75C188 (TTL compatible) available.
 
the3dfxdude said:
So the SN75188 shares the same datasheet as MC1488 at TI. Just because it is prefixed with SN, does that really mean it is TI's own design? I can't be sure they are really any different.
Click to expand...

I would assume that if the datasheets say they're equivalent they'll work fine.

I might offer you a SN75185 for the price of shipping if your card used the single-chip combo part instead of the separate 1488/89s, I bought a cheap surplus tube of them a couple years ago and have used... six?
 
Yeah, I think they’re still used in new designs, availability shouldn’t be a problem.

Considering I also have a tube of the UARTs I bought the 75185s to go with I guess I need to just get off my butt and use them somehow.
 
So I swapped the driver for a new SN75C188. This was not enough to pass the loopback test, but the TX signal is now switching correctly. So the loopback test failed on the RX side, and would also fail on RI or DSR on the first run. After a minute, RI or DSR will start passing, but not the RX. RI and DSR is split between two receiver chips, I went for the one that handled RX and replaced that too with a new SN75C189. Now the tests all pass on the first try, without needing to replace the last receiver chip.
 
Certainly something happened. The chips are in sockets now if it ever happens again. I wanted to get it going today as I want to be able to run a serial terminal without needing another card in there.
 
Chuck(G) said:
1488/1489 getting toasted by ESD was one of the more common serial port failures on the PC. I've killed a couple myself on cold, dry days. That's where I'd start.

Interestingly, products using the TI line driver/receiver combo (e.g. 75150 and 75154) seemed to be less prone to ESD damage.
Click to expand...
So far I have had one transceiver IC failed in my SOL-20 and one in my IBM-5155. I also think it is ESD that gets them. A long RS232 cable not tied or earthed at its far end can acquire electrostatic charge like a capacitor and discharge into the IC when its is plugged. Or Hot plugging scenarios can cause it too, if the common connections if both devices are not at ground potential prior to the plugging. Some devices are not as the common is not tied to mains earth.

In the case of the failed 74154 in the 5155 I didn't have a spare IC on hand and had to order it. I needed to get it working ASAP, so I improvised a repair using part of it that was still working. When I don't have spare parts it reminds me of being "Lost in Space", so for that one I wrote up the improvised repair:

 
In this particular case, it was an 8085 system with all the exposed metal parts spot-welded to copper braid grounding. The thing survived hipot testing, but the static discharge in this case managed to disrupt things to the extent that touching the case would cause the system to reboot. Touching a connector was worse.
Management eventually came in and sprayed the carpet with anti-static stuff. I ascribe it to an HVAC system with no humidity control and polyester carpeting.
 
You must log in or register to reply here.
Back
Top