Serial Port Problem

QNX Newsgroups (Archives) qnx.qnx4
41

I would like to take this opportunity to thank all those people who
responded to my initial queries and provided valuable insight to aid in the
troubleshooting of this problem. Unfortunately I have to move on to other
issues and let this one be, at least for now.

So here is a summary of how it is left:

  1. My code was blocking on a write call forever.
  2. I added code to pull myself out of the write and reset the interrupt
    enable register ( 0x00, then 0x0f ).
  3. The kick code in Dev.ser every 10 * 50 msec seemed not to be happening as
    my code would block indefinitely.
  4. There was some discussion that perhaps the driver was flow controlling my
    application even though there was no HW/SW flow control configured. Not sure
    why the driver would do this but the emvironment is electrically noisy and
    perhaps noise was being injected on the unconnected pins?
  5. One of our trace logs showed:
    Jul 15 10:48:53 2 00002003 Serial port 03F8, Overrun error.
    Not sure what this means but I wonder if it might be related to the kick
    code not happening.
  6. We have temporarily moved to use serial port 3 on the Athena. Com1/2 are
    considered onboard and Com3/4 are considered external. Com3/4 are also high
    speed UARTs 16850? with 128 byte FIFOs. Since moving to Com3 we have not
    had a re-occurance of the lockup. i.e. my alarm code/debug statement has
    never tripped. Note: we still have no flow control, FIFOs are disabled and
    we are communicating at 9600 baud in an RS485 master slave configuration
    where it is always my application that initiates a transaction.

Again thanks for your help.

Larry


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

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

42

Lawrence R. Sweet wrote:

  1. We have temporarily moved to use serial port 3 on the Athena. Com1/2 are
    considered onboard and Com3/4 are considered external. Com3/4 are also high
    speed UARTs 16850? with 128 byte FIFOs. Since moving to Com3 we have not
    had a re-occurance of the lockup. i.e. my alarm code/debug statement has
    never tripped. Note: we still have no flow control, FIFOs are disabled and

More likely to be permanent unless you are planning to replace the processor card altogether. You’ve found what appears to be a hardware bug in Athena’s comports. Looking it up, I note the board uses a VIA Eden CPU, VIA Savage4 northbridge and VIA 686B southbridge.

I guess that’s a warning to anyone using a comport on a VIA 686B southbridge for long hours.


Evan