PEAK-System Forum

Hi @all,

I'm having some problems using the socketcan interface that comes with the pcan driver.
My set up is the following:
- Linux PC with pcan interface, master software working on one socket, Wireshark/candump sniffing on another socket.
- Microcontroller with integrated can interface, working as slave.
When I start this system, everything works as expected.
But when I disconnect the PC interface on the can bus side for a few seconds, the socket driver starts behaving weird after reconnection. It seems to be repeating messages received from the bus, over and over again. With time those repeating messages even get more frequent.
In this image, every 1s there is one real message and ~7 bogus ones. I verified that those are bogus messages by connecting a second bus monitor device.

I've tried the same procedure with an embedded linux device (IMX28), and there are no problems.

More info:
Linux Debian 8, Kernel 3.16.0-4-amd64
Hardware USB ID 0c72:000c PEAK System PCAN-USB
Driver peak-linux-driver-8.2

Thank you for your help!

Hi,

when you disconnect the CAN bus cables from a PCAN-USB while the CAN communication is active, the CAN controller will rise the errorcounters and set the error interrupt, which will force the PCAN-USB firmware to send status messages to the driver.

CAN (and especially a DSub connector) is not a hotplug system. Please always remove the PCAN-USB from the USB port, before you un- or replug the CAN bus cables, to prevent a damage of the CAN transceivers.

regards

Michael

This also happens when my slave device disables the CAN hardware.
In my case, this is the case when the master requests the slave to enter bootloader mode.

Hi,

yes, you will see status messages of the PCAN-USB. Please have a look in cat /proc/pcan to see the error and status for your connected device. You can use the "restart" option with ip link set to automatically reset the connection after a busoff. But as long as the CAN-Controller is in error state, PCAN-USB will send out status messages.

regards

Michael

Hi,

I don't have status/error messages enabled for the socket. The messages I'm getting are regular messages that have passed the driver at some point. However, they are not on the physical bus at that moment of time.

Maybe a few comments inside the screenshots will clarify my problem
In this example, it's always the same message, but that is not necessarily the case.

ip link set canX down / up cycle does not change that behaviour.

content of /proc/pcan before down - up cycle ...and after

sudo ip link set canX type can restart

seems not to work? (RTNETLINK answers: Invalid argument)

Please send us a raw CAN Layer 2 Dump - not a WireShark CANOpen Dissetor screen.

no problem. It's getting really strange now

In this log are two messages per second on the bus (that is correct). The ID 704 message is transmitted by a socket application and the 705 by a bus device.

output of candump -t A can0

-- everything is fine here --
(2016-12-19 14:08:07.531693) can0 704 [1] 7F
(2016-12-19 14:08:08.396058) can0 705 [1] 05
(2016-12-19 14:08:08.532774) can0 704 [1] 7F
(2016-12-19 14:08:09.396079) can0 705 [1] 05
(2016-12-19 14:08:09.534489) can0 704 [1] 7F
(2016-12-19 14:08:10.396101) can0 705 [1] 05
(2016-12-19 14:08:10.535242) can0 704 [1] 7F
(2016-12-19 14:08:11.396079) can0 705 [1] 05
-- now the bus device is powered down --
(2016-12-19 14:08:11.536191) can0 704 [1] 7F
(2016-12-19 14:08:12.536922) can0 704 [1] 7F
(2016-12-19 14:08:13.537747) can0 704 [1] 7F
(2016-12-19 14:08:14.539551) can0 704 [1] 7F
(2016-12-19 14:08:15.541482) can0 704 [1] 7F
(2016-12-19 14:08:16.542169) can0 704 [1] 7F
(2016-12-19 14:08:17.542937) can0 704 [1] 7F
-- and powered up again. from here it is messed up. 704 message matches system time, 705 is in the future --
(2016-12-19 14:08:18.403311) can0 705 [1] 00
(2016-12-19 14:08:18.543925) can0 704 [1] 7F
(2016-12-19 14:08:19.545614) can0 704 [1] 7F
(2016-12-19 14:08:21.199514) can0 705 [1] 00 -- this does not exist
(2016-12-19 14:08:20.547196) can0 704 [1] 7F
(2016-12-19 14:08:23.995717) can0 705 [1] 00 -- this also
(2016-12-19 14:08:29.291930) can0 705 [1] 05
(2016-12-19 14:08:21.548145) can0 704 [1] 7F
(2016-12-19 14:08:30.291951) can0 705 [1] 05
(2016-12-19 14:08:22.548879) can0 704 [1] 7F
(2016-12-19 14:08:31.291930) can0 705 [1] 05
(2016-12-19 14:08:23.549728) can0 704 [1] 7F
(2016-12-19 14:08:32.291951) can0 705 [1] 05
(2016-12-19 14:08:24.550585) can0 704 [1] 7F
(2016-12-19 14:08:33.291973) can0 705 [1] 05
(2016-12-19 14:08:25.551677) can0 704 [1] 7F
(2016-12-19 14:08:34.291951) can0 705 [1] 05
(2016-12-19 14:08:26.553179) can0 704 [1] 7F
(2016-12-19 14:08:35.291973) can0 705 [1] 05
(2016-12-19 14:08:27.553914) can0 704 [1] 7F
(2016-12-19 14:08:36.291994) can0 705 [1] 05
(2016-12-19 14:08:28.555463) can0 704 [1] 7F
(2016-12-19 14:08:37.291973) can0 705 [1] 05
(2016-12-19 14:08:29.556362) can0 704 [1] 7F
(2016-12-19 14:08:38.291994) can0 705 [1] 05
(2016-12-19 14:08:30.556723) can0 704 [1] 7F
(2016-12-19 14:08:39.292015) can0 705 [1] 05


Is it possible that something goes wrong while building the driver? Is there any way to verify the binary? The only thing I can see is a warning "Compiling for __LP64__". I've attached the build log.

The Compiler Warning is "normal" if you compile on a 64Bit System. All looks OK.
Please Unplug and PlugIn the CAN-USB and check if this Problem is still there.

How could you be sure that these CAN Frames are not on the BUS?
Have you any option to connect a third CAN node (CAN Interface on a PC, CAN Handheld, Scope with CAN feature etc.) to verify that these Messages are not physically on the BUS?

Please Unplug and PlugIn the CAN-USB and check if this Problem is still there.

this fixes the problem.

How could you be sure that these CAN Frames are not on the BUS?

'
I've connected a third device in listen only mode to the bus (freescale I-MX28 device running embedded linux).

Same setup as before

PC
-- everything is fine here --
(2016-12-19 15:27:18.737729) can0 704 [1] 05
(2016-12-19 15:27:19.110211) can0 705 [1] 7F
(2016-12-19 15:27:19.738615) can0 704 [1] 05
(2016-12-19 15:27:20.110232) can0 705 [1] 7F
(2016-12-19 15:27:20.740449) can0 704 [1] 05
(2016-12-19 15:27:21.110211) can0 705 [1] 7F
(2016-12-19 15:27:21.741130) can0 704 [1] 05
(2016-12-19 15:27:22.110232) can0 705 [1] 7F
(2016-12-19 15:27:22.741919) can0 704 [1] 05
(2016-12-19 15:27:23.110254) can0 705 [1] 7F
(2016-12-19 15:27:23.742634) can0 704 [1] 05
(2016-12-19 15:27:24.110232) can0 705 [1] 7F
-- now the bus device is powered down --
(2016-12-19 15:27:24.744585) can0 704 [1] 05
(2016-12-19 15:27:25.746588) can0 704 [1] 05
(2016-12-19 15:27:26.747528) can0 704 [1] 05
(2016-12-19 15:27:27.748266) can0 704 [1] 05
-- and powered up again--
(2016-12-19 15:27:28.248302) can0 705 [1] 00
(2016-12-19 15:27:28.749291) can0 704 [1] 05
(2016-12-19 15:27:31.044504) can0 705 [1] 00 -- twice
(2016-12-19 15:27:29.750043) can0 704 [1] 05
(2016-12-19 15:27:35.340654) can0 705 [1] 05
(2016-12-19 15:27:30.750945) can0 704 [1] 05
(2016-12-19 15:27:36.340675) can0 705 [1] 05
(2016-12-19 15:27:31.752165) can0 704 [1] 05
(2016-12-19 15:27:37.340654) can0 705 [1] 05
(2016-12-19 15:27:32.753366) can0 704 [1] 05
(2016-12-19 15:27:38.340675) can0 705 [1] 05
(2016-12-19 15:27:39.340696) can0 705 [1] 05
(2016-12-19 15:27:33.754514) can0 704 [1] 05
(2016-12-19 15:27:40.340675) can0 705 [1] 05
(2016-12-19 15:27:34.756555) can0 704 [1] 05
(2016-12-19 15:27:41.340696) can0 705 [1] 05
(2016-12-19 15:27:35.757302) can0 704 [1] 05
(2016-12-19 15:27:42.340718) can0 705 [1] 05
(2016-12-19 15:27:36.758009) can0 704 [1] 05
(2016-12-19 15:27:43.340696) can0 705 [1] 05
(2016-12-19 15:27:37.758711) can0 704 [1] 05
(2016-12-19 15:27:44.340718) can0 705 [1] 05
(2016-12-19 15:27:38.759684) can0 704 [1] 05
(2016-12-19 15:27:45.340739) can0 705 [1] 05

Embedded device in listen only mode
(2016-12-19 15:27:18.643545) can0 705 [1] 7F
(2016-12-19 15:27:19.271733) can0 704 [1] 05
(2016-12-19 15:27:19.643577) can0 705 [1] 7F
(2016-12-19 15:27:20.272327) can0 704 [1] 05
(2016-12-19 15:27:20.643608) can0 705 [1] 7F
(2016-12-19 15:27:21.272827) can0 704 [1] 05
(2016-12-19 15:27:21.643639) can0 705 [1] 7F
(2016-12-19 15:27:22.273452) can0 704 [1] 05
(2016-12-19 15:27:22.643671) can0 705 [1] 7F
-- now the bus device is powered down. PC is not getting ACK --
-- and powered up again--
(2016-12-19 15:27:26.781640) can0 704 [1] 05
(2016-12-19 15:27:26.781733) can0 704 [1] 05
(2016-12-19 15:27:26.781796) can0 705 [1] 00 -- only once
(2016-12-19 15:27:26.781827) can0 704 [1] 05
(2016-12-19 15:27:26.781952) can0 704 [1] 05
(2016-12-19 15:27:27.279140) can0 704 [1] 05
(2016-12-19 15:27:27.281765) can0 705 [1] 05
(2016-12-19 15:27:28.279765) can0 704 [1] 05
(2016-12-19 15:27:28.281796) can0 705 [1] 05
(2016-12-19 15:27:29.280421) can0 704 [1] 05
(2016-12-19 15:27:29.281827) can0 705 [1] 05
(2016-12-19 15:27:30.281452) can0 704 [1] 05
(2016-12-19 15:27:30.281858) can0 705 [1] 05
(2016-12-19 15:27:31.281890) can0 705 [1] 05
(2016-12-19 15:27:31.282484) can0 704 [1] 05
(2016-12-19 15:27:32.281921) can0 705 [1] 05
(2016-12-19 15:27:32.283452) can0 704 [1] 05
(2016-12-19 15:27:33.281952) can0 705 [1] 05
(2016-12-19 15:27:33.285265) can0 704 [1] 05
(2016-12-19 15:27:34.281984) can0 705 [1] 05
(2016-12-19 15:27:34.285827) can0 704 [1] 05
(2016-12-19 15:27:35.282015) can0 705 [1] 05
(2016-12-19 15:27:35.286359) can0 704 [1] 05
(2016-12-19 15:27:36.282046) can0 705 [1] 05
(2016-12-19 15:27:36.286827) can0 704 [1] 05
(2016-12-19 15:27:37.282077) can0 705 [1] 05
(2016-12-19 15:27:37.287609) can0 704 [1] 05
(2016-12-19 15:27:38.282109) can0 705 [1] 05
(2016-12-19 15:27:38.289015) can0 704 [1] 05



Different question: is this an english-only forum or is it ok to use german?

Hi - wir können auch auf Deutsch reden - oder noch einfacher - schreiben Sie uns an die support@peak-system.com oder rufen Sie uns einfach an : 06151-8173-20 --> technischen Support verlangen.