MSPM0G3507: CAN RX gets stuck when multiple messages are incoming

Thank you!

1.

I see that the "MCAN" - "Advanced Configuration" - "Additional Core Configuration" is enabled and configured.

I have not used this setting by now. might this be the reason why I have these problems?

I don't really understand what I can achieve with these "advanced configuration settings". Is there any help, advice oder documentation concerning these settings? Or can anyone explain to me, what it is?

2.

In the example I find the comment:

Hey,

Thanks for your answers.

I tried to implement everything as in the example that you provided.

But I am facing the problem that my filtering does not seem to work.

I defined the following filters:

But the filtering has no effect. The MCAN new message interrupt gets triggered every time that any message with any ID is received on the CANBUS.

Even any "wrong" message ID is stored in FIFO an triggers an interrupt.

And I have the following lines in my void SYSCFG_DL_MCAN0_init(void)


But when I remove these lines, everything stays unchanged. These lines seem to have no effect.

What should these functions actually do and why don't they currently do that for me?

Thanks a lot in advance!

Matze

Hi, Matze

Matze said:

I defined the following filters:

Filter settings are right~

But need to waiting for MCAN RAM init done, you can set the filter.

There is no need to enter initialization mode to set the filter.

------------

Could you please try to test the MCAN based on my project.

It works normal when set the right filter.

------------------

Check whether you enable the RXFIFO1 interrupt, this will also cause MCAN interrupt triggered.

Also, interrupt need to check every interrupt you enabled to confirm which interrupt is triggered.

Don't put printf function in interrupt, printf will takes a lot of time to printf string.

Regards,

Helic

Hi,

Helic Chi said:

But need to waiting for MCAN RAM init done, you can set the filter.

I compared my SYSCFG_DL_MCAN0_init() to the SYSCFG_DL_MCAN0_init() in the mcan_multi_Msg_RxTx_Interrupt_LP_MSPM0G3507_nortos_ticlang example project.

Both functions are completely identical.

So the MCAN RAM init (

) is waited to be done before I add my filters.

Is this what you wanted me to make sure?

________________________________________________________________

Helic Chi said:

Could you please try to test the MCAN based on my project.

It works normal when set the right filter.

Yes, I will check that.

________________________________________________________________

Helic Chi said:

Check whether you enable the RXFIFO1 interrupt

I enable the FIFO 0 New Message interrupt in the beginning of my int main(void).

Instead of

I could have chosen

Am I right?

I have no corresponding activation/enabling of an interrupt for FIFO1 in my source code.

________________________________________________________________

Helic Chi said:

Also, interrupt need to check every interrupt you enabled to confirm which interrupt is triggered.

I do check what triggered my IRQ like this:

void MCAN0_INST_IRQHandler(void)
{
    switch (DL_MCAN_getPendingInterrupt(MCAN0_INST)) {
    
        case DL_MCAN_IIDX_LINE1:                                                    // RX FIFO 0 New Message - interrupt

            /* Check MCAN interrupts fired during RX of CAN package */
            gInterruptLine1Status |= DL_MCAN_getIntrStatus(MCAN0_INST);

            /* New message received by Rx FIFO 0 (Filter matched) */
            if(gInterruptLine1Status & DL_MCAN_INTERRUPT_RF0N) 
            {
                ...
            }

EDIT:

And I debugged my code and added a watch expression on "gInterruptLine1Status" and found out that every time the IRQ gets triggered the "gInterruptLine1Status" holds the value 0x20001. So the "Message RAM Access Failure bit" (MCAN_IR_MRAF_MASK) and the "RX FIFO 0 New Message bit" (DL_MCAN_INTERRUPT_RF0N) are set.

Really every time both bits are set. Regardless of whether I receive a filter-matching or a not-filter-matching CAN Message ID.

What could possibly cause this "Message RAM Access Failure" ?

in hw_mcan.h it says: 

The
flag is set, when the Rx Handler:   -
has not completed acceptance
filtering or storage of an accepted
message until the arbitration field
of the following message has been
received. In this case acceptance
filtering or message storage is
aborted and the Rx Handler starts
processing of the following message.
- was not able to write a message to
the Message RAM. In this case message
storage is aborted.   In both cases
the FIFO put index is not updated
resp. the New Data flag for a
dedicated Rx Buffer is not set, a
partly stored message is overwritten
when the next message is stored to
this location.   The flag is also set
when the Tx Handler was not able to
read a message from the Message RAM
in time. In this case message
transmission is aborted. In case of a
Tx Handler access failure the MCAN is
switched into Restricted Operation
Mode. To leave Restricted Operation
Mode, the Host CPU has to reset
CCCR.ASM.   0  No Message RAM access
failure occurred   1  Message RAM
access failure occurred */

but unfortunately i can't do much with these explanations..

________________________________________________________________

EDIT2: And if I look at the received messages as “watch expression” during debugging, I see the following set bit:

amnf = 1 : Accepted Non-matching Frame - Received frame did not match any Rx filter element

The filter index (fidx) is also so high at “127” that it appears to have tried all the filters and none of them matched.

So somehow there must be a way to set filters for receiving CAN messages that really only accept filter matching message IDs..
So that an interrupt may only be triggered if a CAN message with a matching (filtered) ID is received.

________________________________________________________________

Helic Chi said:

Don't put printf function in interrupt, printf will takes a lot of time to printf string.

Yes sure.. I just use it for debugging..

But this does not cause my filtering issue, does it?

Thanks in advance!

Matze

Hi, Matze

Matze said:

Is this what you wanted me to make sure?

Yes, seems ok.

Matze said:

I do check what triggered my IRQ like this:

Also, remember to manually clear the interrupt.

Matze said:

What could possibly cause this "Message RAM Access Failure" ?

RAM init is nor finished, or your Filter is not written into CAN RAM successfully.

Please try this demo, this demo can read the filter from CAN RAM, you need to verify your filter configuration.

4174.mcan_multi_Filter_Control_LP_MSPM0G3507_nortos_ticlang.zip

Matze said:

But this does not cause my filtering issue, does it?

Not likely, but it's a risk.

Regards,

Helic

Hi!

Helic Chi said:

Also, remember to manually clear the interrupt

I manually clear the interrupt status in the beginning of my IRQ-case by this line of code:

And depending on the bit that is set in the Interrupt Status Register and in gInterruptLine1Status I clear these bits after processing the corresponding case in the IRQ by:

and/or

When I check gInterruptLine1Status after the IRQ it holds the value 0x00 as expected.

AND I have to correct myself:

When an incoming message (no matter what ID) triggers the Interrupt, only the RF0N-bit is set.

But when an incoming message does not trigger the Interrupt (here, too, it makes no difference whether the ID is contained in my filter config or not) and after that a new message triggers the Interrupt, both bits RF0N and MRAF are set.

Helic Chi said:

RAM init is nor finished, or your Filter is not written into CAN RAM successfully.

Please try this demo, this demo can read the filter from CAN RAM, you need to verify your filter configuration.

4174.mcan_multi_Filter_Control_LP_MSPM0G3507_nortos_ticlang.zip

Thanks, I will try this example!

Hi, Matze

Matze said:

But when an incoming message does not trigger the Interrupt (here, too, it makes no difference whether the ID is contained in my filter config or not) and after that a new message triggers the Interrupt, both bits RF0N and MRAF are set.

This is a bit weird. ID filter seems not work normally. And two message will cause MRAF.

Please also check your MCAN RAM configuration, all filter and message RAM share the sam 1024bytes MCAN RAM region, please make sure that these parts do not overlap in using RAM.

Here is an example:

Matze said:

Thanks, I will try this example!

Waiting for your feedback.

Regards,

Helic