Spamming Address Claimed message when using SocketCAN on the built in CAN on a RockChip RK3588S based SBC

[CRalliNA]

Describe the bug Hi, I've been following the getting started tutorial on my RockChip RK3588S based SBC, attempting to use the built in CANBUS with SocketCAN. However, on the address claim it spams the Address Claimed (0xEE00) message onto the bus flat out as fast as it can (seems to be about 200Hz).

I have just tested it with my PEAK USB CAN tool with the same code and it does not happen. I also can't seem to make it happen using any other basic code in C++ or Python using the built in CAN. I have also sent other messages from the ISOAgStack using the faulty CAN and it only sends them once.

Please could you point me in the right direction of why this could happen.

Supporting Documentation

Candump log file here: candump-2024-07-19_163510.zip

Environment (please complete the following information):

• OS: Ubuntu 20.04
• Compiler: GCC 9.4.0
• CAN Driver: Socket CAN

Additional context Add any other context about the problem here that you think might help us recreate or otherwise address your issue if applicable.

[ad3154]

Usually this symptom means that the CAN stack thinks that the message was not actually sent on the bus, so it re-queues it and sends it again later, which results in this loop where it looks like it's being spammed...

It could mean that this function is returning false for some reason, which would be interesting. Can you specify which specific SBC it is?

If you have access to a debugger, it could be helpful to know if write is returning something <= 0, and in that case, what errno is

[CRalliNA]

Hi Adrian, Thanks for the help.

I am using this SBC https://en.t-firefly.com/product/industry/aio3588sjd4 (Actually an SoM with a carrier board but basically an SBC).

I added some prints to debug the SocketCANInterface::write_frame function and the write function always returns > 0.

I then dug through the code following the function calls, testing the different between the built in CAN and the PCAN and got back to the InternalControlFunction::process_rx_message_for_address_violation function. I printed out the received messages in CANNetworkManager::process_rx_messages and it turns out the SocketCAN thinks it is receiving the messages it has sent, which I assume then makes it reattempt the address claim and causes a spiral into a positive feedback loop. This would also explain why it is only this message that is affected.

Have you come across this before? Do you think there's a setting I need to configure in the built in CAN handler?

Thank you again for the help,

Charlie

[ad3154]

Oh, interesting, that makes sense... yeah the CAN stack does not expect to receive its own messages.

We do attempt to avoid this by setting the socket option to receive our own messages to 0 here but one thing you could try is just disabling local loopback all together to see if that helps. Try adding this line below the one I referenced above:

setsockopt(fileDescriptor, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &RECEIVE_OWN_MESSAGES, sizeof(RECEIVE_OWN_MESSAGES));

I haven't seen this happen before, but that could help.