Hi Guys

Running Fedora FC14x86_64, Mobo gigabyte GA-880GM
processor AMD dual core athlon

Here's the problem,

setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3

ls -lZ /dev/ttyS*
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/ttyS0
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/ttyS1
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/ttyS2
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/ttyS3

in /etc/udev/rules.d I've added 50-serial containing:-
KERNEL=="ttyS0", GROUP="uucp", MODE="0666"
KERNEL=="ttyS[1-9]", GROUP="uucp", MODE="0660"
KERNEL=="ttyS[1-3][0-9]", GROUP="uucp", MODE="0660"


I've checked the correct pins on the DB9 are going to the correct socket pins on the mobo, connected up a very verbose GPS to the port,
and absolutely nothing !!! /:(

I tried winbows XP on another partition and got nothing in a hyperterminal.

Loaded puppy on an ancient laptop ( P2), and checked with the same cables and plenty of date from the GPS.

Strangely enough running tcpdump -i /dev/ttyS0 gives this:-

[root@richard-g8jvm richard]# tcpdump -i /dev/ttyS0
tcpdump: /dev/ttyS0: No such device exists
(SIOCGIFHWADDR: No such device)
[root@richard-g8jvm richard]# ls -la /dev/ttyS0
crw-rw-rw-. 1 root dialout 4, 64 Apr 25 15:04 /dev/ttyS0

Any ideas on what I've missed to get this port up and running ?

TIA
Richard

Okay, the very first thing to try when troubleshooting a PC serial port is to jumper together pins 2 & 3 of the D-sub connector, and run a terminal emulator such as minicom or C-Kermit (or even hyperterminal in Windows). Pressing keys should result in an echo (make sure local-echo is turned OFF on the terminal emulator), irrespective of bitrate, parity, etc. Failure to get an echo in this test would indicate either faulty hardware or faulty driver or both. If you have a DVM, you should be able to measure a steady-state voltage of between -3 and -12 VDC on pin 2 or 3, with respect to chassis ground. The other pin should be near zero VDC. This test tells you that the cable has a transmitter connected to the respective pin (or not; fault).

Running tcpdump against a non-network device will tell you nothing whatsoever.

If you have a ribbon cable attached to a pin-header on the motherboard, make sure the connector is correctly oriented. Some are keyed to ensure this, others can be inserted 180 degrees off (and this is rarely harmful). Also, make sure the connector isn't off by a pin left or right of the correct connection.

--- rod.

Yes correct about tcpdump, I'd been so use to using com ports with ip addresses in the distant past, ax25, that I'd forgotten tcpdump only functions on network ports.
I have already checked the hardware, as said checking between the socket , which is polarised, on the mobo and the DB9 connector and found no problem, also hung a scope on a breakout connector.
With connecting a very verbose GPS device at 4800bd I should have seen data in a terminal, this has not been so. Even with the data rate incorrectly sent you can see in gtkterm or similar terminal garbage, but not even that.
I'm suspecting software, but what and where is getting the upper hand at the moment.

cheers
Richard

Okay, since you have a scope, hang the scope on the Tx pin, and while running a terminal emulator, press and hold the 'U' key. This is a handy key, since its ASCII value is 55h, resulting in nice alternating pattern of ones and zeros. From that, you can easily test that the data is not corrupted, and has the right bit-time, etc.

Then, do the loopback test, and look for the U's to be read back to the Rx pin.

Are you sure that there actually is a serial port on your motherboard. I have a mobo running Debian 6, and whatever kernel it is reports an 8250-style UART, but the motherboard has none. Are you sure the connector you're using corresponds to /dev/ttyS0? More than one serial port (/dev/ttyS1?).

Is there a BIOS setting required to enable the serial port?

--- rod.

Hi Rod

Using GTKterm
Pins
1 DCD H
2 RX 0
3 TX L data hi +/- 10V
4 DTR 0
5 gnd
6 DSR 0
7 RTS H
8 CTS 0
9 ? L

in loopback 3+2 linked
1 DCD L
2 RX 0
3 TX 0
4 DTR 0
5GND
6 DSR L
7 RTS 0
8 CTS H
9 ? 0

nothing shown on GTKTerm in loopback
There doesn't seem to be any change in states with flow control , none, RTC/CTS, Xon/Xoff


the port pinout in the handbook lists as
1 NDCD-
2 NSIN
3 NSOUT
4 NDTR-
5 GND
6 NDSR-
7 NRTS-
8 NCTS-
9 NRI-

No where else on any of the header pins connectors do they prefix the name with an "N", I suspect it means negated ??
As soon as you connect to RS232 controller equipment in this case an antenna rotator, the level on pin 3 changes from -12V to 0V, and no data can seen, with no load on pin 3 the quiescent state is low, ~-12V, and data can be seen full output swing to +12V. loading the Tx pin,3. by connecting it to pin2 RX, causes the same.
I'm beginning to suspect this is a raw unbuffered port, intended to be buffered, maybe through an opto isolator
HTH

Richard

I think the answer is in the last observation. Hanging a single input load on the Tx pin should not pull it to 0VDC. Since it seems to be consistent no matter where the load comes from, I'll say it is probably a fault with the driver chip. There are two industry-standard RS-232 drivers/level-converters; the xx1488 & xx1489 style parts. The 1488 part is the line driver, converting TTL logic to RS-232 line levels. I'm guessing these are probably integrated with the chip that does the UART function, so if it is faulty, you're pretty well hooped. Another possibility would be an external chip that uses capacitor charge pumps to create the +/- 12VDC from +5V, like the old MAX232 chip. If a capacitor for one of those has blown (tantalum in reverse bias?) or has gone faulty it might be replaceable. I doubt there is any optical isolation involved with an RS-232 signal.
At any rate, I think you can be sure that the problem is hardware, not software. It might be interesting to see what happens to other output pins when jumpered to an input load. If all output bits are being dragged down by a single load, then it would point to the aforementioned +/-12VDC generation, which would be common to all output lines.
--- rod.

1 members found this post helpful.

I'll see if I can find where the +/- supplies to the UART are on the mobo which is new,
As 90% of the time I use the com port to control other equipment, which is usually CMOS, I'm not too worried about the -ve level so much. It looks as well if the input is also bad.
.

It would be nice at times like this to have some software that would indicate real time the state of all the lines on that port.

Thanks Rod