[QNX 7.0_x86_generic] Serial Port Data Receive Issue

johnbevy · October 16, 2019, 6:40am

Hi ,

Regarding Serial Port testing in QNX 7.0, we are able to send data to the receiver using the “echo” command in RS232/
RS422/RS485 modes. But when we try to receive the data in QNX using “cat”, it doesn’t receive any data.

We have followed the same procedure with same setup (boards and cables are the same) in Ubuntu OS and confirmed that its
working fine.

Please advise the procedure for testing serial port data reception in QNX.

In QNX ,

Transmitter command : “echo Hello > /dev/ser1” - Its working.

Receiver command: " cat /dev/ser1" - Not working

In Ubuntu,

Transmitter command : “echo Hello > /dev/ttyS0” - Its working.

Receiver command : " cat /dev/ttyS0" -Its working

We have created Serial port write and read application using write () and read () and observed the same behavior. We are able to send using write application. Using read , we are not able to receive. The application waits in read call for the data.

We have confirmed the serial port settings (baud rate,parity,stop bit) using stty utility. It looks weird when write is works but read doesn’t work.

FYI, both applications works in Ubuntu if i changed the serial device name (/dev/ser1 to /dev/ttyS0)

DO you have any idea for receiving data via serial port?

Tim · October 16, 2019, 7:42pm

Hi John,

You mention RS232 and RS485 modes. These are quite different (2 wire vs 4 wire).

Which mode do you need to get working and which type of serial cable do you actually have (232 or 485). If you have a 485 cable it would explain why things are only working in 1 direction.

Can you post what stty says about the serial port you are trying to use.

Tim

johnbevy · October 17, 2019, 10:25am

Hi Tim,

We have used separate cables for RS232, RS422, and RS485 modes. These cables are working fine in Ubuntu OS for serial port communication in both directions.

We want to work in all the 3 modes (RS232/RS422/RS485) in both directions. Currently, we are able to send data in all the 3 modes but not able to receive in 3 modes using cat and separate serial read application.

Please find the attached image for stty settings .

Our read application code

#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define BUFFER_SIZE 100

int main(int argc, char *argv[])
{
	int writefd,readfd;
	unsigned char recv_buf[BUFFER_SIZE];
	char *data="hai";

	size_t recv_length, send_length;

	printf("************************\n");
	printf("* Serial interface app *\n");

	printf("************************\n\n");

	memset(recv_buf, 0x00, BUFFER_SIZE);

	printf("\nSend back data to serial port: \n");
	
	// Open serial port
	readfd = open("/dev/ser1", O_RDWR);
	
	if (readfd < 0)
	{
		printf("Unable to open serial port. \n");
	
		return EXIT_FAILURE;
	}

	// Read data from serial port
	recv_length = read(readfd, recv_buf, BUFFER_SIZE);

	recv_buf[99]='\0';

	if (recv_length > 0)
		printf("\nReceived data: %s \n", recv_buf);
		
	else
	{
		printf("read from serial port FAILED ! \n");
		return EXIT_FAILURE;
	}
	
	return EXIT_SUCCESS;
}

Tim · October 17, 2019, 3:05pm

Hi John,

I’ve only got experience with 232 mode in QNX but I’ve never had any problems sending/receiving in 232 mode. That’s why I asked whether you had tried a 232 cable. I’d also suggest getting 232 mode working first since that’s the easier one to work with.

Your stty looks quite similar to mine other than some minor differences like the imaxbel and onlcr options which should not be a problem. The cat command normally works just fine to show incoming data for me when I’m testing and your sample program looks fine too.

Is there a chance the actual physical serial port on your machine is bad (or the UART on the machine isn’t an 8250)? In other words do you have another serial port on that machine to try or another machine you can install QNX7 on to test or can you swap out the harddrive/CF card containing QNX for a Linux one.

Tim

johnbevy · October 17, 2019, 3:18pm

Tim:

Hi John,

I’ve only got experience with 232 mode in QNX but I’ve never had any problems sending/receiving in 232 mode. That’s why I asked whether you had tried a 232 cable. I’d also suggest getting 232 mode working first since that’s the easier one to work with.

Your stty looks quite similar to mine other than some minor differences like the imaxbel and onlcr options which should not be a problem. The cat command normally works just fine to show incoming data for me when I’m testing and your sample program looks fine too.

Is there a chance the actual physical serial port on your machine is bad (or the UART on the machine isn’t an 8250)? In other words do you have another serial port on that machine to try or another machine you can install QNX7 on to test or can you swap out the harddrive/CF card containing QNX for a Linux one.

Tim

Hi Tim,

Thanks for your reply.

In order to confirm the hardware, we have checked the same setup (hardware/cables) with Ubuntu OS and confirmed that we are able to receive and transmit properly in all 3 modes (RS232/RS422/RS485).

I have found another guy faced the same issue. Cat also not works for them. Please refer the below link,

openqnx.com/phpbbforum/viewtopi … 10&t=12915

Apart from serial port, we have below issues

Not able to record audio using “waverec” command and using “wave” command able to play audio file.

But in 8 -bit mode, High noise is recording. - The same setup works fine in Ubuntu

Password changing - Not able to change the user account password using “passwd” utiltiy. Getting error as "Sorry authentication token busy " . In VM ware, we are able to change the password.

Does the issue related to any read file system issue?

It would be helpful if you provide ideas about audio recording and password changing and serial port data receive.

Thanks,
John

Tim · October 17, 2019, 7:12pm

Hi John,

With regards to not being able to change the password:
This sounds like your QNX filesystem is mounted as ‘read only’.

Are you able to write/delete/edit anything on your QNX filesystem?
If you are able to do so, what do the file permissions in /etc and /etc/pam.d look like
Can you post your QNX build file (the one you used to build the QNX .boot image). I just want to make sure you didn’t put the password stuff in the boot image itself (which is read only).

With regards to waverec:
I’ve never used waverec or wave so I’m probably not going to be much help here.

However, where did you get your QNX waverec binary from. Did you compile it yourself from the QNX source code (which I found by googling) or did you get the binary image from QNX.
Are you running the QNX O/S in 32 or 64 bit mode? I ask this and the prior question because maybe waverec is compiled for the wrong mode or you grabbed the 32 bit exe instead of the 64 bit exe and that is why it only partially is working (8 bit mode).

With regards to serial receiving:
I saw that other link. It’s from 2012 and from a prior version of QNX (6.X). You can try turning off the OHFLOW and IHFLOW from stty or your sample code but it seems very unlikely you have the kind of cable that would require that. All the off the shelf RS 232 cables I’ve ever used just ‘worked’.

Of course once again if you are running the wrong version of devc-ser8250 (32 bit vs 64 bit) it might be the issue. You mentioned running QNX in a VMWare image. Does your serial program/cat command work in the VMWare image (assuming the host machine has a serial port)

Tim

P.S. If you’ve started the QNX system logger (slogger or slogger2) you might use sloginfo or slog2info to check the contents of the logger. Perhaps waverec or passwd or devc-ser8250 logged something. Or you can stop and restart them with higher logging on and see if anything useful shows up.

ger · October 17, 2019, 10:05pm

Regarding the serial port receiving of character issue…

Maybe try starting up qtalk (the QNX terminal program) with a loopback plug connected to the serial port. With the terminal simply press keys and they should be turned around by the loopback plug and be received, and then displayed, on the terminal screen. You can start qtalk as follows:

qtalk -m /dev/ser1

Note that qtalk started with no arguments will default to /dev/ser1 anyway.

The use of echo and cat would not be my initial approach to resolving serial port issues.

The “mode” (RS232/422/485) has relevance only in the wiring configuration. RS232 is more commonly used and is generally the default for the native 8250 or 68x50 UART types fitted to Intel x86 systems. It is the easiest to work with but not always suitable. But for serial port problem diagnosis it is the simplest.

As has been stated before, start devc-ser8250 with a -F to disable hardware flow control. Alternatively, once the driver has been started, disable hardware flow control (stty -ihflow -ohflow < /dev/ser1). If qtalk still doesn’t show a character echo I would then suspect either a wiring issue or hardware problem. Given your wiring harness appears to work with Linux I would be starting to look at the QNX driver and serial port configuration. I am not aware of any problems with the QNX7 devc-ser8250 driver itself. It works for me!

The beauty of the loopback test is that you know that the transmit clock is the same as the receive clock. Furthermore, you know that the transmit and receive parameters (baudrate, data/start/stop bits, and parity) are identical. If that works, then the next step is to connect to a different machine. I have seen receive failures resulting from one machine being set to 1.5 stop bits and the other set to 1 or 2 stop bits. That sort of thing.

I can think of a couple of other reasons why a serial port won’t work but this is simply for starters.

I have been dealing with these sorts of things with QNX for 30+ years and been writing QNX serial port drivers (NOT devc-ser8250!) for 24 years - including one for QNX7. The QNX7 driver is basically identical to the QNX6 driver in terms of functionality. I have both 32-bit and 64-bit QNX7 boxes and devc-ser8250 and qtalk work fine with both. (Just don’t try transferring files between 32 and 64 bit systems using qcp)!

Dealing with serial ports these days can in some ways be considered to be something of a “black art”. After a while it becomes second nature…

Geoff.

johnbevy · October 18, 2019, 9:14am

Tim:

Hi John,

With regards to not being able to change the password:
This sounds like your QNX filesystem is mounted as ‘read only’.

Are you able to write/delete/edit anything on your QNX filesystem?

If you are able to do so, what do the file permissions in /etc and /etc/pam.d look like

Can you post your QNX build file (the one you used to build the QNX .boot image). I just want to make sure you didn’t put the password stuff in the boot image itself (which is read only).

With regards to waverec:
I’ve never used waverec or wave so I’m probably not going to be much help here.

However, where did you get your QNX waverec binary from. Did you compile it yourself from the QNX source code (which I found by googling) or did you get the binary image from QNX.

Are you running the QNX O/S in 32 or 64 bit mode? I ask this and the prior question because maybe waverec is compiled for the wrong mode or you grabbed the 32 bit exe instead of the 64 bit exe and that is why it only partially is working (8 bit mode).

With regards to serial receiving:
I saw that other link. It’s from 2012 and from a prior version of QNX (6.X). You can try turning off the OHFLOW and IHFLOW from stty or your sample code but it seems very unlikely you have the kind of cable that would require that. All the off the shelf RS 232 cables I’ve ever used just ‘worked’.

Of course once again if you are running the wrong version of devc-ser8250 (32 bit vs 64 bit) it might be the issue. You mentioned running QNX in a VMWare image. Does your serial program/cat command work in the VMWare image (assuming the host machine has a serial port)

Tim

P.S. If you’ve started the QNX system logger (slogger or slogger2) you might use sloginfo or slog2info to check the contents of the logger. Perhaps waverec or passwd or devc-ser8250 logged something. Or you can stop and restart them with higher logging on and see if anything useful shows up.

Hi Tim,

Please find our inline comments as below,

1. Serial Port :

With regards to not being able to change the password:
This sounds like your QNX filesystem is mounted as ‘read only’.

Are you able to write/delete/edit anything on your QNX filesystem?

[John] We have created two partitions based on filesystem type 178 and 179 and mounted 179 partitions under the home directory.

We are not able to edit/write anything in any folders or files (etc, dev, bin,) except the home directory. Since we have mounted home directory as read /write, we are able to create directories, files under the home folder.

Please advise your inputs to mount qnx filesystem as read/writable.

If you are able to do so, what do the file permissions in /etc and /etc/pam.d look like

[John] We gave full permission for /etc folder and pam.d files and tried to change the password. But still we have observed the same issue.

Can you post your QNX build file (the one you used to build the QNX .boot image). I just want to make sure you didn’t put the password stuff in the boot image itself (which is read only).

[John] We have attached our build file for reference. Kindly take a look into build file.

2. Audio :

However, where did you get your QNX waverec binary from. Did you compile it yourself from the QNX source code (which I found by googling) or did you get the binary image from QNX.

[John] waverec and wave commands are inbuilt qnx binaries. In our build file, we just added both commands .

Are you running the QNX O/S in 32 or 64 bit mode? I ask this and the prior question because maybe waverec is compiled for the wrong mode or you grabbed the 32 bit exe instead of the 64 bit exe and that is why it only partially is working (8 bit mode).

[John] We are using 32-bit BSP and we are able to execute command successfully. But the issue is it doesn’t record.

Wave works fine.

3. Serial Port :

Our Vmware setup doesn’t have serial ports. We will check the same image in another board and provide our observations.

Thanks,
John.

Tim · October 18, 2019, 2:19pm

Hi John,

I didn’t see your build file???

It’s definitely a good idea to try on a second board just to eliminate the potential problem of the physical hardware being bad.

As far as mounting goes, I’d need to see the mount commands (presumably in your build file). Normally unless you specify the -r option (read only) everything should be read/write (assuming you are logging in as a root user).

Tim

P.S. Another user replied but I am having trouble approving his post. So I’m cutting and pasting his response below: