Serial Port Problems

[Guest]

I am having the following problem with my serial port (COM1), and it seems to
be windows (XP Professional) related:

I think Windows is controlling the DTR (pin4) and RTS (pin7) signals from
COM1. Instead of these pins being user controlable, windows seems to be
setting and holding them both active (+6V). On normal ports both signals are
negative (-5V). I think it is a Windows (and not hardware/bios) problem
because in bios mode (i.e. before windows boots up) both these pins are -5V,
however once windows starts up it controlls these pins makinging them +6V.
Curiously, when the computer wakes up from standby/hybernation both pins go
to -5V, however as soon as anything tries to access the port, both pins
return to +6V.

Has anyone else experianced this problem?? What is controlling these pins??
Is it a resource conflict?? How do i make XP Pro leave my serial port alone
to let other software control it??
This is driving me nuts, so all help/suggestions are greatly appreciated.

Thanks in advance,
Michael

 

[GTS]

NT versions of Windows generally don't permit direct hardware access.
Access/control is management through a device driver.
For more information see http://www.beyondlogic.org/porttalk/porttalk.htm

 

[w_tom]

How to get control of DTR & RTS pins? Use an OS that is not
stable - because it permits direct access to hardware. It's
called DOS or Windows 3.1.

You quest control of DTR and RTS pins in NT/XP. You tell
Windows what you want and then Windows decides that those pins
will be so. But if you access the COM1 port using a Windows
serial port software, then Windows is told by that serial port
program to change DTR/RTS accordingly. You want more control
of those pins? Then use software that directly accesses the
IO ports. Windows changes hardware UART registers according
to assembly language OUT commands that request the change.

To better see how its done: Execute (from Command Line) the
program DEBUG. Output to port address 0x3FC changes to bits 0
and 1. For example (first is the letter O; second is a number
zero, one or two):
O 3fc 1
O 3fc 0
O 3fc 2
O 3fc 0

 

[Bob I]

Please try
command line
MODE COM1
and view output
You can set DTR and RTS to ON:OFF or HS for handshake

 

[fatman]

Check main board bio, set com1 03f8 set modem to
IRQ3,reboot...............if that doesn't work go to safe mode remove
com1&2 reboot let windows find the IRQ com 1 should be IRQ 4 com2 IRQ3
try that.

 

[cquirke (MVP Windows shell/user)]

You might try a more lateral approach to this issue.

As has been mentioned, NT isolates software from the hardware, though
perhaps not quite as absolutely as one might like. Since DirectX was
added to NT 4, driver code can play in Ring 0, and Witty demonstrated
how malware can in fact puke over raw HD from within NT (XP), NTFS
etc. notwithstanding. In Witty's case, it may have been because it
was acting within the firewall product it had burrowed into, and thus
enjoyed that app's low-level system access.

Be all that as it may, I'd be thinking along the lines of creative
cabling (assuming your serial device is external).

It's quite common to have devices that don't assert various serial
control lines properly, and/or require behavior that isn't provided by
what they are connecting to. This is over and above the "null modem"
issue, where you cross over various lines to that two "terminals"
(i.e. computers) and talk as if there were modems between them.

It's been a while, but as I recall, there are two sets of handshaking
control lines; Data Terminal Ready and Data Set Ready, and Clear To
Send and Ready To Send. The first set usually refelct powered-on
status, whereas the second reflects the more dynamic state of being
ready to handle data or not. In addition, some devices may care about
the Ring Indicator line.

So it was common practice to wire these up in various ways, to spoof
them into various states - forcing CTS/RTS to go wherever DTS/DTR
goes, or force DTS/DTR to always be On, etc. RTFM so you don't fry
something - serial ports are about the only thing in the PC that still
uses -12V, and that's an unwelcome voltage in most places.

The other approach is to talk to the modem (if that's what it is) via
the AT command set, so you can tell it how to behave. Once again,
it's RTFM time; most Rockwell (Conexiant) chipsets use the same AT
extended command set, but with other modem chipsets (especially
USR/Texas Instruments) YMMV.

You can write your own "modem" .INF file to pass along the vocabulary
you'd like your modem (or "modem") to use, or better yet, do a Save As
of one of the existing modem .INF and hack that to taste.

Less extreme, and sometimes enough, is to add extra AT commands via
the modem's "Extra settings". There's an implicit AT, and if you want
to nuke the modem back to factory defaults before laying down the law
afresh, start with &F (or Z if you have saved settings you'd rather
fall back to instead). These reset commands tend to blow everything
away, so you can often put "spare" settings behind the Z or &F as a
way of "commenting them out", e.g. &C1&F will blow away &C1, whereas
&F&C1 will assert &C1 after blowing everything else away.

HTH

------------------------ ---- --- -- - - - -

Forget http://cquirke.blogspot.com and check out a
better one at http://topicdrift.blogspot.com instead!