Brand new PCI Express 4-channel board, no send or receive

[langosta39]

Hello,

I just installed a new PCI Express 4 channel FD card that was ordered from phytools.com. All 4 CAN interfaces appear up in Ubuntu 20.04 with the standard kernel drivers and I can bring them up using:
sudo ip link set can0 type can bitrate 500000 berr-reporting off restart-ms 100
sudo ip link set up can0

However no data is sent over the wire when testing with
cansend can0 111#12341234
although ifconfig does show TX packets

Also no data is received on the bus using candump. I have a Peak USB CAN device configured on the same system and when i move the CAN cable to that device I can send and receive data using the same commands.

I built the custom drivers and tried them in NETDEV and non-NETDEV configuration then tested using commands from another forum post on a similar topic but nothing works.

Is there anything else to try before doing an RMA?
Andy

[PEAK-Support]

The cards are all finally tested and leave our company only when 100% OK

Please check if you have a physical problem first.
1. Termination (must be 2 x 120 Ohm on each end between CAN-H and CAN-L)
2. CAN-H and CAN-L are definitally not swapped ?
3. Run PCAN-View on Windows using the PCAN-USB Adpater and send a single Frame - check the Satus line - what do you read ?
4. Repeat with each Channel of the PCIe card, later on PCIe CAN Channels to each other on Linux.

[langosta39]

Hello, thanks for the quick reply.

1. We have a terminator on the DB9 on of the cable, so it moves with with CAN cable when we change adapters. The PEAK USB model sends and receives with no errors to our network with this cable.
2. CAN wires are definitely not swapped since the USB model works fine with the same cable. We verified that the pinout between the PCI and USB devices match. When I do swap the wires on the Linux side connector the USB CAN on Windows gives a passive error.
3. Ran a cable from Windows PC with USB CAN to Linux with PCIE CAN. Sending data from Windows PCAN-View the Status says OK, but Linux machine with 4chan PCIE receives nothing in PCAN-View or ifconfig.
4. Same behavior from Windows USB to all Linux PCIE all ports. A 2nd Peak USBCAN on the Linux machine does receive from the Windows machine. Putting both USB CAN devices on the Linux machine we can send and receive using our cable. Then moving the cable to the PCIE ports no data is seen when sending regularly from PCAN-View

Also tried in Ubuntu 18.04 on this machine and no data.

I believe this device is dead.

Andy

[PEAK-Support]

Please send us the result of lspci to see if the card is detected by the OS.

[langosta39]

Hello,

Yes, it is detected:
85:00.0 Network controller: PEAK-System Technik GmbH Device 0013 (rev 01)

When running PCAN-View with your custom driver installed it shows the 4 interfaces

When running the standard linux driver lsmod shows
lsmod | grep peak
peak_pciefd 24576 0
can_dev 40960 1 peak_pciefd

and 'ip link show' displays
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can
5: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can
6: can2: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can
7: can3: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can

[langosta39]

We got a 2nd board to try and we get the same behavior. I looked at the peak_canfd driver code, it would be pretty easy to add some log outputs to debug the behavior. I would be willing to help if someone familiar with the code and card could give some guidance so I don't have to spend a bunch of time understanding the architecture and basic behavior.

We could really use this unique quad interface device in our test system and product. For our product we plan to use the M.2 version of the quad FD adapter that uses the same driver. On Wednesday we will have our ARM64 Ubuntu 20.04 Kernel 5.10 platform to install the M.2 card into and hoping we don't run into this same issue.

Running 'cat kern.log | grep peak'
Oct 3 08:58:23 andy-HP-Z840-Workstation-u20 kernel: [ 11.668475] peak_pciefd 0000:85:00.0: enabling device (0100 -> 0102)
Oct 3 08:58:23 andy-HP-Z840-Workstation-u20 kernel: [ 11.668655] peak_pciefd 0000:85:00.0: 4x CAN-FD PCAN-PCIe FPGA v3.2.1:
Oct 3 08:58:23 andy-HP-Z840-Workstation-u20 kernel: [ 11.681719] peak_pciefd 0000:85:00.0: can0 at reg_base=0x000000008c1ae586 irq=16
Oct 3 08:58:23 andy-HP-Z840-Workstation-u20 kernel: [ 11.695410] peak_pciefd 0000:85:00.0: can1 at reg_base=0x00000000d0ff9238 irq=16
Oct 3 08:58:23 andy-HP-Z840-Workstation-u20 kernel: [ 11.715061] peak_pciefd 0000:85:00.0: can2 at reg_base=0x0000000085c2053c irq=16
Oct 3 08:58:23 andy-HP-Z840-Workstation-u20 kernel: [ 11.722375] peak_pciefd 0000:85:00.0: can3 at reg_base=0x000000005169da88 irq=16

So the device is probing without error, but there are no other log entries for the device to help understand what is happening.

[PEAK-Support]

Looks like your board need to be used with MSI. As this is still not supported by the Kernel Driver, you need to use our Driver
and edit /etc/modprobe.d/pcan.conf and add the red line, to enable MSI support:

# pcan - automatic made entry, begin --------
# if required add options and remove comment
# options pcan type=isa,sp
options pcan fdusemsi=1
install pcan modprobe --ignore-install pcan
# pcan - automatic made entry, end ----------

After that , please reboot your system once.

See driver manual for more details:

Linux_MSI.png (19.85 KiB) Viewed 5890 times

[langosta39]

That fixed it, thank you!!

After this issue was resolved I dug into all of the documentation of your custom driver. I am very impressed at the completeness of your driver's features and capabilities!

I'm not familiar with what MSI is and the docs don't explain it, so I could not have stumbled upon this solution by myself. Do you know why my computer requires this option? Was it the fact that all of my can interfaces had the same IRQ that you suggested this? It might be helpful to include this debugging information in the docs for future users. In any case, I am very grateful for your assistance via this forum.

Best,
Andy

[PEAK-Support]

Sound great - Hopefully now all work as expected!

More Info about the Message Signalled Interrupts (MSI) could be found here
All is depending on your used mainboard and the way the Int Handling is Setup. The MSI do not use physical Interrupt Lines - it use Messages, send over the PCIe Bus (min. PCI 2.2)

Important advantages of this type of interrupts are:

* Devices can generate different interrupts (messages)
* Interrupt sharing is avoided (no "fixed" number like with interrupt signal lines)
* No acknowledgement, therefore faster