DRA821U-Q1: send or receive CAN FD frames in linux with ack error

Hi,

CAN-FD can send in multiples of 64 bits while traditional CAN can send in multiples of 8 bits. Instead of "cansend main_mcan0 143##1AAAAAAAAA", could you try "cansend main_mcan0 143##1AAAAAAAA" where there is one less A?

Regards,

Takuma

Thanks for your reply. Yes, it's my fault forgot to check the command from the document. I re-check it and found it can send fd messages OK, but can't receive fd message from outside. And the sender of the fd device outside works fine with canoe. And the current error message like:

Protocol error in Arbitration fail
Data phase error detected

Hi,

From the error message, I suspect the issue is related to arbitration. Perhaps the arbitration bitrate (set by "bitrate" argument in the command) is not the same as the arbitration bitrate of the sender?

As an experiment, if there are multiple CAN ports on your board, then you could do a loopback and set up two CAN ports using exact same arguments, but one would send and other receive.

Regards,

Takuma

I am sorry to take a response so late from the Spring Festival holiday. Yes, there are more then one can port on our boards. I link the two can ports directly, they all work fine for sending and receiving, but can't work in the network with others. For example,  there are two other can fd nodes: Node 1: STM32 F103, Node 2: RPI4 with  MCP2518FD. Our board and rpi start up canfd with the same command(in my older post), the same can fd message sent by STM32 can be received OK for RPI4, but ours could not. And further more, there are some more information for the issue:

1. if our boards run as std can mode, it works fine

2. if our board run as fd mode, and the STM32 board keep sending fd frame without stop:

    1) our board reports errors for stuff error, but can receive one frame in a long period, in several tens seconds or several hundreds seconds

   2) if cut our board's link off, our board can receive some fd frame sames OK and then enter 1) scene when I reconnect our board's link to the network.

 this issue can be reproduced always.

Hi,

Understood. Currently I'm on business travel, so I cannot test out on a board. I will be back next week to experiment.

In the meantime, could you share what bit rate is set for standard can mode, and data bit rate + arbitration bit rate for can fd mode during your experiments?

Regards,

Takuma

I use command:

ip link set main_mcan0 up type can bitrate 500000 dbitrate 2000000 restart-ms 1000 berr-reporting on fd on

for both our board and the rpi(which use can0 instead). So, the data bit rate should be 2000000 and the arbitration bit rate should be 500000

Hi,

Could you also share the bit rate set for standard CAN mode, not using CAN-FD?

Why I ask, is that there is an experiment I would like for you to try. The experiment is setting bitrate the same as dbitrate, and setting these at the same rate as whatever rate you are using for standard CAN mode.

For example, if you are using the following bitrate for standard CAN mode:

• ip link set main_mcan0 type can bitrate 500000

Then for CAN-FD mode, try setting to:

• ip link set main_mcan0 up type can bitrate 500000 dbitrate 500000 restart-ms 1000 berr-reporting on fd on

These two should functionally be the same.

But in any case, I would like to know what you are testing for standard CAN mode.

Regards,

Takuma

I test the fd mode with command "ip link set main_mcan0 up type can bitrate 500000 dbitrate 500000 restart-ms 1000 berr-reporting on fd on" for our board and configure the other two fd node with the sample params, then all three nodes can communicate each other successfully.

It seems our boards can't receive messages normally rather than 500000 dbirate

From your suggestion, I tested most bitrates above, and found only rpi can work fine with our board, so, I start to doubt the STM32 sender and the spi receiver, and found the problem was the sample-point did not match as its user manual, it's 0.75, but our board and rpi4 with a default sample-point 0.875. So, I changed our board's sample-point to 0.75, then the three nodes all can work fine.

Although there is still a strange point, that is, rpi4 can work with devices with  sampling point 0.75 at a default sampling point of 0.875, but our board can't.