QSerialPort::readyRead() not fired any more after QSerialPort::close() and QSerialPort::open()

? Offline

Hello to all,
I got the following strange behaviour with QSerialPort::readyRead():
I create a QSerialPort object, open a port and connect its QSerialPort::readyRead() with a function for reading incoming data. Everything works fine until I close the connection and reopen it, again (I need to unload the g_serial kernel driver and load it, again). QSerialPort::readyRead() seems not to fire any more. Until I restart the whole application, again.
Does anybody have an idea?

My code is as follows:

MainWindow::MainWindow(QWidget *parent) :
    QWidget(parent),
    ui(new Ui::MainWindow)
{
    ...    
    openSerialPort();
}

void MainWindow::openSerialPort()
{
    serial = new QSerialPort(this);
    ...
    if (serial->open(QIODevice::ReadWrite)) {
        connect(serial, &QSerialPort::readyRead, this, &MainWindow::serialPortReadData);
   }
}

void MainWindow::closeSerialPort()
{
    if(!serial->bytesToWrite()){
//        disconnect(serial, SIGNAL(readyRead()), this, SLOT(serialPortReadData()));
        serial->close();
        delete serial;
    }
}

Calling openSerialPort() after closeSerialPort(), the connect is successful (returns "true"), but the slot serialPortReadData() is never called any more. So I conclude that that the signal doesn't fire any more. But why?

Kind regards,

Markus

Maniek1313

Hi !

You check result serial->open with error code.

http://doc.qt.io/qt-5/qserialport.html#error-1

? Offline

Hello Maniek,

thanks for your fast response!

I inserted the following lines after serial->open in openSerialPort():

qDebug() << "Serial error: " << serial->error();
qDebug() << "Serial errorString: " << serial->errorString();

The output of the former is "11" (QSerialPort::UnknownError - http://doc.qt.io/qt-5/qserialport.html#error-prop), the output of the latter is "Invalid argument". Strangely, this is also the output when opening the port for the first time (where everything works perfectly).

Currently I'm looking if maybe the Linux device file for the interface is maybe created slower than qt opens the interface and open() gives out no error, anyway.

Kind regards,

Markus

? Offline

Hm,

I also tried connecting to the signal QSerialPort::error. The connected slot is called twice each time, but with the same error codes.

Does anybody know what the output "invalid argument" of QSerialPort::errorString() means exactly? Is there somewhere a list explaining the output of QSerialPort::errorString()? So far I could'nt find any on http://doc.qt.io.

Also, delaying the re-opening of the interface after inserting the driver module again, didn't show any differences...

So, still, any help is much appreciated...

kuzulis

What is QtSerialPort version?

I need to unload the g_serial kernel driver and load it, again

What is reason in this?

bsomervi

Is the device a Prolific USB to serial interface.

mrjj

Hi
I was wondering if you could try the "Terminal Example"
and see if had same issue.

? Offline

Thanks for your answers!

I'm currently on sick leave (since today) and will try out the terminal example and be able to answer questions as soon as I will be back to work.

@kuzulis: I'm using Qt5.3. In case there is a specific version of SerialPort, I will try to check as soon as I'm back to work.
The reason why I unload the g_serial driver and load it again is as follows: I want to use both gadget drivers g_serial and g_mass_storage (both are linux kernel drivers, the former for using the USB OTG interface like a serial one and the latter to share one or more directories with a PC via USB, appearing to the PC as a disk drive). Only one of them can be loaded at a time, so when needing the functionality of g_mass_storage, I have to unload g_serial and when coming back to it, I have to load its module, again. Actually a composite gadget driver exists, which could also be a possible solution to the problem, but as far as I've read this could make it more difficult on the PC driver side.

@bsomervi: No, the device is a virtual serial port using the g_serial gadget driver on the USB OTG interface. In fact I use a Prolific USB to serial device, but only for console communication with the target board, which should not interfere with my actual problem. Anyway, if you've experienced problems with the Prolific device, just let me know, since this might be helpful on other occasions!

Kind regards,

Markus

mrjj

@MarkusBraitner
oh, wish you well then

? Offline

Ok, I'm back to work, again :-)

@mrjj: thanks!

@kuzulis: I now could check my Qt installation on the target. I'm using Qt 5.3.2 compiled using Yocto and the qtserialport module seems also to be version 5.3.2 (at least this version number is included in the corresponding Yocto recipe).

Will now also try the terminal example as soon as possible.

Kind regards,

Markus

kuzulis

seems also to be version 5.3.2

It is better to trying the 5.6.0 version of QtSerialPort, because between 5.3.2 and 5.6.0 many changes and differences.. , and for me has not sense make tests for 5.3.2, because it is too become outdated.

? Offline

@kuzulis: Thanks for the hint to update to 5.6.0! Since it is some effort to update the embedded installation on the Qt target, I first tried the terminal example with 5.3.2, just adding /dev/ttyGS0 as a serial interface manually. Interestingly, transmission worked very well even after re-loading the g_serial driver.

So i had a look at my own qt program, again. First, very strangely, transmission didn't work at all, but after restarting the embedded system, doing a "clean all" on the project and built it again, everything now works perfectly also in my program... Very strange...

So I hope there has only happened something in the build directory and now everything is solved doing the clean and re-building...

Everybody, thanks a lot for your help!

Greetings,

Markus

PS: I also had to update my desktop qt installation for receiving the terminal example files (didn't find the bundled files on the qt site and my installation didn't provide them, also), but I guess this didn't have an effect on my cross-compiled application...