Multi-frame transfer failure

nburkitt · April 16, 2021, 2:27am

Hi.

I’m having trouble with libcanard receiving multi-frame transfers of a specific size. The frames are being received, but libcanard isn’t reassembling them into a transfer.
I’m using “classic” CAN 2.0 B, with 8-byte frames. The data structure is 104 bytes long. At 7 “user” bytes per frame, that’s 14 frames, plus six bytes, which puts the second byte of the CRC alone in a 15th frame (see below). The receiver never produces a transfer, despite all frames being received.
If I increase the size of the structure by two bytes, to 106, libcanard then reassembles the frames and produces a transfer.
Is this expected behavior, or have I found some novel way to screw things up?
Thanks,

-Nick

tx payload:
80 81 82 83 84 85 86 87 00 01 02 03 04 05 06 07
08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17
18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
28 29 2a 2b 2c 2d 2e 2f 30 31 28 33 34 35 36 37
38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47
48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57
58 59 5a 5b 5c 5d 5e 5f

rx frames:
frame: id: 0x0464d301, payload_size: 8, 80 81 82 83 84 85 86 ab
frame: id: 0x0464d301, payload_size: 8, 87 00 01 02 03 04 05 0b
frame: id: 0x0464d301, payload_size: 8, 06 07 08 09 0a 0b 0c 2b
frame: id: 0x0464d301, payload_size: 8, 0d 0e 0f 10 11 12 13 0b
frame: id: 0x0464d301, payload_size: 8, 14 15 16 17 18 19 1a 2b
frame: id: 0x0464d301, payload_size: 8, 1b 1c 1d 1e 1f 20 21 0b
frame: id: 0x0464d301, payload_size: 8, 22 23 24 25 26 27 28 2b
frame: id: 0x0464d301, payload_size: 8, 29 2a 2b 2c 2d 2e 2f 0b
frame: id: 0x0464d301, payload_size: 8, 30 31 28 33 34 35 36 2b
frame: id: 0x0464d301, payload_size: 8, 37 38 39 3a 3b 3c 3d 0b
frame: id: 0x0464d301, payload_size: 8, 3e 3f 40 41 42 43 44 2b
frame: id: 0x0464d301, payload_size: 8, 45 46 47 48 49 4a 4b 0b
frame: id: 0x0464d301, payload_size: 8, 4c 4d 4e 4f 50 51 52 2b
frame: id: 0x0464d301, payload_size: 8, 53 54 55 56 57 58 59 0b
frame: id: 0x0464d301, payload_size: 8, 5a 5b 5c 5d 5e 5f 11 2b
frame: id: 0x0464d301, payload_size: 2, 3b 4b

pavel.kirienko · April 16, 2021, 12:44pm

This is not the expected behavior. Libcanard has this case covered by a dedicated test that purposely splits off the CRC:

github.com

UAVCAN/libcanard/blob/55938c51cf7da3096679933302693c9dae7a2b33/tests/test_private_rx.cpp#L585-L630


// CRC SPLIT -- first frame.
frame.timestamp_usec    = 30'000'000;
frame.transfer_id       = 0;
frame.start_of_transfer = true;
frame.end_of_transfer   = false;
frame.toggle            = true;
frame.payload_size      = 8;
frame.payload           = reinterpret_cast<const uint8_t*>("\x0E\x0E\x0E\x0E\x0E\x0E\x0E\xF7");
REQUIRE(0 == update(0, 1'000'000, 16));
REQUIRE(rxs.transfer_timestamp_usec == 30'000'000);
REQUIRE(rxs.payload_size == 8);
REQUIRE(0 == std::memcmp(rxs.payload, "\x0E\x0E\x0E\x0E\x0E\x0E\x0E\xF7", 8));
REQUIRE(rxs.calculated_crc == crc("\x0E\x0E\x0E\x0E\x0E\x0E\x0E\xF7"));
REQUIRE(rxs.transfer_id == 0);
REQUIRE(!rxs.toggle);
REQUIRE(rxs.redundant_transport_index == 0);
REQUIRE(ins.getAllocator().getNumAllocatedFragments() == 1);
REQUIRE(ins.getAllocator().getTotalAllocatedAmount() == 16);

// CRC SPLIT -- second (last) frame.

This file has been truncated. show original

Maybe the transfer is generated incorrectly. Who is the sender? To help you investigate, please prepare a reproducible MWE in C that I could run locally. Thanks!

nburkitt · April 16, 2021, 5:13pm

Hi Pavel.

Thanks for the reply. As is often the case, preparing an example exposed the real problem.
It turns out that the “DataBytesToDlc()” function in the library supplied with the Microchip MCP2518FD will not return a DLC value less than four. So, when I passed the two-byte final frame to libcanard, its payload_size was set to the incorrect value of four, and libcanard saw an invalid tail byte.
Fortunately it’s a trivial fix, but a strange decision on the part of the library’s author.
Thanks again,

-Nick

pavel.kirienko · April 16, 2021, 6:06pm

Not to pontificate but from my personal experience I can say that the software libraries and tools supplied by Microchip and STMicroelectronics are horrendous and absolutely unfit for use in production. There is simply no quality control whatsoever. Building a product based on their software is a recipe for disaster.

nburkitt · April 16, 2021, 7:11pm

Hi Pavel.
I’m not sure I’d limit membership in that club to just those two. But, to be fair, this Microchip CAN library is well organized and readable, and largely avoids unnecessary complexity. The coding is a bit clumsy, but by the same token its intent is obvious. It will not have been extensively tested, as evidenced by this and a previously discovered buffer overrun issue, but at least I have someone else to blame when something goes wrong.
Thanks again,
-Nick