CAN-FD transport MAX_DLC_REQUIRED

[danielhrisca]

I think that the way MAX_DLC_REQUIRED is handled for CAN-FD should be revised.

In the current implementation this is automatically set to True for CAN-FD (see

pyxcp/pyxcp/transport/can.py

Line 316 in 60a38cb

self.max_dlc_required = self.config.get("MAX_DLC_REQUIRED") or self.canInterface.is_fd

)

SRS_Can_01160 does not state that a maximum frame length must be used, it only talks about padding the frame up to the next CAN-FD DLC value, which is also correctly implemented in the pad_frame function (

pyxcp/pyxcp/transport/can.py

Line 78 in 60a38cb

def padFrame(frame: bytes, padding_value: int, padding_len: int = 0) -> bytes:

)

SWS_Can_00502] ⌈ If PduInfo->SduLength does not match possible DLC values 
CanDrv shall use the next higher valid DLC for transmission with initialization of 
unused bytes to the value of the corresponding CanFdPaddingValue (see 
ECUC_Can_00485).⌋ ( SRS_Can_01160)

On the other hand the XCP on CAN specification only talks about MAX_DLC_REQUIRED which would then result in 8 or 64 bytes frames.

[christoph2]

Yes, FD-frame padding is only required if SduLength does not exactly matches a discrete DLC value.
The fix will be included in the next big release.

[danielhrisca]

And only for autosar

[Funth0mas]

(disclaimer: I don't know XCP-over-CAN specification) The Autosar implementation from EB seem to require minimal DLC=8 on CANfd. It ignores shorter frames. C'est la vie...

[christoph2]

The FD padding behavior is fixed in the (hopefully soon) coming release.