problem with devc-ser8250

Hi everybody!

I have done an application that it uses 4 serial ports. The application consists in an endless loop. In each loop I read data from 2 sensors by serial ports, send other data by other serial port, and finally I use the last serial port to establish communication with other micro. As you see, 3 of the 4 serial ports are reading or writing constantly, but one of them are reading and writing. 

The application usually works fine, but
the last serial port does not send data sometime (randomly, I think), but this serial port reads data. For various seconds the application works ok except by this problem. After these seconds the application sends all the data before and it works fine again.

Firstly, I had the size of the interrupt output buffer by default (2 kb), and the behaviour of the application was different. After some seconds the application stopped completely for about one second. Next, the application runs again in a correct way.
 
I launched the driver in this way:
   
    devc-ser8250 -T14 -t8 -b38400 3f8,4 -T14 -t8 -b38400 2f8,3 -b57600 3e8,9 -b115200 2e8,15

After that,
I increased the size of the output buffer from 2 kb to 8 kb, and the application runs as I explain before. That is, it does not stop but the serial port gives to send data.

Nowadays, I launched the driver in this other way:

    devc-ser8250 -T14 -t8 -O8192 -b38400 3f8,4 -T14 -t8 -b38400 2f8,3 -b57600 3e8,9 -b115200 2e8,15


I understand that the serial driver gives up to send data for various seconds and then, these data are stored in the outbut buffer of the serial driver. Next, the driver begins (when it can) to send the data of the output buffer.

I think the problem comes from the driver, but I am not sure. Could someone help me? Did you have a similar problem?



Thanks in advance, and Merry Christmas.

Jorge

Make sure that you are using QNX 6.3.0 or later. There was an issue in
versions 6.2.1 and earlier where transmit could stop for ~13 seconds.
This was due to hardware failure (16c550 compatible UARTs sometimes fail
to generate TX interrupt when FIFO goes empty) and the way we worked
around it.

Regards,

Joe

Jorge wrote:

Hi everybody!

I have done an application that it uses 4 serial ports. The application
consists in an endless loop. In each loop I read data from 2 sensors by
serial ports, send other data by other serial port, and finally I use
the last serial port to establish communication with other micro. As you
see, 3 of the 4 serial ports are reading or writing constantly, but one
of them are reading and writing.

The application usually works fine, but the last serial port does not
send data sometime (randomly, I think), but this serial port reads data.
For various seconds the application works ok except by this problem.
After these seconds the application sends all the data before and it
works fine again.

Firstly, I had the size of the interrupt output buffer by default (2
kb), and the behaviour of the application was different. After some
seconds the application stopped completely for about one second. Next,
the application runs again in a correct way.

I launched the driver in this way:

devc-ser8250 -T14 -t8 -b38400 3f8,4 -T14 -t8 -b38400 2f8,3 -b57600
3e8,9 -b115200 2e8,15

After that, I increased the size of the output buffer from 2 kb to 8 kb,
and the application runs as I explain before. That is, it does not stop
but the serial port gives to send data.

Nowadays, I launched the driver in this other way:

devc-ser8250 -T14 -t8 -O8192 -b38400 3f8,4 -T14 -t8 -b38400 2f8,3
-b57600 3e8,9 -b115200 2e8,15


I understand that the serial driver gives up to send data for various
seconds and then, these data are stored in the outbut buffer of the
serial driver. Next, the driver begins (when it can) to send the data of
the output buffer.

I think the problem comes from the driver, but I am not sure. Could
someone help me? Did you have a similar problem?



Thanks in advance, and Merry Christmas.

Jorge

Hello!

I am sure it is my problem.

I understand there is a problem in all 16C550 compatible UARTs because
of devc-ser8250 driver, isn´t it? Then, Do you know if this hardware
failure (16c550 UARTs) is produced in other UARTs? like 16c554, Exar
16C2850… because I suppose these UARTs are compatible with 16c550, but
I am not sure. The help of the driver only talks about 8250s, 14450s or
16550s UARTs.
I talk of that because I could use a serial port with one of these UARTs
instead of a serial port with 16C550 UART.

Anyway, if my problem is produced in others UARTs too, then, according
to your opinion, the only way to solve my problem is updating my
operating system (from QNX 6.2.1A to QNX 6.3)??? And, Could I use
serial driver of QNX 6.3 in QNX 6.2.1A? I know my last question is a
nonsense, but before updating, I would want to make sure there is no
other possibility.

Thank you very much, Joe.

Greetings,

Jorge.

Hi Jorge,

I am not sure how wide spreed this fault is withing this family of
UARTs. If upgrading to 6.3.0 is not an option for you, then you could
also contact your QNX sales rep to look into getting a back port of the
fix from the 6.3.0 source base to 6.2.1.

Regards,

Joe

Jorge wrote:

Hello!

I am sure it is my problem.

I understand there is a problem in all 16C550 compatible UARTs because
of devc-ser8250 driver, isn´t it? Then, Do you know if this hardware
failure (16c550 UARTs) is produced in other UARTs? like 16c554, Exar
16C2850… because I suppose these UARTs are compatible with 16c550, but
I am not sure. The help of the driver only talks about 8250s, 14450s or
16550s UARTs.
I talk of that because I could use a serial port with one of these UARTs
instead of a serial port with 16C550 UART.

Anyway, if my problem is produced in others UARTs too, then, according
to your opinion, the only way to solve my problem is updating my
operating system (from QNX 6.2.1A to QNX 6.3)??? And, Could I use
serial driver of QNX 6.3 in QNX 6.2.1A? I know my last question is a
nonsense, but before updating, I would want to make sure there is no
other possibility.

Thank you very much, Joe.

Greetings,

Jorge.

Thank you, Joe.

I think we will upgrade to fix the problem. It will be the perfect
excuse for upgrading, :wink: .

Happy New Year!, for everybody