CAN_Initialize failed with PCAN_ERROR_ILLOPERATION error

[fzchen]

Hi,
I have a Linux workstation installed with one quad PCAN-PCIe card and one PCAN-USB Pro device. The OS is Ubuntu 18.04 and I have peak-linux-driver-8.10.1 installed. I have modified /etc/modprobe.d/blacklist-peak.conf to allow PCAN-PCIe device use socket can driver and PCAN-USB device use character driver.

The PCAN-USB device looks like work properly with the transmittest and receivetest programs. But it met some issues with the PCANBasic pcanwrite example program. The error occurs during CAN_Initialize API call. The error code is 0x8000000(PCAN_ERROR_ILLOPERATION).

According to the document, "PCAN_ERROR_ILLOPERATION Indicates that an action cannot be executed due to the state of the hardware. Possible causes are: The desired PCAN-Channel is a LAN Channel, which uses a different bit rate than the specified."

What's the exact mean of "LAN channel"? Is it conflict with some things?

I have tried to reboot my machine. I found the pcanwrite program can work as expected at the 1st minute after reboot. But then the device cannot be initialized.

I need your help with the diagnosis. Thank you!

[fzchen]

Some new finding:

I found the issue can be fixed by replugging the PCAN-USB device or reload pcan driver remotely. So the issue only occurs after work station reboot without unplugging/plugging the PCAN-USB device.

I do not find such an issue on another Linux laptop. Why different behavior on different Linux machine? Is it related with kernel version? The kernel version on my Linux laptop is 5.3.0-59-generic, while the one on work station is 4.15.0-99-generic.

I still need to understand the exact meaning of PCAN_ERROR_ILLOPERATION error, and the underlying root cause of the strange phenomenon described above. Thank you!

[M.Heidemann]

Hello,

Apparently you use the hardware-handle in a static fashion ("51h") but the handle might changes after a reboot (this is system related).

The error message in this case means that the wrong hardware id will cause the application to try to initialize a non char-dev device, hence why it says it is a LAN channel. (NetDev)

You might want to try to change the code, so that it uses the right hardware (for example "pcanusbX", where X represents a channel number).

Alternatively you can assign device ids to CAN-channels:

The assignment of device IDs to CAN-Channels is also described in this forum post:
https://forum.peak-system.com/viewtopi ... evid#p5423

You can use this post as reference.


Make sure you use the assign paramter for every available channel, for me the channels came up as pcanusbfd32 -37 using

Code: Select all

cat /proc/pcan

In your case you should also assign device-ids to your PCIe channels so they will not go out of order after reboot.


You can check the current device ID like this (from the driver directory):

Code: Select all

sudo test/pcan-settings -f=/dev/pcansubfd32 -d

So i went through assigning a DeviceID to each channel (from the driver directory):

Code: Select all

sudo test/pcan-settings -f=/dev/pcansubfd32 -d=0
sudo test/pcan-settings -f=/dev/pcansubfd33 -d=1
sudo test/pcan-settings -f=/dev/pcansubfd34 -d=2

etc ..

Afterwards just add the line:

Code: Select all

options pcan assign=devid

in

Code: Select all

/etc/modprobe.d/pcan.conf

with your text-editor,
like it is described in the forum post.

On next startup the channels will be assigned to the device ID you have set before.

[fzchen]

Hi,
Thank you for the detailed instruction!
I have followed your instructions to fix the device ID. But after reboot, the issue keeps the same as before.

Note that my PCAN-USB device can work properly at the first 2~3 minutes after every reboot. At each power cycling, I keep repeating the test, and find out the CAN_Initiaize always fails after 2~3 minutes. I'm curious why it happens 2~3 minutes later after reboot, but not right after reboot?

[M.Heidemann]

Hello,

Hard to evaluate what exactly causes the change here, especially after a couple of minutes.

Seems like there is some service running in the background that will cause these issues.

Can you share the output of

Code: Select all

cat /proc/pcan

once this issue arises?

Can you try to run the same test on a different system?

Does the same behaviour manifest there?


Best Regards


Marvin

[fzchen]

Hi,

The output of "cat /proc/pcan" command is as below, and it is same before or after the issue occurs.

*------------- PEAK-System CAN interfaces (www.peak-system.com) -------------
*------------- Release_20200519_n (8.10.1) Jun 12 2020 02:59:30 --------------
*---------------------------- [mod] [par] [usb] -----------------------------
*--------------------- 2 interfaces @ major 511 found -----------------------
*n -type- -ndev- --base-- irq --btr- --read-- --write- --irqs-- -errors- status
32 usbfd -NA- ffffffff 000 0x001c 000a86e6 01a92f84 0108da01 00000000 0x0000
33 usbfd -NA- ffffffff 001 0x001c 00000000 00000000 00000000 00000000 0x0000

I don't find similar issue in another system as I described in my 2nd post above. But these two systems are different in linux kernel and HW configuration. The machice I met the issue has an additional quad PCAN-PCIe card (use netdev driver), while another system does not. I do not have two identical systems.

I agree with you some background service might cause the issue. By the way, is it possible the netdev driver based quad PCAN-PCIe card interfere with the chardev driver based PCAN-USB device?

Thanks,
Fanzhong

[M.Heidemann]

Hello,

You should try the following:

if you remove the PCAN-PCIe device and run the same test only using the PCAN-USB, does this cause the same behaviour?

If the same issue persists this is not due to a hardware conflict, also you may want to keep an eye on running services while testing.

Please report back to me with your results.

Best Regards

Marvin

[fzchen]

Hi Marvin,
Thank you for the guidance.Since the project schedule is tight, and I found a workaround by just reloading the driver after a new boot. So I would like to postpone the root cause investigation.

I would like to hold this thread for now. I will try it and report back to you later.

Thank you again,
Fanzhong