CAN-FD Message Truncation Issue When Sending More Than 8 Bytes

[PMCSilva]

Describe the bug

When attempting to send a CAN-FD message with a payload larger than 8 bytes using 'slcan' bustype connected to a CANABLE device, the message appears to be truncated or not sent at all, despite setting is_fd=True in the can.Message object and fd=True in the can.interface.Bus initialization. Messages with 8 bytes or less are sent and received correctly.

To Reproduce

1. Initialize a CAN interface with CAN-FD enabled.
2. Create a CAN-FD message with more than 8 bytes of data.
3. Send the message over the CAN bus.
4. Observe that the message is not sent correctly or is truncated.

Expected behavior

The CAN-FD message with more than 8 bytes should be sent and received correctly, as per the CAN-FD specifications.

Additional context

OS and version: Windows 11 Pro 22H2 Python version: 3.11.3 python-can version: 4.3.0 python-can interface/s (if applicable): slcan

Code Snippet

import can

# Initialize CAN interface with CAN-FD enabled
can_bus = can.interface.Bus(channel='COM16', bustype='slcan', bitrate=500000, fd=True)

# Create a CAN-FD message with more than 8 bytes of data
data = bytes.fromhex("0102000000AAAAAAA000000A")  # Example data with more than 8 bytes
message = can.Message(arbitration_id=0x100, is_extended_id=False, data=data, is_fd=True)

# Send the message
try:
    can_bus.send(message)
    print("Message sent")
except can.CanError as e:
    print(f"Error sending CAN message: {e}")

Additional Information: Successfully tested sending the same CAN-FD message using the Cangaroo application, where it was received correctly. This suggests that the issue may be specific to the 'python-can' library or its interaction with slcan and the CANABLE device.

[zariiii9003]

The python-can slcan does not support CAN-FD

[hartkopp]

Hi @PMCSilva ,

the slcan protocol officially does not support CAN FD but only Classical CAN.

Your referenced CANABLE app obviously uses some proprietary extension with extra frame types b,B,d,D See https://github.com/normaldotcom/cangaroo/blob/master/src/driver/SLCANDriver/SLCANInterface.cpp#L350

A similar suggestion was made here: https://www.mikrocontroller.net/topic/501223

So an approach could be to implement the new CAN FD frame types b,B,d,D either in https://github.com/hardbyte/python-can/blob/main/can/interfaces/slcan.py#L208 and maybe also inside the Linux kernel https://github.com/torvalds/linux/blob/master/drivers/net/can/slcan/slcan-core.c#L185

Unfortunately the CANABLE CAN FD bitrate configuration looks somewhat broken in comparison to the suggestion on microcontroller.net. But we might start with the CAN (FD) frame encapsulation only - and leave the CAN FD bitrate configuration for a later stage.

@zariiii9003 : What do you think about this idea?

[zariiii9003]

@hartkopp i'd say, python-can will follow whatever the linux-kernel implements (prototyping in python-can is probably easier though). But does it make sense to implement CAN FD frames without the bitrate configuration? That doesn't seem very useful.

[hartkopp]

I have mixed feelings about the CAN FD support especially due to the CAN FD data bitrates. When you would use 4Mbit/s data bitrate the ASCII hex data stream from slcan has to be even faster. I'm not sure about the USB/slcan link speed and whether the Cangaroo application can really provide full load CAN FD traffic?!?

And the fact that there is no agreed common CAN FD bitrate configuration definition so far makes it even harder.

IMHO it would make more sense to flash the CANABLE hardware ( https://github.com/makerbase-mks/CANable-MKS ???) with https://github.com/candle-usb/candleLight_fw firmware - but I'm not sure whether CAN FD is already supported for the CANABLE CAN FD hardware.

Maybe @marckleinebudde can tell us more about the CAN FD status of the CANABLE hardware.

[marckleinebudde]

I have work in progress branch of the candlelight firmware, that supports CAN-FD. Some patches of that branch are already mainline, but most of them are still in review. It's tracked in this PR.

The candlelight firmware doesn't support STM32G431 yet, but there is already integration for the m_can CAN IP core.

[hartkopp]

Thanks for the update! Interesting that STM is using the M_CAN IP core in these SoCs too.

Do you have an opinion about supporting the CAN FD frame types (see above) without the bitrate setting in the slcan driver?

[marckleinebudde]

Feel free to send patches against the slcan driver. I don't mind taking them (after finishing my backlog CAN maintainer work).

I personally don't have any interest in the slcan protocol, I'd rather focus on bringing the candlelight firmware/driver forward.

[hamlinzheng]

Are there any updates here? As the proposer mentioned, it is not possible to send messages longer than 8 bytes using python-can with CANable2 hardware, and even emulating it as socketcan using the slcand command does not work with CANFD.

[marckleinebudde]

No change on the kernel side. I'm willing to review and merges patches, but not write them.