Turning off power to a running QSerialPort

sykac

Hello,
I'm developing an application with several serial ports. Each of these ports is handled by a different thread and has its own QSerialPort object. From a hardware point of view, they are connected hierarchicaly, meaning that there is one main device connected to the PC with a usb cable (1 COM port), to this main device there are several other devices connected, each of them having its own COM port. The main device can turn on/off the power supply to these child ports.

In the application, the ports are handled asynchronously. Each device object is running in its own loop. If its port is opened, it reads the incoming data. If the port is closed, it tries to open it in every loop until it succeeds. Each QSerialPort object handles errors on the errorOccurred signal. If it receives DeviceNotFoundError, PermissionError, ResourceError error, the port is closed (if it was opened) and the looping continues as described above.

The problem is that this serial communication part of the application is crashing (segmentation fault). I spent days finding the issue but with no results so far. To better understand what is going on, I wanted to ask here. Could it be a problem for QSerialPort if the main device turns off the power supply for the child ports while they're opened and are working? Or if the power supply is turned off while the child ports are being opened/closed or any other operation is being executed on them?

Thanks for any help or ideas!

mrdebug

I'm not sure to having understood.
Is power off a child port similar to remove a usb / ftdi adapter? If yes it is normal to having the QSerialPort object goes to crash.
I suggest you to implement directly the libusb or better, send a command to power off but, the device has to execute it later, after the serial port clouse procedure.

JKSH

@sykac said in Turning off power to a running QSerialPort:

Could it be a problem for QSerialPort if the main device turns off the power supply for the child ports while they're opened and are working? Or if the power supply is turned off while the child ports are being opened/closed or any other operation is being executed on them?

I believe it heavily depends on the drivers for those serial ports. A good driver shouldn't cause software to crash when the connected device loses power.

How does your PC know about the "child" ports?
To understand your problem better... are you saying that the crashes only occur if you cut power?

sykac

@mrdebug By power off I mean literally switching off electricity.

@JKSH 1. The main device has a USB hub. To this hub there are 6 ports connected.
2. I don't have answer to this question. I don't know when the application crashes exactly, I'm just sure it's because of the serial communication and I'm trying to find out what could be a problem for QSerialPort.

I'm sorry for this abstract question but I have troubles understanding the problem myself.

JKSH

@sykac said in Turning off power to a running QSerialPort:

The main device has a USB hub. To this hub there are 6 ports connected.

Is the hub externally powered? If not, there's a small chance you might get a power overload.

P.S. Earlier you mentioned "there is one main device connected to the PC with a usb cable (1 COM port)". Note that a USB hub only has USB ports -- it has no COM ports.

           2. I don't have answer to this question. I don't know when the application crashes exactly, I'm just sure it's because of the serial communication and I'm trying to find out what could be a problem for QSerialPort.

I'm sorry for this abstract question but I have troubles understanding the problem myself.

Unfortunately, I can't do much with such a vague description.

You need to spend time troubleshooting. For example:

See if you can gradually remove code from other parts of your application and still cause the crash.
See if the crashes occur when you only have 1 instead of 6 serial devices.
See if a different hub causes the crashes.
See if a dedicated multi-serial-port hub causes the crashes: https://www.moxa.com/product/UPort_1610-8.htm

mrdebug

If you unplug the device when the serial port is open it is normal to have a crash.
It is similar to remove an usb pen drive when you are working on a file.
The os could have a problem with device handle, for example it can assign a diferent description to the device when you replug it.

J.Hilk

you might be doing something wrong in your threads.

I have an application that is running a QSerialPort in a thread, with constant data polling, and if I unplug the usb/COM-Port dongle

I get simply an

QModbusDevice::Error(ConnectionError) "Resource error."

to what I react to.

aha_1980

Just to add my experience to @mrdebug and @J-Hilk:

I sometimes have problems with electrical arcs in our devices. If a computer is connected through USB (with FTDI USB-serial converter), anything can happen: often I'm unable to close and re-open the serial port. It seems this is dependend on the device driver.

In most cases it helps to disconnect and reconnect the USB cable, but I also remember cases where a PC reboot was needed.

MrShawn

Make sure you don't have any dangling pointers. Usually my programs are crashing when I do something stupid with a pointer. If you have multiple threads you are likely doing things with pointers somewhere, and you may not have been as careful as you think you were. I'd run in debug mode and see if any insight is provided.

sykac

@aha_1980 That's my case, some of my devices are using ftdi usb-serial converter. What exactly do you mean device drivers? I just manually downloaded ftdi drivers from the official web. I thought I couldn't do anything wrong with that, I just downloaded and installed the driver.

So you are saying it is not solveable? It just happens with this kind of HW?

J.Hilk

@sykac where does your program actually crash!? Have you run your program with the debugger attached yet? If yes, what does the stacktrace say?

JKSH

@sykac said in Turning off power to a running QSerialPort:

So you are saying it is not solveable?

Before you can solve it, you must first track down the cause of the crash.

You need to spend time troubleshooting. For example:

See if you can gradually remove code from other parts of your application and still cause the crash.
See if the crashes occur when you only have 1 instead of 6 serial devices.
See if a different hub causes the crashes.
See if a dedicated multi-serial-port hub causes the crashes: https://www.moxa.com/product/UPort_1610-8.htm

sykac

@J-Hilk @JKSH So it seems there is more problems in my serial communication. One problem starts probably in the hardware. The COM port of the device disconnects from the PC (I don't why, it could be some driver/firmware issue), QSerialPort emits error "The attached device is not functioning.". Then the application closes the serial port and tries to reopen it. It opens succesfully but when waitForReadyRead(3000) is called after that, the thread hangs forever. It doesn't crash, just hangs.

It is weird as in the Device Manager I cannot see the COM port anymore, although the QSerialPort opens succesfully.

Then there is another error which causes the crashing but I couldn't find the reproducer for it yet.

aha_1980

@sykac said in Turning off power to a running QSerialPort:

One problem starts probably in the hardware. The COM port of the device disconnects from the PC (I don't why, it could be some driver/firmware issue)

Reading you topic title, could it be that the USB connection between PC and FTDI is interrupted? And that's what I said, this may lead to endless loops in the device driver.

This kind of problems can hardly be solved in the user space.