LM3S5652 Luminary Micro, Inc, LM3S5652 Datasheet - Page 496

• Manufacturer Part Number: LM3S5652
• Description: Lm3s5652 Arm Microcontroller
• Manufacturer: Luminary Micro, Inc

Controller Area Network (CAN) Module
17.4.5
17.4.6
17.4.7
17.4.8
496
The DLC bit in the CANIFnMCTL register is set to the number of bytes to transfer to the message
object. TxRqst and RmtEn should not be set before the data is valid, as the current data in the
message object can be transmitted as soon as these bits are set.
Updating a Transmit Message Object
The CPU may update the data bytes of a Transmit Message Object any time via the CAN Interface
Registers and neither the MsgVal nor the TxRqst bits have to be reset before the update.
Even if only a part of the data bytes are to be updated, all four bytes of the corresponding
CANIFnDAn or CANIFnDBn register have to be valid before the content of that register is transferred
to the message object. Either the CPU has to write all four bytes into the CANIFnDAn or CANIFnDBn
register or the message object is transferred to the CANIFnDAn or CANIFnDBn register before the
CPU writes the new data bytes.
In order to only update the data in a message object, the WR, NewDat, DataA, and DataB bits are
written to the CAN IFn Command Mask (CANIFnMSKn) register, followed by writing the CAN IFn
Data registers, and then the number of the message object is written to the CAN IFn Command
Request (CANIFnCRQ) register, to update the data bytes and the TxRqst bit at the same time.
To prevent the reset of TxRqst at the end of a transmission that may already be in progress while
the data is updated, NewDat has to be set together with TxRqst. When NewDat is set together
with TxRqst, NewDat is reset as soon as the new transmission has started.
Accepting Received Message Objects
When the arbitration and control field (ID + Xtd + RmtEn + DLC) of an incoming message is
completely shifted into the CAN module, the message handling capability of the module starts
scanning the message RAM for a matching valid message object. To scan the message RAM for
a matching message object, the Acceptance Filtering unit is loaded with the arbitration bits from the
core. Then the arbitration and mask fields (including MsgVal, UMask, NewDat, and EoB) of message
object 1 are loaded into the Acceptance Filtering unit and compared with the arbitration field from
the shift register. This is repeated with each following message object until a matching message
object is found or until the end of the message RAM is reached. If a match occurs, the scanning is
stopped and the message handler proceeds depending on the type of frame received.
Receiving a Data Frame
The message handler stores the message from the CAN module receive shift register into the
respective message object in the message RAM. It stores the data bytes, all arbitration bits, and
the Data Length Code into the corresponding message object. This is implemented to keep the data
bytes connected with the identifier even if arbitration mask registers are used. The NewDat bit of
the CANIFnMCTL register is set to indicate that new data has been received. The CPU should reset
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 was already set, the MsgLst bit is set to indicate that the previous data was
lost. If the RxIE bit of the CANIFnMCTL register is set, the IntPnd bit of the same register is set,
causing the CANINT interrupt 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.
Receiving a Remote Frame
When a remote frame is received, three different configurations of the matching message object
have to be considered:
Preliminary
June 02, 2008