Details
-
Bug
-
Resolution: Invalid
-
Not Evaluated
-
None
-
5.9.1
-
* Board: toradex iMX6
* Linux: Linux TORA-DEX 3.14.52-00011-g9f2723e-dirty #11 SMP Mon Mar 6 13:52:01 MSK 2017 armv7l GNU/Linux
* CAN: socketcan
Description
I use the simple code to initialize the CAN device of my 'consumer' application:
auto device = QCanBus::instance()->createDevice("socketcan", "can1"); device->setConfigurationParameter(QCanBusDevice::LoopbackKey, false); connect(device, &QCanBusDevice::framesReceived, [this]() { // E.g. read all available messages and print out its ids }); connect(device, &QCanBusDevice::errorOccurred, [this]() { // E.g. print out all errors }); device->connectDevice();
On other side I have an other 'producer' application (on Windows with PEAK-CAN backend) which sends periodically the CAN messages every ~200 msecs to my 'consumer' application.
My 'consumer' application starts automatically via initrc script at system boot.
My problem is that sometimes, after the system reboot by power, my 'consumer' application starts, but does not receive the CAN messages within ~20 seconds (I did not see any errors).
I see, that the CAN interface is in Up/Running state, so, it is strange. Seems, that this ~20 seconds similar to 'default TCP linux connection timeout': http://www.sekuda.com/overriding_the_default_linux_kernel_20_second_tcp_socket_connect_timeout.
If I use the candump utility, which I start via initrc script (instead of my 'consumer' application), then it always received the CAN-messages.
So, seems, the problem is somewhere in qt & socketcan backend.