FDCAN H7 BRS failure with Kvaser Leaf 3

[LCE]

Heyho,

after some *** CAN beginner mistakes on my side, I got the FDCAN BRS 8 Mbit working.

Or so I thought. It's only working between my custom boards, as I found out after connecting a Kvaser Leaf v3.

With the Kvaser (directly connected to the board's D-sub, termination on, signals on the scope look good (enough)) and BRS on, it only works with max 2 Mbit, and only if the Kvaser's bit timing is set below 70% sampling point.

So far I played with changes to TDC, sampling point, SJW, and all bit timings (checked the Kvaser timing website).

Any ideas welcome!

[mƎALLEm]

So it's a "Kvaser" issue as FDCAN BRS 8 Mbit is working between your custom boards.

Did you remove the terminating resistor inside that Kvaser device? you need only two terminating resistors on the CAN lines.

[LCE]

Thanks for the quick answer!

I only have the Kvaser connected to one of my boards.
The termination resistor is switchable on my boards (with an isolated low capacitance opto relay).

 

[mƎALLEm]

Do you confirm FDCAN is working well between the boards without that kvaser device?

[LCE]

> Do you confirm FDCAN is working well between the boards without that kvaser device?

Yes, at all bit rates.

Scope confirms bit timings.

I thought that the Kvaser stuff - coming from the market leader (I think) - is the impeccable reference.

So maybe I got something wrong?

Here's the CAN register settings for 8M (hex):

(for the segment times below the complete register, e.g. DTSEG1, the "+1" is already included)

FDCAN 1->
Clock = 80.000 MHz - PLL 1 Q
CREL = 32141218
ENDN = 87654321
DBTP = 00800521
 TDC = 1
 DBRP = 1
 DTSEG1 = 6
 DTSEG2 = 3
 DSJW = 2
NBTP = 24008A13
 NBRP = 1
 NTSEG1 = 139
 NTSEG2 = 20
 NSJW = 19
TEST = 00000080
RWD = 00000000
CCCR = 00004300
 INIT = 0
 CCE = 0
 ASM = 0
 CSA = 0
 CSR = 0
 MON = 0
 DAR = 0
 TEST = 0
 FDOE = 1
 BRSE = 1
 PXHD = 0
 EFBI = 0
 TXP = 1
 NISO = 0
TSCC = 00000001
TSCV = 0000BA51
TOCC = 0000FFFF
TOCV = 0000FFFF
ECR = 00000000
PSR = 0000070F
GFC = 00000007

 

[mƎALLEm]

---

@LCE wrote:

> Do you confirm FDCAN is working well between the boards without that kvaser device?

Yes, at all bit rates.

---

So that's not a STM32 issue, that's "kvaser" related one which I cannot help you on that.

Check again your kvaser device config, your wiring etc ..

[mƎALLEm]

A question: What is the clock source of PLL1Q? HSE?

Are you using a crystal?

If not, please use HSE as source clock for PLL1Q and use crystal (XTAL) or crystal oscillator (XO).

[LCE]

HSE, ultra stable 10 ppm crystal

PTP running on that successfully, lots of timing relevant stuff in that application.

[mƎALLEm]

According to "Kvaser Leaf v3" specification, it can reach up to 8Mbit/s

So it should work.

Still not clear about the terminating resistor inside that device. Ensure that -if available- the internal terminating resistor on that kvaser device is disconnected.

What about the configuration of the tool: the bitrate the mode.. etc ?

Or raise a support ticket to kvaser over this link: https://kvaser.com/support/

[LCE]

> terminating resistor inside that device

I don't want to fiddle with the Kvaser hardware.
And as I said: there's a switchable terminating resistor on my board, and when that one is turned off, not even non-BRS is working.

[LCE]

@mƎALLEm  I just checked the Kvaser manual, the Leaf v3 does not have terminating resistor.

So I'll add another one...

[mƎALLEm]

---

@LCE wrote:

@mƎALLEm  I just checked the Kvaser manual, the Leaf v3 does not have terminating resistor.

So I'll add another one...

---

If you have already two terminating resistors of 120ohm on the bus you shouldn't.

[LCE]

I only had the Kvaser and my device on the bus, so only one R.

With 2 Rs still the same.

I'll contact Kvaser, thanks for the link!

[LCE]

Problem solved, Kvaser replied, saying that definitely 2 terminating resistors are needed on the bus, and:

 

When using CAN FD it is extremely important that ALL nodes on the CAN bus use exactly the same settings.

---

That was it, I didn't know that. I thought the sampling point might be something device / interface / endpoint specific.

Luckily I made all bus parameters editable (via http PUT), so when setting the sampling point to exactly the Leaf's settings, it works.

Thanks to @mƎALLEm and to Kvaser for the quick replies! :)

 

Edit:

Interestingly, the settings must be the same not only for the BRS data phase, but also for the arbitration phase.
Without BRS it didn't really matter where each side's sampling point was.

[mƎALLEm]

Thank you @LCE  for coming back with this.

But still not understand why the sample point should be the same. Each node is seeing the bit not the sample point on the bus ! Even if it works for you I'm still not totally convinced ;).

In this github example CKB-STM32-FDCAN-8Mbs , I used 6 nodes communicating at 8Mb/s, each node has its own sample point position and all nodes are working well on the same bus!

Anyway, this is something that needs to be explained..

[LCE]

Kvaser wrote:

On regular CAN CC (Classic CAN), the SP is important, but you can mix it a bit on the BUS, because it is only the interface LISTENING that uses this number.

But on CAN FD, the change of speed, is done in the SP. The SP is a mathematical defined point, and you can not observe it on a oscilloscope.

With that said, it is important that the SENDER and the RECEIVERS switches speed at the same time, otherwise they will be out of sync.

Even if you not have the same SP everywhere, the CAN bus is forgiving and will try to help you to fix the problem. It will re-synchronize as good as possible, but sometimes they get our of sync and you will get errors.

But if you instead uses EXACTLY the same parameter on all nodes, then the “resync mechanism” will be used for adjusting from sporadic errors and noise, and will save you from non wanted events. It will give you a safe CAN bus.

What if it not is possible to use the same settings?

Biggest problem is a mix of clock frequencies on the different nodes. If you have nodes that uses 40 or 80 MHz clocks, then it easy to find common parameters. But if you also have nodes with 30 or 60MHz, then it can be more problematic to find common settings.

---

@mƎALLEm