Serial Port Problem

QNX Newsgroups (Archives) qnx.qnx4
1

I have a Diamond Systems Athena CPU running a control application that uses
one of the on port serial ports. This serial port (16550) is configured for
raw mode and no hardware or software handshaking, 9600 baud, FIFOs not
enabled.

Ocassionally we have a situation where a write to the serial port will block
forever. We added an alarm() function to pull us out of the write after 1
sec. We have determined that once we have time out (and reset the alarm(0))
we can never talk to the port again. The only solution is to slay Dev.ser
for that port. Once we do this we continue to run for some random period of
time (8 -10 hours) and then we will have another lockup.

Has anyone seen this type of behaviour before? The next time I experience
the lockup I was going to read some of the UART registers to see if I could
see something amiss. Is there any reason that the serial driver would stop
accepting/transmitting characters?

Thanks for your help.

Larry

2

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs ?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments (some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the driver
in (e.g. REPLY blocked ?).

The next time I experience
the lockup I was going to read some of the UART registers to see if I could
see something amiss. Is there any reason that the serial driver would stop
accepting/transmitting characters?

I suppose there are quite a few reasons this could happen. The most obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

3

I have seen it also. A couple of years ago. It turned out to be the UART
chipsets on the motherboards of this particular brand of computer that
after a while, and at random, would cease issuing interrupts. This
problem caused us a lot of pain - some of it still lingers…

The solution was to disable the on-bord UART’s and utilise an external
(ISA in this case) serial port instead.

Geoff Roberts.



Rennie Allen wrote:

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs ?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments (some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the driver
in (e.g. REPLY blocked ?).

The next time I experience
the lockup I was going to read some of the UART registers to see if I could
see something amiss. Is there any reason that the serial driver would stop
accepting/transmitting characters?

I suppose there are quite a few reasons this could happen. The most obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

4

Geoff Roberts wrote:

I have seen it also. A couple of years ago. It turned out to be the UART
chipsets on the motherboards of this particular brand of computer that
after a while, and at random, would cease issuing interrupts. This
problem caused us a lot of pain - some of it still lingers…

Sounds so much like stupid power-save “features”.


Evan

5

The write call sends a message to the serial port driver.
The driver receives this message and writes the first character to the UART.
After sending that chracter the UART activates an interrupt.
This interrup is the signal to the driver to send next character.
This process repeats until no more characters are available to write to the UART.

At this point the driver reply the message and the initial write call returns.

Note that if one interrupt is lost the process is blocked and the write call
never returns (it remains reply blocked).
The alarm unblocks your process, but the driver continues “waiting” for the
interrupt indicating UART is free to receive next character. This explain that
the Alarm call unblocks your process, but you can’t write again until serial
driver is restarted.

The problem is that sometimes one single interrup is lost.
The origin may be hardware, or an interrupt conflict with other devices. This may
be difficult to find.


Rennie Allen wrote:

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs ?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments (some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the driver
in (e.g. REPLY blocked ?).

The next time I experience
the lockup I was going to read some of the UART registers to see if I could
see something amiss. Is there any reason that the serial driver would stop
accepting/transmitting characters?

I suppose there are quite a few reasons this could happen. The most obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

6

“Rennie Allen” <rallen@csical.com> wrote in message
news:42D430A1.403@csical.com…

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs ?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments (some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the
driver
in (e.g. REPLY blocked ?).

This appears to be happening on our Athena CPU but not the Prometheus. We
are using the standard
0x3f8 IRQ 4 configuration. I know that our application is reply blocked on
Dev I don’t the state of Dev.ser.

We have checked in the BIOS and verified that we have Power Save Mode
disabled and that we don’t have any interrupt conflicts.

The next time I experience the lockup I was going to read some of the
UART registers to see if I could see something amiss. Is there any
reason that the serial driver would stop accepting/transmitting
characters?

I suppose there are quite a few reasons this could happen. The most
obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

7

“Geoff Roberts” <ger_two@rttsdotcom.au> wrote in message
news:42D46889.85712498@rttsdotcom.au…

I have seen it also. A couple of years ago. It turned out to be the UART
chipsets on the motherboards of this particular brand of computer that
after a while, and at random, would cease issuing interrupts. This
problem caused us a lot of pain - some of it still lingers…

The solution was to disable the on-bord UART’s and utilise an external
(ISA in this case) serial port instead.

Geoff Roberts.

The Athena has 4 serial ports. Com1,2 are 16550 and on chip. Com3,4 are
16850 with 128 byte FIFOs and are shown as external.

For testing we have the option of using one of the high speed UARTs to see
if it has the same problem. However, for production we
will need to get COM 1 working.


Rennie Allen wrote:

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs
?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments
(some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the
driver
in (e.g. REPLY blocked ?).

The next time I experience
the lockup I was going to read some of the UART registers to see if I
could
see something amiss. Is there any reason that the serial driver would
stop
accepting/transmitting characters?

I suppose there are quite a few reasons this could happen. The most
obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

8

Unfortunately we’ve already checked the BIOS …

“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:db29pu$ash$1@inn.qnx.com…

Geoff Roberts wrote:
I have seen it also. A couple of years ago. It turned out to be the UART
chipsets on the motherboards of this particular brand of computer that
after a while, and at random, would cease issuing interrupts. This
problem caused us a lot of pain - some of it still lingers…


Sounds so much like stupid power-save “features”.


Evan

9

“Joan Baucells” <“Joan Baucells”@NoSpam.es> wrote in message
news:42D4B6DE.A137134E@NoSpam.es…

The write call sends a message to the serial port driver.
The driver receives this message and writes the first character to the
UART.
After sending that chracter the UART activates an interrupt.
This interrup is the signal to the driver to send next character.
This process repeats until no more characters are available to write to
the UART.

At this point the driver reply the message and the initial write call
returns.

Note that if one interrupt is lost the process is blocked and the write
call
never returns (it remains reply blocked).
The alarm unblocks your process, but the driver continues “waiting” for
the
interrupt indicating UART is free to receive next character. This explain
that
the Alarm call unblocks your process, but you can’t write again until
serial
driver is restarted.

The problem is that sometimes one single interrup is lost.
The origin may be hardware, or an interrupt conflict with other devices.
This may
be difficult to find.

I was wondering what effect it would have to enable the FIFO? I guess it
would just reduce the chance of this happening because we are decreasing the
number of transmit interrupts generated.

What is it that Dev.ser does during initialization of the UART that resets
the chip so that it works again? Perhaps I could do the same thing in my
application in the case where alarm(1) pulls me out of the write?

This would be preferable to having to slay and restart the driver.

Is the source code for the latest Dev.ser available in usr/free?

Rennie Allen wrote:

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs
?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments
(some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the
driver
in (e.g. REPLY blocked ?).

The next time I experience
the lockup I was going to read some of the UART registers to see if I
could
see something amiss. Is there any reason that the serial driver would
stop
accepting/transmitting characters?

I suppose there are quite a few reasons this could happen. The most
obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

10

Lawrence R. Sweet wrote:

I was wondering what effect it would have to enable the FIFO? I guess it
would just reduce the chance of this happening because we are decreasing the
number of transmit interrupts generated.

The FIFOs should be enabled if they exist (IIRC).

What is it that Dev.ser does during initialization of the UART that resets
the chip so that it works again? Perhaps I could do the same thing in my
application in the case where alarm(1) pulls me out of the write?

This would be preferable to having to slay and restart the driver.

The init code in the serial driver basically does:

-baud rate and data bit, parity etc setup (eg 9600,8,n,1)
-drains any incoming/outgoing characters and the FIFOs if they exist
-and then clears the line status interrupt, the RX interrupt, the TX
interrupt and then the modem interrupt.
-enables the FIFOs (again if they exist)
-DTR/RTS is enabled (if applicable)
-enables interrupts/attaches handlers

In terms of debugging, it would be worth while to dump the UART to see
if there is a pending interrupt for TX or not (or other clues based on
what state the UART is in). I seem to recall there was supposed to be
gear in the serial driver already for buggy fifos where after a certain
timeout the driver would kick the UART to get it moving again


Is the source code for the latest Dev.ser available in usr/free?

Your sales rep can help you in this regard.

–
Cheers,
Adam

QNX Software Systems
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

11

Lawrence R. Sweet wrote:

This appears to be happening on our Athena CPU but not the Prometheus. We
are using the standard
0x3f8 IRQ 4 configuration.

Is there any difference in the BIOS between the Athena and the Prometheus ?
(I think it is reasonable to assume that a 16550 is a 16550 is a 16550).

I know that our application is reply blocked on
Dev I don’t the state of Dev.ser.

If it is running READY or something else unexpected, then it would be a
contra-indication of missing interrupt.

We have checked in the BIOS and verified that we have Power Save Mode
disabled and that we don’t have any interrupt conflicts.

Might just be a bad MB chipset or BIOS design.

Rennie

12

According to the documentation on Dev.ser, it is the -t option that sets the
threshold for the FIFO. Its default (according to the docs) is zero which I
assume means disable the FIFO. i.e. interrupt the CPU after each byte
received or transmitted?

“Adam Mallory” <amallory@qnx.com> wrote in message
news:db3e3d$7qo$1@inn.qnx.com…

Lawrence R. Sweet wrote:

I was wondering what effect it would have to enable the FIFO? I guess it
would just reduce the chance of this happening because we are decreasing
the number of transmit interrupts generated.

The FIFOs should be enabled if they exist (IIRC).

What is it that Dev.ser does during initialization of the UART that
resets the chip so that it works again? Perhaps I could do the same
thing in my application in the case where alarm(1) pulls me out of the
write?

This would be preferable to having to slay and restart the driver.

The init code in the serial driver basically does:

-baud rate and data bit, parity etc setup (eg 9600,8,n,1)
-drains any incoming/outgoing characters and the FIFOs if they exist
-and then clears the line status interrupt, the RX interrupt, the TX
interrupt and then the modem interrupt.
-enables the FIFOs (again if they exist)
-DTR/RTS is enabled (if applicable)
-enables interrupts/attaches handlers

In terms of debugging, it would be worth while to dump the UART to see if
there is a pending interrupt for TX or not (or other clues based on what
state the UART is in). I seem to recall there was supposed to be gear in
the serial driver already for buggy fifos where after a certain timeout
the driver would kick the UART to get it moving again


Is the source code for the latest Dev.ser available in usr/free?

Your sales rep can help you in this regard.

–
Cheers,
Adam

QNX Software Systems
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

13

Lawrence R. Sweet wrote:

According to the documentation on Dev.ser, it is the -t option that sets the
threshold for the FIFO. Its default (according to the docs) is zero which I
assume means disable the FIFO. i.e. interrupt the CPU after each byte
received or transmitted?

After checking the source, yes, you’re correct the default a FIFO
threshold of zero.

There is a high level timer which will kick the UART if TX is stalled.
The kick condition is if there is a TX pending, and the transmitter
buffer isn’t empty (TBE bit in the LSR). The kick is to bang the IER
with 0x0f, which causes the UART to reassert the TX.

So if you’re missing tx interrupts, the driver should already be kicking
the UART. You could also kick it yourself to see if that ‘fixes’ things
as well. If it does, I think a closer look at the driver into why the
kick didn’t work is required.

\

Cheers,
Adam

QNX Software Systems
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

14

Adam Mallory wrote:

After checking the source, yes, you’re correct the default a FIFO
threshold of zero.

There is a high level timer which will kick the UART if TX is stalled.
The kick condition is if there is a TX pending, and the transmitter
buffer isn’t empty (TBE bit in the LSR). The kick is to bang the IER
with 0x0f, which causes the UART to reassert the TX.

So if you’re missing tx interrupts, the driver should already be kicking
the UART. You could also kick it yourself to see if that ‘fixes’ things
as well. If it does, I think a closer look at the driver into why the
kick didn’t work is required.

Depending on the value of that timer, and the size of the buffer in the
driver (I think it defaults to 2048 bytes), if the uart stops generating
tx irqs altogether, tx can certainly appear to have stopped (even if it
is kicking the uart every XX ms). Certainly it can take long enough to
empty a reasonable sized write() that an alarm(1) can fire.

Rennie

15

Rennie Allen wrote:

Adam Mallory wrote:

After checking the source, yes, you’re correct the default a FIFO
threshold of zero.

There is a high level timer which will kick the UART if TX is stalled.
The kick condition is if there is a TX pending, and the transmitter
buffer isn’t empty (TBE bit in the LSR). The kick is to bang the IER
with 0x0f, which causes the UART to reassert the TX.

So if you’re missing tx interrupts, the driver should already be
kicking the UART. You could also kick it yourself to see if that
‘fixes’ things as well. If it does, I think a closer look at the
driver into why the kick didn’t work is required.


Depending on the value of that timer, and the size of the buffer in the
driver (I think it defaults to 2048 bytes), if the uart stops generating
tx irqs altogether, tx can certainly appear to have stopped (even if it
is kicking the uart every XX ms). Certainly it can take long enough to
empty a reasonable sized write() that an alarm(1) can fire.

All the more reason to look at the state of the UART when the condition
occurs. It should be very apparent that the UART has stopped generating
TX interrupts when doing so.

–
Cheers,
Adam

QNX Software Systems
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

16

This is 485 and most of my command messages are 8 bytes.

“Rennie Allen” <rallen@csical.com> wrote in message
news:42D55CFF.8090704@csical.com…

Adam Mallory wrote:

After checking the source, yes, you’re correct the default a FIFO
threshold of zero.

There is a high level timer which will kick the UART if TX is stalled.
The kick condition is if there is a TX pending, and the transmitter
buffer isn’t empty (TBE bit in the LSR). The kick is to bang the IER
with 0x0f, which causes the UART to reassert the TX.

So if you’re missing tx interrupts, the driver should already be kicking
the UART. You could also kick it yourself to see if that ‘fixes’ things
as well. If it does, I think a closer look at the driver into why the
kick didn’t work is required.


Depending on the value of that timer, and the size of the buffer in the
driver (I think it defaults to 2048 bytes), if the uart stops generating
tx irqs altogether, tx can certainly appear to have stopped (even if it
is kicking the uart every XX ms). Certainly it can take long enough to
empty a reasonable sized write() that an alarm(1) can fire.

Rennie

17

We just caught the lockup. i.e alarm(1) triggered when trying to send an 8
byte message. Looking at the Line Status Register shows 0x63.

This would indicate that the transmitter empty (TEMT) bit is high indicating
that the Transmitter Holding register (THR) and the Transmitter Shift
Register (TSR) are both empty.

I guess this shows that an interrupt was indeed missed correct?

Even though we are not using any HW/SW flow control and we only have 3 wires
for our RS485 connection. Is it possible that noise is being picked up on
one of the other modem control lines(pins) and the Driver is flow
controlling by mistake?

I’ll take a look at the modem status register while I’m still trapped in the
debugger.

Larry

“Adam Mallory” <amallory@qnx.com> wrote in message
news:db3nje$esp$1@inn.qnx.com…

Rennie Allen wrote:
Adam Mallory wrote:

After checking the source, yes, you’re correct the default a FIFO
threshold of zero.

There is a high level timer which will kick the UART if TX is stalled.
The kick condition is if there is a TX pending, and the transmitter
buffer isn’t empty (TBE bit in the LSR). The kick is to bang the IER
with 0x0f, which causes the UART to reassert the TX.

So if you’re missing tx interrupts, the driver should already be kicking
the UART. You could also kick it yourself to see if that ‘fixes’ things
as well. If it does, I think a closer look at the driver into why the
kick didn’t work is required.


Depending on the value of that timer, and the size of the buffer in the
driver (I think it defaults to 2048 bytes), if the uart stops generating
tx irqs altogether, tx can certainly appear to have stopped (even if it
is kicking the uart every XX ms). Certainly it can take long enough to
empty a reasonable sized write() that an alarm(1) can fire.

All the more reason to look at the state of the UART when the condition
occurs. It should be very apparent that the UART has stopped generating
TX interrupts when doing so.

–
Cheers,
Adam

QNX Software Systems
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

18

I don’t know the driver details.

Try to write a character directly to the UART using the hardware level function
outp when your write is unlocked by the alarm call.
If only one interrupt was lost, but UART is OK and can continue sending
interrupts after each character is transmitted to the serial port, after
transmitting this character the UART will produce a new interrupt that will
“unblock” the driver (I hope).
If UART has stopped sending interrupts the driver will remain “blocked”.

With this test you can have an idea if the origin of the problem is related to
the UART itself or if it’s related to the interrupt managing system.

Note that the extra character sent to the UART will interfere with your serial
message. This is oly a test, and even in the case this unblocks the driver this
is not a valid solution to be used in the working environment.

“Lawrence R. Sweet” wrote:

“Joan Baucells” <“Joan Baucells”@NoSpam.es> wrote in message
news:> 42D4B6DE.A137134E@NoSpam.es> …
The write call sends a message to the serial port driver.
The driver receives this message and writes the first character to the
UART.
After sending that chracter the UART activates an interrupt.
This interrup is the signal to the driver to send next character.
This process repeats until no more characters are available to write to
the UART.

At this point the driver reply the message and the initial write call
returns.

Note that if one interrupt is lost the process is blocked and the write
call
never returns (it remains reply blocked).
The alarm unblocks your process, but the driver continues “waiting” for
the
interrupt indicating UART is free to receive next character. This explain
that
the Alarm call unblocks your process, but you can’t write again until
serial
driver is restarted.

The problem is that sometimes one single interrup is lost.
The origin may be hardware, or an interrupt conflict with other devices.
This may
be difficult to find.


I was wondering what effect it would have to enable the FIFO? I guess it
would just reduce the chance of this happening because we are decreasing the
number of transmit interrupts generated.

What is it that Dev.ser does during initialization of the UART that resets
the chip so that it works again? Perhaps I could do the same thing in my
application in the case where alarm(1) pulls me out of the write?

This would be preferable to having to slay and restart the driver.

Is the source code for the latest Dev.ser available in usr/free?


Rennie Allen wrote:

Lawrence R. Sweet wrote:

Has anyone seen this type of behaviour before?

I have; with incorrectly configured and/or malfunctioning hardware.

Could you provide more details ? Have you tried this with different MBs
?
What IRQ ? How does the MB handle the on-board UARTs IRQ assigments
(some
MBs require that the IRQ for the UART be designated as legacy, and some
automatically handle this when the UART is enabled) ? Is the UART at one
of the conventional (i.e. 0x3f8,0x2f8) addresses ? What state is the
driver
in (e.g. REPLY blocked ?).

The next time I experience
the lockup I was going to read some of the UART registers to see if I
could
see something amiss. Is there any reason that the serial driver would
stop
accepting/transmitting characters?

I suppose there are quite a few reasons this could happen. The most
obvious
(given that h/w flow control is disabled) being that the UART stopped
generating interrupts for some reason.

19

Try this short program (I call it wakeup_serial):


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <conio.h>

int main(int argc, char *argv[])
{
int i, go = 1, base;

if(argc < 2){
printf(“Nezadany ziadny argument\n”);
return(-1);
}

while(go){

for( i = 1; i < argc; i++){
base = strtol(argv_, NULL, 0);
if(base && errno != EOK){
outp(base + 1, 0x00);
outp(base + 1, 0x0f);
}
}

sleep (1);
}

return(0);
}





“Lawrence R. Sweet” <lsweet@fct.ca> wrote in message
news:db1530$g3e$1@inn.qnx.com…_

I have a Diamond Systems Athena CPU running a control application that
uses
one of the on port serial ports. This serial port (16550) is configured
for
raw mode and no hardware or software handshaking, 9600 baud, FIFOs not
enabled.

Ocassionally we have a situation where a write to the serial port will
block
forever. We added an alarm() function to pull us out of the write after 1
sec. We have determined that once we have time out (and reset the
alarm(0))
we can never talk to the port again. The only solution is to slay Dev.ser
for that port. Once we do this we continue to run for some random period
of
time (8 -10 hours) and then we will have another lockup.

Has anyone seen this type of behaviour before? The next time I experience
the lockup I was going to read some of the UART registers to see if I
could
see something amiss. Is there any reason that the serial driver would
stop
accepting/transmitting characters?

Thanks for your help.

Larry

begin 666 wakeup_serial.c
M(VEN8VQU9&4@/’-T9&EO+F@^“B-I;F-L=61E(#QS=&1L:6(N:#X*(VEN8VQU
M9&4@/'5N:7-T9"YH/@HC:6YC;'5D92 \97)R;F\N:#X*(VEN8VQU9&4@/&-O
M;FEO+F@^”@HO+R!T96YT;R!P<F]G<F%M(&)Y(&UA;"!V961I970@<F]Z8VAO
M9&ET(’-E<FEO=F4@<&]R=‘D@;F$@4#0@9&]S:V%C:" +R@;V0@061V86YT
M96-H=2 H:W1O<F4@<F%D:2!Z86UR>FYU0H*:6YT(&UA:6XH:6YT(&%R9V,L
M(&-H87(@F%R9W9;72D>PH):6YT(&DL(&=O(#T@,2P@8F%S93L*"@EI9BAA
M<F=C(#P@,BE["@D)<’)I;G1F*").97IA9&%N>2!Z:6%D;GD@87)G=6UE;G1<
M;B(I.PH)“7)E='5R;B@M,2D[”@E]"@H)=VAI;&4H9V\I>PH*“0EF;W(H(&D@
M/2 Q.R!I(#P@87)G8SL@:2LK7L"0D)8F%S92 ](’-T<G1O;“AA<F=V6VE=
M+”!.54Q,+” P3L"0D):68H8F%S92 F)B!E<G)N;R A/2!%3TLI>PH)"0D)
M;W5T<"AB87-E("L@,2P@,’@P,“D[”@D)“0EO=71P*&)A<V4@R Q+" P>#!F
M3L)”@D)“7T*“0E]”@H)“7-L965P(”@Q3L"7T*”@ER971U<FXH,"D["GT*
`
end

20

Lawrence R. Sweet wrote:

We just caught the lockup. i.e alarm(1) triggered when trying to send an 8
byte message. Looking at the Line Status Register shows 0x63.

Bit 0 - Data Ready
Bit 1 - Overrun Error
Bit 2 - Parity Error
Bit 3 - Framing Error
Bit 4 - Break Interrupt
Bit 5 - Tx Holding Register
Bit 6 - Tx Empty
Bit 7 - Rx FIFO Error

Umm, Data Ready is set, why is the receive buffer not empty? I presume you didn’t have data coming in when you probed the LSR. And the Overrun Error shouldn’t have occurred either, this indicates the driver is not gathering the incoming data.

Your driver looks very confused. It doesn’t appear to be talking to the comport at all.

Even though we are not using any HW/SW flow control and we only have 3 wires
for our RS485 connection. Is it possible that noise is being picked up on
one of the other modem control lines(pins) and the Driver is flow
controlling by mistake?

Nope. 232 line receivers are quite hardy and true 485 doesn’t have any external handshake.

And even if it did manage to pickup a spike it would be too short for the driver to see. The only chance of such an event having any effect at all is if the UART generates an interrupt on the MSR and, even though the delta bit is set, the driver would see the line state as a go so should continue transferring.



Evan