Uavcan v0 found data transfer reversal

Applications & Usage LibCyphal
#1

img_v2_402a9248-7ad3-4103-9765-4bb9fa0dc13g
img_v2_402a9248-7ad3-4103-9765-4bb9fa0dc13g1080×343 257 KB

In this case we found that

data: 21 50 21 8d f8 05 10
data: 4f f0 03 02 14 bf 44

transfer reversal, then data decode error.
how can I process this case?
I think protocol stack need consider data order.

#2

Of course the protocol is aware of basic things like frame transmission ordering. Your case looks like a typical priority inversion problem. Please tell us how do you manage the transmission queue in your CAN driver? Can you share the code here?

Related: UAVCAN/CAN: tx buffer management in CAN (FD) controllers

#3

We use like this:

      clock_(std::make_shared<uavcan_linux::SystemClock>()),
      can_driver_(std::make_shared<uavcan_linux::SocketCanDriver>(*clock_)),
#4

What CAN controller are you using? Perhaps the inversion is happening within it. Try also to reduce the number of frames enqueued inside the socket from the default 2 to 1 (see max_frames_in_socket_tx_queue):

#5

mttcan:

https://docs.nvidia.com/drive/drive_os_5.1.6.1L/nvvib_docs/index.html#page/DRIVE_OS_Linux_SDK_Development_Guide/System%20Programming/sys_components_tegra_can.html

#6

I doubt there are issues in the M_CAN driver but then again, you never know.

You are dealing with an inner priority inversion problem. It is not really specific to UAVCAN. There are two things to try:

  • Reduce the number of enqueued frames to 1 as suggested above. The default should actually be updated in the sources; if you could submit a pull request that would be appreciated.

  • Inspect the sources of the M_CAN driver (which are rather massive) to see if the TX queue management is implemented correctly. Maybe reach out to the maintainers.

#7

Is that means make change

SocketCanIface(const SystemClock& clock, int socket_fd, int max_frames_in_socket_tx_queue = 1)

as a PR?

#8

Yes.

#9

Here：

1 Like