Instable connection when moving from PCI Express to PCI Express FD

[felixwidmaier]

Hello,

we have successfully been using the PCAN-PCI Express Dual Channel cards (IPEH-003027) for a few years now to control some motor control boards which support CAN 2.0B.
I recently tested the same setup with a PCAN-PCI Express FD Four Channel card (IPEH-004040). The motor board does not support CAN FD but from what I understood it should be backward-compatible, so I was expecting it to work in the same way as with the old card.
However, while I am able to connect to the board and control the motors, the connection is much less reliable, resulting in instable motor control.
I monitored the timing of message that is sent by the board at a fixed rate of 1 kHz using `candump`. While with the old card the timing is pretty stable (mean error around 0.02 ms), there are significant delays when using the new one (mean error of 0.3 ms).

Unfortunately, I am not really an expert in CAN. Is the FD card expected to work out of the box on a CAN 2.0B bus or do I need to adjust some configuration?
The only configuration we are doing at the moment is the following:

Code: Select all

ip link set can0 type can bitrate 1000000

Some background info: We are working on Linux with a PREEMPT_RT-patched kernel and are using the standard drivers that are included in the kernel. I tried with kernel versions 4.14.59 and 5.6.19, both showed the same behaviour.
I also tried building the latest version of the proprietary driver with netdev support but the result was the same.

Any advice on how to fix or at least further debug this issue would be much appreciated.

[M.Heidemann]

Hello,

Thank you for your email.

The PCAN-PCIe FD card is backwards compatible, however it uses a different CAN core and uses
different clock frequencies, this needs to be taken into account.

Please test the following as a first step:

Do similiar issues occur, if you communicate between both your PCAN-PCI and PCAN-PCIe FD card (for example using cangen and candump) using the same bitrate?

Have you checked your physical setup?

Is the termination correct? You should measure 60 Ohms between CAN-High and CAN-Low in an unpowered state.



Furthermore, do you know at which sample point your motor control boards operate @1Mbit/s?
Also can you tell us which exact bitrate-timing setting is used on the boards?

Please report back to us regarding this.

Best Regards

Marvin

[felixwidmaier]

Hello Marvin,

Thanks for the fast response! It took a bit but we did some checks and tests
now:

1. Communication between cards:

I tested directly connecting two ports of the same card (both with the old and
the new one) and connecting the old with the new one. In each case I sent some
messages on one interface using

Code: Select all

    cangen canX -g 1 -n 20

and measured the timing on the other with

Code: Select all

    candump -t -d canY

The timing of the received messages hat some variance but I assume `cangen` is
not running in hard real time, so that might be okay. In any case, the delays I
observed here were comparable in all three cases, i.e. I did not see a
difference in behaviour of the old and new card.


2. Physical Setup

We noticed two things: There was no termination on the PC-side, only on the
motor control board. Further, we did not connect the ground pin of the CAN
connector. Both is fixed now, but it did not solve the problem.


3. Timing Settings

I was completely new to CAN when I set this up back then, so it might well be
that something is not optimal here. From what I found in the configuration:

Baud Rate Prescaler: 3
Seg 1: 12
Seg 2: 2
Synchronization jump width: 2

So I think the sampling point should be at 86.7%.

If I understand it correctly, the CAN module on the board is running at 45 Mhz.

Please let me know in case some relevant value is missing here.


Best regards,
Felix

[M.Heidemann]

Hello,

With socketcan you can specify the used sample point specficially, when bringing the device up:

Code: Select all

ip link set can0 type can bitrate 1000000 sample-point 0.867

Does this resolve your issue?

Please report back to us regarding this

Best Regards

Marvin

[felixwidmaier]

I tried this now but it did not solve the issue.

Another thing I observed as I did more tests: I cannot start the motor board every time. Sometimes it works (apart from the delays) but sometimes the connection seems to stop (candump stops showing new messages) shortly after initialising the board (after initialisation the board starts to send more data, maybe this is somehow causing it?). Is there any tool I can use to debug what might be the reason for the communication stop in such a situation?

[M.Heidemann]

Hello,

you could use:

Code: Select all

candump canX -e

to log error-frames and see which kind of errors are possibly showing up
druing communication.

Furthermore, do you have any kind of documentation on the controller-board
which gives an definitive answer as to which bitrate-configuration is used?
This would be beneficial in setting the correct bitrate-timing needed.

Best Regards

Marvin

[felixwidmaier]

I am sorry for not having responded anymore. I was busy with an other project and only now have time to look into this again.

Unfortunately `candump -e` does not show any error. It looks like there are just no new messages anymore at some point.

I'm afraid I cannot give a definitive answer regarding the bitrate configuration but maybe the following helps:
The boards we are using for motor control are Texas Instruments LaunchPads (LAUNCHXL-F28069M). The documentation of its CAN module is here (Chapter 16, more specifically 16.10 for the bit timing configuration).
The CPU clock frequency of the F28069M is 90 MHz. In our firmware we set

Code: Select all

BRPREG = 2;
TSEG1REG = 11;
TSEG2REG = 1;
SJWREG = 1;
SAM = 1;

which, if I understood everything correctly, should result in the settings I posted previously (for some reason the values of the registers BRPREG, TSEG1REG, TSEG2REG and SJWREG are increased by 1 when the CAN module accesses them).

I can try to check the communication with a Logic Analyzer, maybe this gives some helpful insight.

[M.Heidemann]

Hello Felix,

No problem.

Please check with texas Instruments which predefined bitrates are available, as this will simplify things quite alot.

At 90Mhz not every config will work as intended, or will be valid.

Are there any clear examples, where both bitrate and SP are given?

Please report back to us regarding this.

best Regards

Marvin

[felixwidmaier]

Unfortunately I couldn't find explicit examples for this board. However, I did find a calculator for the timing parameters by TI (previously I used a calculator by some third party).
It indeed gives me different parameters compared to what I used before:

Code: Select all

BRP  	3
Tseg1 	9
Tseg2 	5
Bit rate 	1000
SJW 	4
SAM 	0
Sampling Point 66.7%

I was able to control the motor with these settings, however, I am observing the same delays as before, so it doesn't seem to make a notable difference.

Since the sampling point is quite different to what I had before, I am wondering, is there some rule of thumb regarding what value is desired?

In the calculator, there is an input parameter "Extra propagation delay" to compensate for delays caused by the transceiver. I kept it at the default value (0.1 µs) for now as I'm not sure about this. Is there some information regarding delays caused by the PCAN card?

I'll also try to do some more research and will also check the actual signals on the bus via logic analyser, which I did not yet have the time for. I'll let you know if I find anything new.

[M.Heidemann]

Hello,

As the original issue still exists:

How do you actually determine the delays?

You were unable to see any errorframe with candump so i would assume, that the bitrate
is not the cause for this.

How do you send the frames to your control-boards?

Can you give us a comparison between both the old and new card (candump?)

Best regards

Marvin