• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 229 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP432E401Y: CAN functionality with RTOS implementation

Mith Jain
Prodigy 10 points
Part Number: MSP432E401Y

Hello, 
I am using RTOS based example project with CAN Communication for a Vehicle Control Unit implementation. 
I have one thread to handle the state diagram (say A) and another thread running parallel just for CAN_read() (say B)
The question I have is as follows:
Because of time slicing, when thread A is running, the message received on the CAN Bus would ideally be stored in a buffer in the hardware
When thread B resumes its functioning, does it process the messages stored in the buffer or directly the messages currently on the bus?

In the latter case, wouldn't it lead to us losing a lot of messages, and in the former case, what is the size of the internal buffer storing the messages for future processing? 

Thank you in advance!

  • 0
    TI__Guru**** 191206 points

    Hi,

      If thread B is more important than A then you should set B's task priority higher than A. CAN module stores the messages in its message memory. There are 32 message objects to save messages. Unless all messages (per the message ID and the acceptance filter) are saved to the same message object, the MSG LOST lag will set in the hardware.

    Receiving a Data Frame
    The message handler stores the message from the CAN controller receive shift register into the
    matching message object in the message RAM. The data bytes, all arbitration bits, and the DLC bits
    are all stored into the corresponding message object. In this manner, the data bytes are connected
    with the identifier even if arbitration masks are used. The NEWDAT bit of the CANIFnMCTL register
    is set to indicate that new data has been received. The CPU should clear this bit when it reads the
    message object to indicate to the controller that the message has been received, and the buffer is
    free to receive more messages. If the CAN controller receives a message and the NEWDAT bit is
    already set, the MSGLST bit in the CANIFnMCTL register is set to indicate that the previous data
    was lost. If the system requires an interrupt on successful reception of a frame, the RXIE bit of the
    CANIFnMCTL register should be set. In this case, the INTPND bit of the same register is set, causing
    the CANINT register to point to the message object that just received a message. The TXRQST bit
    of this message object should be cleared to prevent the transmission of a remote frame.