How to connect CN0401 node to ValueCAN 4-2 or Kvaser Leaf v3 for CAN FD packets sending and receiving?

Hello Mike,

   Have you reviewed the SW user guide?  https://wiki.analog.com/resources/eval/user-guides/eval-adicup3029/reference_designs/demo_cn0401

   This describes the configuration parameters and that they can be changed in the can_ctrl_get_config function contained within the can_obi_layer.c file.  I believe that these parameters are basically hard coded into the software and changing them requires a rebuild of the code.

Eric

Thank you Eric.

I've looked through, and don't think settings in the struct can_ctrl_init_param could help.

also tried to set some settings, e.g. set eid=1, sid11=1, in a send out header (tx_obj_header type struct), to enable extended sid, from the default CAN ID 0x300 to 0xB00, but Kvaser Leaf 3 side (based on canecho demo app) could not received any valid CAN packets, many packages were marked as 0 bytes and CAN ID are 0.

Hopefully anyone with the experience could help.

Thank you very much.

Update:

For whom may be interested, I would like to share my progress:

1. The other end CAN FD devices, ValueCAN 4-2, or Kvaser Leaf v3, should be set arbitration bitrate to 500k, data bitrate to 1000k, then CN0401 could transceive CAN FD packets up to 64 bytes;

2. For sending CAN FD packets with extended CAN ID, in the sending function, set the tx tx_obj_header_str->ide to 1, then the other attr eid will be taken as the lower 18 bits of the extended CAN ID, the higher 11 bits come from attr sid. For example: sid = 0x300, eid=0x12345, then the extended CAN ID will be 0xC012345;

There is still a minor concern while receiving:

The rx_sid_addr is set to 0x300 in default, but nowhere I can set to enable extended CAN ID for receiving. e.g. how to set it to receive CAN FD packets with a CAN ID 0xC012345?

Currently both incoming CAN FD packets with 0x300 or 0xC012345 can be received, seems there is no such a setting to specify standard CAN ID or extended CAN ID for receiving. I wonder if that is a feature, or I missed some settings somewhere.

Thank you very much for your time.

Mike

extra information:

While connecting to Kvaser Leaf v3, a windows app canecho could echo back CAN FD messages that sent from CN0401 (with extended CAN ID), but noticed that sometimes short message, e.g. "1", "abc", could not reach CN0401 side, but not always. If canecho initiated sending CAN 2.0A messages, then CN0401 received all.

With two CN0401 connected, then nothing wrong observed.

Wonder in the CN0401 demo code if the receiving mechanism needs some tricks to set up for receiving all kinds of messages ( CAN FD & CAN messages with or without extended CAN ID)

Hello Mike,

   The purpose of the CN0401 is only to demonstrate the ADM3055 in a minimal system and so the CN0401 software is a merely simple driver to the MCP2518 CAN Controller which is what is actually implementing the CAN functionality.   The CN0401 software implements enough functionality to meet this basic goal so that the performance of the ADM3055's PHY layer can be observed.

  You will likely need to consult Microchip's documentation for the MCP2518 and/or other open-source projects which use this part for guidance on how to augment the CN0401 software to utilize the additional functionality the MCP2518 offers.  Searching on the term "MCP2518 driver" will turn up many hits.

Eric

Hello Eric,

So far the CN0401's verified functionalities are good enough for our purpose.

We may need dig deeper for a specific project in future.

Thank you very much.

Mike