Sending canfd, receiving non-canfd (if payload <= 8)

[lbeuster]

I'm sending canfd frames with payload-size <=8 with JavaCan. If I receive these frames with JavaCan in a different process the frames are recognized as canfd.
But CANoe marks these frames as non-FD frames (any probably the linux-can-tools too - see below).

If I use the linux-can-tools to send the canfd frame, then CANoe marks them as FD.

Frames sent by JavaCan with a payload size > 8 are correctly received as FD by JavaCan, candump and CANoe.

What I did:

# CAN 2.0 + cansend
cansend can0 123#00
Output candump: see "[1]" as length
  can0  123   [1]  00

# CanFD + cansend
cansend can0 123##000
Output candump: see "[01]" as length
  can0  123  [01]  00
Output JavaCan on receiver side: CanFDFrame(ID=123, FLAGS=4, LEN=1, DATA=[00])
CANoe: shows CanFD
-> everything's fine
-> seems like the can-tools use this special length format for canfd - but that's only a guess.

# CanFD + JavaCan
        val client = CanChannels.newRawChannel().apply {
            setOption(CanSocketOptions.FD_FRAMES, true)
            bind(NetworkDevice.lookup("can0"))
        }
        client.send(CanFrame.create(291, CanFrame.FD_FLAG_FD_FRAME, ByteArray(1))
Output candump: can0  123   [1]  00
Output JavaCan on receiver side: CanFDFrame(ID=123, FLAGS=4, LEN=1, DATA=[00])
Output CANoe: no CanFD

So I'm not quite sure where the problem is: something in JavaCan or in my mind? Any ideas?

Used version: 3.3.0/aarch64

[pschichtel]

Would you be able to provide a regression test reproducing this as a pull request? I should be able to have a look at this by next week

[lbeuster]

It's no regression test, just the code to reproduce this manually. See README in canfd-test directory.

#53

[pschichtel]

I cannot confirm that candump detects JavaCAN's FD frames as such. In the candump -L output below you see:

1. pair of lines: a non-FD frame with 8 bytes of data sent once with JavaCAN and once with cansend
2. pair of lines: an FD frame with 8 bytes of data sent once with JavaCAN and once with cansend
3. pair of lines: an FD frame with 11 bytes of data send once with JavaCAN and once with cansend

To me it seems that the FD flag is not being set properly.

(1702687478.648674) vcan0 7ED#0011111111111111
(1702687478.705444) vcan0 7ED#0011111111111111

(1702687484.148808) vcan0 7ED#0011111111111111
(1702687484.201471) vcan0 7ED##400111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

(1702687488.149807) vcan0 7ED##40011111111111111222222
(1702687488.201676) vcan0 7ED##400111111111111112222220000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[pschichtel]

Please test the latest snapshot (https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.3.1-SNAPSHOT/javacan-core-3.3.1-20231216.013458-4.jar)

[lbeuster]

Thanks, works now, verified with candump.

# canfd, sent with JavaCan
vcan0  123  [02]  00 00
# no canfd, sent with JavaCan
vcan0  123   [2]  00 00

[pschichtel]

great, I'll publish a release later today or tomorrow

[pschichtel]

https://github.com/pschichtel/JavaCAN/releases/tag/javacan-3.3.1

The jars might still need some time to propagate to maven central.

[lbeuster]

3.3.1 still not available at maven-central, maybe something went wrong?

[pschichtel]

Weird, I'll check that. I haven't upgraded my own project to. 3.3.1 yet, I'll check this and get back to you here

[pschichtel]

Apparently something get's messed up in maven's release plugin since my recent plugin updates.... more reasons to go for #45 ... 3.3.2 should eventually land in central. I'll check back later to see if it worked out.

[pschichtel]

the directory index in central is a little messed up, but the jar is available now

[lbeuster]

Thanks, 3.3.2 is available and works as expected. ...and thanks for "re-adding" the arch-auto-detect feature - if you use Java to access the CAN, you really don't care about program size ;)

[pschichtel]

the removal was never about program size, I removed it because it was (and still is) unfixably broken for some architectures. The new solution is a best effort, but it's now just one option instead of the only way.