I would like to know which occurs first while using CAN communication. Based on the answer I would conclude whether an acceptance filter must be used in my project or not.

Scenario: There are three nodes in my project (for example, node A, B, and C). All have unique IDs. All nodes have been configured to interrupt on receiving a message. As of now, an acceptance filter is not configured for the nodes.

When node A sends a message to node B via CAN, both node B and C will trigger an Rx interrupt. In the ISR, I'll filter out the message based on ID in software. Suppose acceptance filters are configured for all the nodes, when node A again sends to node B, will even node C's Rx interrupt trigger?

My question is: Will a receive interrupt be triggered only after a message passes through the acceptance filter or is it triggered when a message is received by the CAN hardware even if an acceptance filter has been configured?

Note: I'm using LPC1778 (if that matters).


2 Answers 2


First the ID is checked and only then the data is put in the RX Fifo. Since you get an interrupt only when there is something in the RX fifo the interrupt will not occur. In the datasheet it will also be mentioned on how the acceptance filter works and how the data is captured. I also had a look at my microcontroller (ZYNQ 7000) which has a can in it and it says the exact same thing I have mentioned above. And this will not differ from microcontroller to microcontroller as CAN is a protocol and is uniform everywhere.

In page 568 from the same reference manual that I have shared below, it explains the type of interrupts that are possible in CAN. For example there is RxFIFO Not Empty interrupt, RxFIFO overflow interrupt, RxFIFO underflow (error) interrupt and the Message Rx interrupt. so if these interrupts are enabled in the interrupt enable register (pg 810) and if these bits are set in the interrupt status register (pg 807) then it goes inside the interrupt handler. The main interrupt for your case is the message RX interrupt which is triggered whenever a message is received, so if you enable this interrupt(which is needed if you want an interrupt whenever something is received and put in the RX fifo) then if your acceptance filter is configured to a particular message ID then only when this particular ID is received the message is put in the RXFIFO thereby causing an interrupt. So if this ID is not received then the RX message recieved interrupt flag will not be set in the interrupt status register and therefore the receive interrupt will not be triggered.

  • \$\begingroup\$ Can you please share the reference of where in the ZYNQ 7000 datasheet it says that \$\endgroup\$
    – AlphaGoku
    Feb 18, 2016 at 12:33
  • \$\begingroup\$ xilinx.com/support/documentation/user_guides/… In page 570 'RX message filtering' \$\endgroup\$ Feb 18, 2016 at 12:40
  • \$\begingroup\$ I have read what you have suggested. Where does it say that interrupt is triggered only when data enters the RxFIFO and not when it arrives at the physical layer? Any references to this point would be greatly appreciated. Thanks \$\endgroup\$
    – AlphaGoku
    Feb 18, 2016 at 13:08
  • \$\begingroup\$ I have edited my answer including your interrupt related information have a look. \$\endgroup\$ Feb 18, 2016 at 14:53

First, nodes don't have IDs, only messages do.

Second, using filters and masks is always optional. Their intent is to reduce firmware load by not bothering the firmware with message that you know up front are not relevant to that device.

I have done a number of CAN implementations, and have yet to use filters and masks. I can see how they would be useful in highly targeted devices where low power is important. However, they make good software architecture difficult. The decision of what messages to ignore should not really be done in the low level packet reception layer. That should be done at higher levels that understand the protocol used above CAN, not the bare CAN protocol. So far in the CAN projects I've had, it's been more trouble to generalize the finite number of masks and filters to arbitrary message acceptance criteria than any benefit gained.

I have my low level CAN reception layer receive whole packets and make them available to the application layer. The application layer then decides what to do with them, which could be nothing. This decision of how to process particular messages is usually done via a dispatch table, so ignoring messages simply means not including table entries for them. This mechanism is there anyway. So far the little extra processing power that requires hasn't been worth the less maintainable architecture of discarding messages at the low level in hardware.

  • \$\begingroup\$ But if I use a dispatch table, i must ensure that i service the data in the RxFIFO before a new data arrives. To achieve this il have to increase my Clock speed or decrease baud rate. It does sometimes help that the hardware allows only useful packets to enter and reject packets not intended for me. Any links as to how to implement the approach you have suggested would be very useful for me. \$\endgroup\$
    – AlphaGoku
    Feb 18, 2016 at 13:05
  • \$\begingroup\$ @Aks: What you are saying is only true if the processor is utilized at the edge of its ability. In most cases, the extra processing power to inspect a packet and discard it is relatively small. Also, most CAN hardware has more than one receive buffer. Even if not, you have the low level CAN reception code copy the message from the hardware to a software buffer, which the application code then reads the message from. \$\endgroup\$ Feb 18, 2016 at 13:19
  • \$\begingroup\$ uC is operating at full ability with clock speed of 120MHz. CAN is operated at 1Mbps. There is a single receive buffer. But yes. I too am not a fan of AccFilter. Il try if it works with no AccFilter. If theres a frequent overflow error il use AccFilter and retry. In either way, does interrupt occur before or after the Acc filtering? \$\endgroup\$
    – AlphaGoku
    Feb 18, 2016 at 13:52
  • 1
    \$\begingroup\$ @Aks: Messages that are blocked by filters are discarded, so no interrupt generated. Doing otherwise would defeat part of the purpose of filtering. \$\endgroup\$ Feb 18, 2016 at 13:57
  • \$\begingroup\$ Some higher-level protocols do have the concept of node IDs. For instance, most, but not all, CAN messages for CANopen (11-bit message ID) are a 4-bit function code + a 7-bit node ID. An SDO request is function code 11 and e.g. may address a device at node ID 67. \$\endgroup\$ Jul 11, 2016 at 11:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.