min_frame_length for iso_tp_frames

[CanCanRep]

some OEMs are defining their ISO-TP CAN-Frames with some kind of a "minimum length". That means If you are on a CAN-FD Bus and you are sending data which is <=6 bytes, the CAN-FD-Frame will always be of a length of 8 bytes. Even if you are just sending a simple 2 byte data, the can-stack will pad the missing bytes up to 8. If you want to send data on the same connections with data >=8 it will t use the appropriate frame length on an CAN-FD-Frame up to 64.

I can´t find such an setting inside that lib. I´m not even sure if this has to be inside ISO-TP or rather inside python-can.

I could only found 2 options which do not lead to the descibed behavior

1. tx_padding not None & tx_data_length = 64 --> This will always pad up to 64
2. tx_padding is None & tx_data_length = 64 --> This will send frames < 8 DLC in case of small data

If anyone has an idea how to solve that issues it would be great, otherwise I could help to integrate such a feature if wanted.

Thanks

[hartkopp]

The kernel implementation supports TX_PADDING and also is able to check the received PDUs if they were padded correctly. Do you refer to this functionality?

[CanCanRep]

Thank you for the fast response. In the Kernel it is used as I was describing it. If I´m using -L option and set the padding to 64 , the CANFD-Frame will always be of a length of 8 byte if the data is < 2 byte.

using this command with tx_dl 64
echo 3e 00 | isotpsend -s 0b1 -d 0b0 vcan0 -L 72:64:0 -p 0x00
the kernel generates this output:
vcan0 0B1 [08] 02 3E 00 00 00 00 00 00
using the same command while sending data >8 byte
echo 3e 00 aa aa aa aa aa aa | isotpsend -s 0b1 -d 0b0 vcan0 -L 72:64:0 -p 0x00
this is the output:
vcan0 0B1 [12] 00 08 3E 00 AA AA AA AA AA AA 00 00

In comparison to the python-can-isotp package:
I´ve used this params:

can_fd: True
tx_padding: 0x00
tx_data_length: 64 

and the output is always padded up to 64 byte.

vcan0 0B0 [64] 02 3E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....

The Problem with this setting is that the ECUs will drop this messages if the iso-tp data is only 2 bytes while the can-fd frame is 64.

I´m not sure where this behaviour is specified. Maybe in the specification of ISO-TP for CAN-FD?

[pylessard]

Hi sorry for the late answer,
I can look into fixing this soon. Do you have any reference in the standard that describe this behaviour?
If we don't, I'll make sure to add options supporting every cases.

Thank you

[CanCanRep]

I just had a look into the specification. It´s not 100% clear but I think padding a CAN-FD frame up to 64 byte if the data is < 48 - PCI bytes is not allowed. Instead it should always just use the appropriate CAN-FD frame length

From the Spec ISO 15765-2 Third Edition 2016-04-01:

10.4.2.3 Mandatory padding of CAN FD frames (TX_DL > 8)
... For DLC values from 9 to 15, only the mandatory padding shall be
used. ...

[CanCanRep]

This would mean even if you have a padding of 64 byte, the iso-tp layer should decide on which can dlc to use. But a minimum of 8 byte. Do you have access to that specification ?

[hartkopp]

AFAIK the padding is used to fill up the "uninitialized" / "unneeded" bytes that are generated by the non-linear length steps introduced by the DLCs in the CAN FD case.
E.g. when you have 26 bytes to be transferred the DLC 0xd is needed which has space for 32 bytes - where the last 6 bytes are to be padded.
And for padding the minimum frame length is at least 8 bytes.

[pylessard]

After reviewing the standard I understand there is 2 scenarios of padding:

1. When TX_DL = 8, all frames should be padded up to 8 bytes. Seems to be inheritance from before CAN FD support
2. When TX_DL > 8, therefore CAN FD frames, unused bytes shall be padded.

I agree that the current behaviour of the Python module is not adequate. I think the addition of a tx_min_data_length parameter is relevant. I will proceed with the implementation shortly

[pylessard]

@CanCanRep : I pushed a fix. The stack now support a new parameter tx_data_min_length.
Can you validate that the behaviour seems correct to you?

Thanks

[CanCanRep]

@pylessard: sorry for the delay. I just checked the implementation and it works as specified and expected. Good work. The issue can be closed now.

[pylessard]

Fixed in v1.6
Thanks