nuttx/can: in trunk support to Send message cancel mechanism. #17694

OceanfromXiaomi · 2025-12-26T12:21:32Z

add the logic about "cancel mechanism" of sending can/canfd message based priority list.

Summary

This PR is intended to resolve the CAN message priority inversion issue that can occur during CAN frame transmission.
It fundamentally addresses the problem of CAN message priority inversion, thereby avoiding communication latency or errors caused by priority inversion.

The solution manages CAN message transmission by introducing a cancel mechanism combined with a linked list, along with predefined cancel conditions (can_txneed_cancel), to control and reorder CAN frame transmission as needed.

Impact

If users want to use this scheme, they only need to enable CONFIG_CAN_TXCANCEL.
This scheme does not affect the build process, security, or compatibility.

A new dev_cancel interface is introduced, which is used to cancel the transmission of CAN messages that are already queued in the CAN driver’s hardware transmit buffer.

Testing

This scheme has been applied in an automotive basic-software project and has undergone long-term testing and validation; it does not break existing code.
The scheme also ran stably on development boards based on the Cortex-M7 architecture.

Test procedure:

Enable CONFIG_CAN_TXCANCEL.
Configure the CAN driver to use only one hardware transmit buffer.
Disconnect the CAN bus.
Using the cansend utility, first send a low-priority CAN message (ID 0x222). After confirming that this message has been placed into the hardware transmit buffer, send a high-priority CAN message (ID 0x111).
Reconnect the CAN bus.

Observed behavior:
the high-priority message (ID 0x111) appears on the bus first, followed by the low-priority message (ID 0x222).

xiaoxiang781216 · 2025-12-26T14:28:24Z

@OceanfromXiaomi fix:

../nuttx/tools/checkpatch.sh -c -u -m -g 4a069358b6cbd7acf377f1e32e359c480a5a9679..HEAD
❌ Missing git commit message
Used config files:
    1: .codespellrc
/home/runner/work/nuttx/nuttx/nuttx/drivers/can/can_sender.c:309: specfic ==> specific
Some checks failed. For contributing guidelines, see:

acassis · 2025-12-26T14:30:38Z

drivers/can/can.c

        }
    }

+#ifdef CONFIG_CAN_TXCANCEL


@OceanfromXiaomi please include some comments explaining the idea, it will help someone looking this code in the future

michallenc · 2025-12-26T19:30:20Z

include/nuttx/can/can.h


  CODE bool (*co_txempty)(FAR struct can_dev_s *dev);
+
+  CODE bool (*co_cancel)(FAR struct can_dev_s *dev,


I think this deserves some comment in the code. I suppose cancel should abort the msg that is passed as an argument, but should it also reorganize hardware buffers sending order if they are sent to the bus in FIFO order?

We do not use cancel ability if lower driver enable H/W FIFO to store msg.
I will add explaination in Kconfig file.

michallenc · 2025-12-26T19:39:23Z

drivers/can/Kconfig

+        depends on CAN_TXPRIORITY
+	---help---
+		Enabling this feature adds support for the can cancel ability.
+                this ability can cancel the msg with the largest msgID in the


Fix indentation

michallenc · 2025-12-26T19:41:28Z

drivers/can/can_sender.c

+  callbackmsg_node = list_last_entry(&cd_sender->tx_sending,
+                                     struct can_msg_node_s, list);
+  if (dev->cd_ops->co_cancel != NULL &&
+      dev_cancel(dev, &callbackmsg_node->msg))


Maybe add assert above the statement ensuring the lower half actually has dev_cancel to simplify subsequent debugging.

Or just return false as the lower half is not capable of aborting the frame. I think that's even better than assertion.

I will do these as follow:

DEBUGASSERT(dev->cd_ops->co_cancel != NULL) ... if (dev_cancel(dev, &callbackmsg_node->msg)) { ... return true; } return false;

michallenc · 2025-12-26T19:43:15Z

drivers/can/Kconfig

+config CAN_TXCANCEL
+	bool "Implement tx cancel ability"
+	default n
+        depends on CAN_TXPRIORITY


Do these have to be separate configuration options? I would say strict TX priority ordering is useless without the ability to abort the frame from hardware buffer.

CAN_TXCANCEL deponds on CAN_TXPRIORITY, because cancel ability will update pending list.

I will add explaination to explain cancel ability deponds on that the hardware buffer has ability of aborting frame.

michallenc · 2025-12-26T19:55:52Z

drivers/can/can.c

+#ifdef CONFIG_CAN_TXCANCEL
+  if (TX_PENDING(&dev->cd_sender) && can_txneed_cancel(&dev->cd_sender))
+    {
+      if (can_cancel_mbmsg(dev))


Shouldn't this be in a while loop? What if you need to cancel more messages? Let's say there are two CAN frames with IDs 1 and 2 already stored in HW buffers and you want to add CAN frame with ID 0. The current design, as I understand it, would have to abort both of these frames.

We just cancel the msg with the max id in sending list.
In the current design, when the hardware transmit buffer is full and there are frames in the pending list, the can_txneed_cancel function checks whether the ID of the first frame in the pending list is smaller than the minimum ID in the sending list. If this condition is met, the can_cancel_mbmsg function is invoked to attempt to cancel the transmission of the frame with the largest ID in the sending list, and this frame is then reinserted into the pending list at a specified position.

Afterwards, dev_send is called to load the first frame from the pending list into the hardware transmit buffer.

michallenc · 2025-12-26T20:08:53Z

drivers/can/can.c

    }

+#ifdef CONFIG_CAN_TXCANCEL
+  if (TX_PENDING(&dev->cd_sender) && can_txneed_cancel(&dev->cd_sender))


I don't think we need to cancel the messages unless hardware buffers are actually full, we just need to reorganize the order in which they are sent to the bus (not possible with all CAN controllers, but same can do it). If I am not mistaken, this approach could lead to the following scenario:

write CAN frame with ID 5 to first HW buffer

write CAN frame with ID 0, we check for abort

CAN frame with ID 5 is aborted and returned back to the software FIFO

CAN frame 0 is inserted to first HW buffer

CAN frame 5 is inserted to second HW buffer

The ideal scenario would be something like this

write CAN frame with ID 5 to first HW buffer

write CAN frame with ID 0 to second HW buffer

change the order of HW buffers so the HW buffer 2 is sent before HW buffer 1

We avoid a lot of list operations and unnecessary aborts. This becomes even more significant if more hardware buffers are used and you need to abort more frames. Yes, the implementation is more complicated and it passes some of the logic to the lower half, because dev_send has to check the priority of the newly added frame and correctly change the order in which the buffers are sent to the bus. Also the cancel has to be handled a bit differently, because now it's the lower half that decides what frame is returned back to the software FIFO.

I am not forcing the change here as this is a lot of work to do, just passing some thoughts and ideas about possible future enhancements. We used this approach in RTEMS CAN stack in my diploma thesis actually -> multiple priority queues, lower half reorganizes the sending order and returns the frame back to SW FIFO. This is something I'd like to see in NuttX in the future as well. It's probably a bit different from your needs, because you are doing strict CAN ID ordering. The problem with that is that some protocols need to keep the sending order even for different identifiers, that's where you need multiple priority classes... you filter ID ranges to these classes and then ensures the highest priority class is sent first, but the order within one class is still kept.

This change does not introduce excessive linked-list operations or unnecessary abort operations.

The reasons are as follows:

The prerequisite of this PR is the following loop:
while (TX_PENDING(&dev->cd_sender) && dev_txready(dev))

When this loop finishes, it means that either the hardware transmit buffer is full, there are no more frames in the pending list, or an error occurred during dev_send.

After that, the cancel condition is evaluated:

if (TX_PENDING(&dev->cd_sender) && can_txneed_cancel(&dev->cd_sender))

Only when there are still pending frames in the pending list and the can_txneed_cancel condition is satisfied will the cancel logic be executed.

Therefore, the cancel mechanism is triggered only when necessary, avoiding excessive list operations and unnecessary abort actions.

OceanfromXiaomi · 2026-01-04T09:01:40Z

@OceanfromXiaomi fix:

../nuttx/tools/checkpatch.sh -c -u -m -g 4a069358b6cbd7acf377f1e32e359c480a5a9679..HEAD
❌ Missing git commit message
Used config files:
    1: .codespellrc
/home/runner/work/nuttx/nuttx/nuttx/drivers/can/can_sender.c:309: specfic ==> specific
Some checks failed. For contributing guidelines, see:

Done

Introduce a priority-based CAN TX cancel mechanism to reorder pending frames and prevent priority inversion during message transmission. Signed-off-by: zhaohaiyang1 <zhaohaiyang1@xiaomi.com>

acassis

@OceanfromXiaomi please update the Documentation: https://nuttx.apache.org/docs/latest/components/drivers/character/can.html to include this new functionality

OceanfromXiaomi requested review from acassis, jerpelea, michallenc and simbit18 as code owners December 26, 2025 12:21

github-actions bot added Area: Drivers Drivers issues Size: M The size of the change in this PR is medium labels Dec 26, 2025

OceanfromXiaomi force-pushed the send_msg_cancel_logic branch from 2f1e894 to 180f5f9 Compare December 26, 2025 12:26

acassis requested changes Dec 26, 2025

View reviewed changes

michallenc requested changes Dec 26, 2025

View reviewed changes

OceanfromXiaomi force-pushed the send_msg_cancel_logic branch 3 times, most recently from 63c1bf3 to aef5984 Compare January 4, 2026 08:58

can: add TX cancel mechanism to avoid priority inversion

1c9a2d1

Introduce a priority-based CAN TX cancel mechanism to reorder pending frames and prevent priority inversion during message transmission. Signed-off-by: zhaohaiyang1 <zhaohaiyang1@xiaomi.com>

OceanfromXiaomi force-pushed the send_msg_cancel_logic branch from aef5984 to 1c9a2d1 Compare January 4, 2026 09:12

acassis requested changes Jan 4, 2026

View reviewed changes


		CODE bool (co_txempty)(FAR struct can_dev_s dev);

		CODE bool (co_cancel)(FAR struct can_dev_s dev,

nuttx/can: in trunk support to Send message cancel mechanism. #17694

Are you sure you want to change the base?

nuttx/can: in trunk support to Send message cancel mechanism. #17694

Conversation

OceanfromXiaomi commented Dec 26, 2025

Summary

Impact

Testing

Uh oh!

xiaoxiang781216 commented Dec 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OceanfromXiaomi Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OceanfromXiaomi commented Jan 4, 2026

Uh oh!

acassis left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

OceanfromXiaomi Jan 4, 2026 •

edited

Loading