Configure SocketCAN for FD

[raragon71]

Hello, I'm trying to use pyxcp to connect to CAN-FD XCP slave. I'm using a raspberry pi as master, using socketCAN. I pass the parameter FD = True in the configuration file but it does not make a difference. The board's CAN interface is up and running and configured for CAN-FD at 500kb bit-rate and 2000000 data bit-rate. I can see the CAN XCP frames (connect) coming out as a regular CAN frame, with 8 data bytes (I need CAN-FD and 64 data bytes). Am I missing any parameter in my configuration? Thanks /RA

[christoph2]

First of all, I'm glad you're using RasPI / SocketCAN like I do; in this case my infamous [xcpdump] (https://github.com/christoph2/xcpdump) may useful, it's just like the "official" candump but showing you XCP traffic in a readable form.

Note: command packets are basically max. 8 bytes (with the exception of WRITE_DAQ_MULTIPLE), what makes the difference are command response packets.

OK, given you're using xcpdump, the important thing to watch for is the CONNECT response, if maxCto isn't greater than 8, your ECU / simulator wasn't (obviously) compiled to support larger frames.

I suggest to use examples/xcphello.py as a starting point. If GET_ID resp. returns a value > 7 then the following UPLOAD will provoke an FD frame. Yes, set FD=True and you're done. Works for me, if I'm using my counterpart project BlueparorrtXCP on a (virtual) CAN connection.

You may also add the following lines (before x.disconnect()) :

x.setMta(0xcaffe)   # some readable address
x.fetch(0x120)        # arbitrary size

[raragon71]

Thanks for your prompt response and thanks for letting me know about your "xcpdump" project!! I can see how it will come in handy for my needs. It does make sense the use of 8 bytes, regular CAN frames for most of the commands, and switch to CAN-FD frames as needed on the slave response data, however, I'm not really sure what the ASAM/XCP specification says about mixing CAN/CAN-FD frames though... (I'm seeing CAN regular frames 8 data bytes (for connect) coming out from the master, not FD 8 data bytes as I said... perhaps the FD=True flag is not being propagated properly?)... anyways, unfortunately my ECU (Autosar based module), does filter out the regular CAN frames, so it seems that I need a 'pure' FD master because I'm not able to establish a connection. I will look deeper into your code (when I have a chance) to see what it takes to switch all the transmitting commands to FD... I'm guessing it shouldn't be that difficult, since I believe you are using python-can as underlying driver, Am I correct?

[christoph2]

Well, I think I've tracked down the issue, but it shows some interesting behavior of python-can (not sure if it is intended) : If one just passes fd = True to a interface constructor, python-can does "FD-on- demand", as it was observed by you.

What was missing: to do pure classic / FD networking, the is_fd parameter to Message() also has to be set (fixed by 28da1b2)

Please let me know if it really fixes the issue.

[raragon71]

Yes, it indeed fixes the issue. I can see now the connect command coming out as CAN-FD, with 8 data bytes. However, I'm not able to go further with my testing because I just found out that the Autosar CAN driver in my ECU is also dropping the XCP frames not matching max DLC... I think I inadvertently set this up in the Autosar configuration, and never noticed because we use CANape with fixed data bytes length equal to 64, so all commands are sent with max DLC. I'll try to change that setting in my ECU's code tomorrow, unless there is a way to force the commands DLC to 64 on pyxcp of course. Thanks for your support!!!

[christoph2]

OK, now pyxcp behaves like required by Autosar. Add the following to your config:

MAX_DLC_REQUIRED = true 
MAX_CAN_FD_DLC = 64
PADDING_VALUE = 0

Note: The last two values are defaults, so they are not really needed in this case. To see what's going on check out transport/can.py

P. S. : If you're using CANape, are you also using Microsar? P. P. S: While issues could be "abused " for interesting talks, why not start a discussion? Checkthis one.

[christoph2]

Wait a minute, I've published a draft by mistake, the changes are not yet pushed!

[raragon71]

Yes, I agree, let's keep the issues were they belong! BTW, I tried the settings you suggested in the configuration file and they didn't work, the frames keep being sent as 8 data bytes (CAN-FD though) [Perhaps a new issue?]… I'll switch to the discussion now!

[raragon71]

Just confirming that upgrading to 0.16.8 fixes the issue. I probably tested too soon.