Weird behavior of serial port under Windows 7

Mark81

Qt 5.15.2, this code:

QSerialPort *_serial;

_serial = new QSerialPort(this);
_serial->setPortName(port);
 if (_serial->open(QIODevice::ReadWrite)) 
 {
     _serial->setBaudRate(115200);
     // ...
 }

Works fine under Ubuntu 20.40+ and Windows 10 allowing me to send and receive data from the serial line.
Instead running it with Windows 7 no data is sent nor received. I checked the error() method but nothing is there.

Opening and closing the port using another terminal (i.e. RealTerm) before running my application leads to the expected behavior. Instead, just opening and close the port using command line:

mode com19: baud=115200 Parity=n Data=8 Stop=1

does not help.

Is this a known issue? I remember this but it is not my case.
Any workaround?

KroMignon

@Mark81 said in Weird behavior of serial port under Windows 7:

Is this a known issue? I remember this but it is not my case.
Any workaround?

AFAIK, you have to configure serial port before calling open().
Did you try this:

_serial->setPortName(port);
_serial->setDataBits(QSerialPort::Data8);
_serial->setStopBits(QSerialPort::OneStop);
_serial->setParity(QSerialPort::NoParity);
_serial->setFlowControl(QSerialPort::NoFlowControl); // No RTS/CTS flow control or XON/XOFF
_serial->setBaudRate(115200);
if (_serial->open(QIODevice::ReadWrite))
{
// ...
}

kuzulis

@KroMignon said in Weird behavior of serial port under Windows 7:

AFAIK, you have to configure serial port before calling open().

No. It is irrelevant.

@Mark81 ,

Try to connect the RX && TX pins, compile the Terminal example and try to put something, at first.

Mark81

@kuzulis actually there are no RX/TX pins because the port is a USB / CDC one.

KroMignon

@Mark81 said in Weird behavior of serial port under Windows 7:

actually there are no RX/TX pins because the port is a USB / CDC one.

Did you deactivate flow control (_serial->setFlowControl(QSerialPort::NoFlowControl))?

Mark81

@KroMignon no, because the documentation states:

The default value is NoFlowControl, i.e. no flow control

anyway I can add this line and check if anything changes.

KroMignon

@Mark81 said in Weird behavior of serial port under Windows 7:

Opening and closing the port using another terminal (i.e. RealTerm) before running my application leads to the expected behavior. Instead, just opening and close the port using command line:

@Mark81 said in Weird behavior of serial port under Windows 7:

no, because the documentation states:
    The default value is NoFlowControl, i.e. no flow control
anyway I can add this line and check if anything changes.

It maybe the default value, but as you notice, serial port works after configure it with another serial port terminal.
This means to me, that default values are not really defaults!
I always (re)configure full settings (baudrate, word size, stop bits, parity and flow control mode) before using QSerialPort to be sure to have the configuration I expect to have.

Mark81

@KroMignon I added the following lines:

    qDebug() << _serial->setBaudRate(115200);
    qDebug() << _serial->setDataBits(QSerialPort::Data8);
    qDebug() << _serial->setFlowControl(QSerialPort::NoFlowControl);
    qDebug() << _serial->setParity(QSerialPort::NoParity);
    qDebug() << _serial->setStopBits(QSerialPort::OneStop);
    qDebug() << _serial->errorString();

The output is:

true
true
true
true
true
Unknown Error

but the behavior is unchanged.

hskoglund

Hi, just a guess but for completeness, you could try adding a toggle of the DTR, e.g.:

    qDebug() << _serial->setBaudRate(115200);
    qDebug() << _serial->setDataBits(QSerialPort::Data8);
    qDebug() << _serial->setFlowControl(QSerialPort::NoFlowControl);
    qDebug() << _serial->setParity(QSerialPort::NoParity);
    qDebug() << _serial->setStopBits(QSerialPort::OneStop);
    qDebug() << _serial->setDataTerminalReady(true);   // set DTR
    qDebug() << _serial->errorString();

kuzulis

@Mark81 said in Weird behavior of serial port under Windows 7:

Unknown Error

Try to check, what's call setBaudRate, setDataBits, setFlowControl, setParity, or setStopBits produces this error.

PS: Most likelly you have a bug in the CDC firmware.

Mark81

@hskoglund your wild guess did the trick! Now it works as expected! But is this behavior documented somewhere? Because I NEVER had to set the DTR in over 15 years of development....

hskoglund

Nice! 15 years is good, but now you have one more piece of serial comm. knowledge :-)

One of my first jobs was to connect Apple II to IBM mainframes and I remember resetting DTR to disconnect the modem. But I'd say that in this century DTR is very much an obsolete thing (so the USB-serial port Windows 7 driver shouldn't require a DTR toggle to behave properly.)