• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 199 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

MSPM0G3507: CAN RX gets stuck when multiple messages are incoming

MSPM0G3507: CAN RX - messages are not received reliably

Matze
Intellectual 431 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi TI-Experts!

In the related question thread I had the problem that my CAN-ID-Filtering didn't work. I now found out the reasons:

1st: I initialized the filter IDs after the execution of DL_MCAN_addStdMsgIDFilter() where the filters are configured. So I configured the filtering with non-initialized filter IDs.

2nd: I didn't use the "Advanced Configuration" in sysconfig so I didn't set the .filterConfig.anfe = 2 and .filterConfig.anfs = 2. So non-matching frames are accepted even after i managed to set the filtering correctly.

So now I managed to get my filtering working.

But other problems stay unsolved:

The receiving of CAN-Messages does not work reliably. Sometimes the first CAN message gets received correctly, sometimes the first CAN message does not trigger a CAN Rx interrupt and is therefore not received.

And this unreliable reception continues with every further message that is to be received. sometimes it works, sometimes not.

When one message is not received and then the next message is received correctly, the CAN RX interrupt is triggered and both the "new message bit"(MCAN_IR_RF0N_MASK) and the "Message RAM Access Failure bit"(MCAN_IR_MRAF_MASK) are set.

But only the message that triggered the CAN RX interrupt is received. the other message does not appear in the rx message struct.

Is there any possibility to look into the CAN RX FIFO to see, if the messages are in the FIFO but did not trigger an interrupt?

My RX MSG RAM is configured properly and there is no overlapping between FIFO0, FIFO1 and Buffer. and I don't use CAN TX so there should be not overlapping and influencing by the TX MSG RAM.

What could be the reason for not triggering an interrupt or to be more precisely what could be the reason that some messages are not received while ohers are received properly?

Thanks a lot in advance!

Matze

  • 0
    TI__Mastermind 39715 points

    Hi,

    I have not encountered this kind of issue before. Usually, if your configuration is correct. Then all the messages which matches the filter will be received by the MCU. Can you send your sysconfig file here so we can take a look into it?

    Best regards,

    Cash Hao

  • 0 in reply to Cash Hao11
    Intellectual 431 points

    sure:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "MSPM0G350X" --part "Default" --package "LQFP-48(PT)" --product "mspm0_sdk@2.02.00.05"
    * @v2CliArgs --device "MSPM0G3507" --package "LQFP-48(PT)" --product "mspm0_sdk@2.02.00.05"
    * @versions {"tool":"1.21.0+3721"}
    */
    /**
    * Import the modules used in this configuration.
    */
    const ADC12 = scripting.addModule("/ti/driverlib/ADC12", {}, false);
    const ADC121 = ADC12.addInstance();
    const Board = scripting.addModule("/ti/driverlib/Board");
    const GPIO = scripting.addModule("/ti/driverlib/GPIO", {}, false);
    const GPIO1 = GPIO.addInstance();
    const GPIO2 = GPIO.addInstance();
    const MCAN = scripting.addModule("/ti/driverlib/MCAN", {}, false);
    const MCAN1 = MCAN.addInstance();
    const PWM = scripting.addModule("/ti/driverlib/PWM", {}, false);
    const PWM1 = PWM.addInstance();
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Matze
    TI__Mastermind 39715 points

    Hi,

    I am check on the configurations. Some points I observed. 

    1. Try enable TDC function

    2. Even though you do not use TX MSG RAM. You still need to confirm there is no overlap on the address. There are overlaps shows in the current configuration.

    Best regards,

    Cash Hao

  • 0 in reply to Cash Hao11
    Intellectual 431 points

    Hi and thanks!

    1. I enabled TDC function:

    ______________________________________________________________________

    2. I eliminated RX and TX Msg RAM overlaps:

    _______________________________________________________________________

    But I still encounter the same unreliable reception.

    Any more ideas what could go wrong? Any more things I could check?

    Within what limits does it make sense to adjust the values for the TDC? Can I somehow measure how big the delay really is that I might have to compensate for?

    Thanks a lot in advance!

    Matze

  • 0 in reply to Matze
    TI__Mastermind 39715 points

    Hi,

    Well, I am checking on the description of 'Message RAM Access Failure bit'

    Message RAM Access Failure. 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.

    In your configuration, you can try change the two filter options to store the message in different FIFOs. The standard filter can be used to save in RX FIFO0 and extended filter can be used to save in RX FIFO1. It can help avoid unable to write message to RAM.

    Best regards,

    Cash Hao

  • 0 in reply to Cash Hao11
    Intellectual 431 points
    Cash Hao11 said:
    In your configuration, you can try change the two filter options to store the message in different FIFOs.

    I can try to change that, but I don't expect much improvement from that. 

    For four reasons:

    1. It is not uncommon for the very first message not to arrive and then the "Message RAM Access Failure bit" is set for the second message that arrives. I don't see the probability that the RAM is not yet accessible.

    2. I send the CAN messages manually with a large time interval, so that the previous message must already have been processed and the ram should no longer be busy.

    3. It also happens when I send multiple messages with the same standard or extended ID. Accordingly, I do not expect any advantage if the other ID is stored in the other FIFO.

    4. I use 4 different IDs, two standard and two extended IDs... so theoretically I would again run the risk of mutual interference in the respective FIFO.

    What do you think?

    __________________________________________________________________

    Matze said:
    Within what limits does it make sense to adjust the values for the TDC? Can I somehow measure how big the delay really is that I might have to compensate for?

    Any ideas or answers to these questions?

    Thanks a lot and best regards,

    Matze

  • 0 in reply to Matze
    TI__Mastermind 39715 points

    Hi,

    I agree with you that it is very uncommon that the very first message not to arrive and then the "Message RAM Access Failure bit" is set for the second message that arrives.

    I do not have many clues about this issue. Maybe try remove the filter configuration and check if this issue still there. The original demo code without the filter does not have this kind of issue for sure. So, I am thinking maybe it relates to the filter. 

    For the TDC, I find out it is for the CAN FD frame. It is not work on classic CAN. So, no needs to worry about it here.

    Best regards,

    Cash Hao

  • 0 in reply to Cash Hao11
    Intellectual 431 points

    Hi,

    in the mean time I found out that my problems in CAN reception were caused by the 80 MHz that I set for CAN-frequency. After I changed my CAN-frequency to 40 MHz my problems in CAN reception were gone!

    But I don't know, why the 80 MHz didn't work errorless.

    Cash Hao11 said:
    I agree with you that it is very uncommon that the very first message not to arrive and then the "Message RAM Access Failure bit" is set for the second message that arrives.

    Concerning this issue I also found out why and need to clarify:

    The "Message RAM Access Failure bit" was set when the can rx interrupt of the second Msg came in because the MRAF-Interrupt was not enabled but the bit nonetheless got set when the message reception crashed. But I only saw that the MRAF bit is set when the new-message-interrupt of the second message was triggered.

    Since I have also activated the MRAF interrupt, an interrupt containing the MRAF flag is also triggered when the first message crashes. Each interrupt flag is now correctly assigned to the corresponding CAN message received.