This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2634: Issue receiving both standard and extended ID CAN messages

Part Number: AM2634

Tool/software:

Hello,

I'm performing a test on an AM36x SItara processor using a single CAN bus, aiming to receive both standard and extended ID can messages. However, I'm facing an issue where the reception behavior seems to depend on the order in which I add the filters. 

For example, when I add filters in the order < standard_id_0 , standard_id_1, extended_id_0, extended_id_1, standard_id_2 >, only messages with standard_id_1 and standard_id_2 are received.

On the other hand, when I add them in the order < extended_id_0, extended_id_1, standard_id_0, standard_id_1 >,  only messages with extended_id_0  are NOT received.

Could you clarify:

  • How does the filter order affect message reception?
  • Is there any recommended way to configure filters to ensure both standard and extended IDs are received correctly using Classic Filter?
  • Should filters be applied in a specific sequence to avoid inconsistent behavior of reception?

Thanks in advance for your support!

  • Hello Danae,

    Are you storing the messages to RX Buffer or RX FIFO?

    With the RX Buffer, this behavior is expected.

    The acceptance filter process is described in to flow charts in the TRM. I am including the standard identifier flow for reference, but it is equivalent for extended identifier.

    I wanted to point out the following note from Bosch MCAN User Guide: (I will file a ticket to make sure this info is added to the TRM if not already).

    Note: When an accepted message is written to one of the two Rx FIFOs, or into an Rx Buffer, the unmodified received identifier is stored independent of the filter(s) used. The result of the acceptance filter process is strongly dependent on the sequence of configured filter elements.

    The following text was also extracted from Dedicated RX Buffers section of the TRM:

    After the last word of a matching received message has been written to the Message RAM, the respective New Data flag in register NDAT1,2 is set. As long as the New Data flag is set, the respective Rx Buffer is locked against updates from received matching frames. The New Data flags have to be reset by the Host by writing a ‘1’ to the respective bit position.

    While an Rx Buffer’s New Data flag is set, a Message ID Filter Element referencing this specific Rx Buffer will not match, causing the acceptance filtering to continue. Following Message ID Filter Elements may cause the received message to be stored into another Rx Buffer, or into an Rx FIFO, or the message may be rejected, depending on filter configuration.

    It is an application/system-level implementation requirement to ensure the acceptance filter process accounts for the expected order of received messages so that all necessary messages are accepted and stored.

    Best Regards,

    Zackary Fleenor

  • Hello Zackary,

    Thank you for your detailed reply. I understand that the order in which CAN ID filters are configured can affect message reception, particularly in how the MCAN controller handles received messages.

    Given that my system is configured to use Rx FIFOs, the filter order is likely not the cause of the message loss I'm experiencing. The receive function in my system is designed to read from an Rx FIFO. Therefore, the issue is likely not due to Rx Buffer management. Instead, the problem might lie in the filter configuration itself or some other aspect of the MCAN setup. Is there any example of a configuration of MCAN for receiving both standard and extended messages on the same CAN bus?

  • Hey Danae,

    I did a quick check, I am not aware of any examples that are configured to receive both types of messages, however the necessary data structures are defined for both types in the mcan.h file.

    MCAN_StdMsgIDFilterElement;
    MCAN_ExtMsgIDFilterElement;
     
    If you start with the mcan_external_read_write example which currently uses StdMsgIDFilterElement.
    Both structures need to be properly configured in the App_mcanConfig(); function of mcan_external_read_write.c.
    Then a new App_mcanInitExtFilterElemParams() function needs to be made that mimics the current App_mcanInitStdFilterElemParams() layout.
    I will check internally with our SW team about the opportunity to include an additional example to showcase this functionality.
    Best Regards,
    Zackary Fleenor