CAN Frame ID for Jetson SPE TX

Hello,

I’m working on implementing the CAN bus from the TX2’s SPE to send a consistent message every second. I have the logic worked out and I am able to get a message sending consistently, but I am unable to set a new frame ID for the CAN message.

From the CAN-app demo code, the frame had the ID 0xA5. I used this until I found the proper ID we will be needed, which is 0x80.

However, when I try to send a message with the ID set to 0x80, the message never goes through and I run into an error. Is there a list of certain ID’s that I can use when sending messages? I looked through the code that is used to send the messages, but I have no been able to find anything that would explain this issue.

Thanks you!

hello ssb,

may I know what’s the failure you’d seen,
could you please gather them and share the details for reference,
thanks

Hi Jerry,

This is the frame sync that I am trying to send on the can bus:

struct mttcanfd_frame sync;
memset(&sync, 0, sizeof(sync));
sync.cmdid = MTTCAN_MSG_TX;
sync.payload.frame.can_id = 0x80;
sync.payload.frame.d_len = 0;
sync.payload.frame.flags = 0x0;

But, when I try to send this, I receive no messages on the other end using candump

However, when I set up the frame as follows:

struct mttcanfd_frame sync;
memset(&sync, 0, sizeof(sync));
sync.cmdid = MTTCAN_MSG_TX;
sync.payload.frame.can_id = 0xa5;
sync.payload.frame.d_len = 0;
sync.payload.frame.flags = 0x0;

I am able to receive the messages using candump

As for my setup, I have a PEAK PCAN USB adapter connected to CAN H/L and GND from the Jetson.

Please let me know if you need any more information, thanks!

hello ssb,

could you please test with cangen to specify can_id to test again?
for example, to send CAN messages,
$ cangen -L <Data_length> -I <CAN_ID> -D <Data_Bytes> DEVICE

wouldn’t I be using cangen to send messages to the SPE? I’m using the can_test_transmit function provided in can-app-tx-task.c

Hello ssb,

To filter out unknowns, can you start with linux kernel? I mean connect can 0 and can1 and do the loop back experiment with 0x80 ID from the linux kernel. This will take SPE out of the picture. That way we may know where is the problem.