christoph2
CAN-FD transport MAX_DLC_REQUIRED
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 https://github.com/christoph2/pyxcp/blob/60a38cbea0b1335d205d1655a4c594fcc424557b/pyxcp/transport/can.py#L316)
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 (https://github.com/christoph2/pyxcp/blob/60a38cbea0b1335d205d1655a4c594fcc424557b/pyxcp/transport/can.py#L78)
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.
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.
(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...
The FD padding behavior is fixed in the (hopefully soon) coming release.