LM3S2637 Datasheet, PDF (547/678 Pages) Texas Instruments – Stellaris® LM3S2637 Microcontroller

Stellaris^® LM3S2637 Microcontroller
15.3.8
15.3.9
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 upon 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.
Receiving a Remote Frame
A remote frame contains no data, but instead specifies which object should be transmitted. When
a remote frame is received, three different configurations of the matching message object have to
be considered:
Configuration in CANIFnMCTL
Description
■ DIR = 1 (direction = transmit); programmed in the At the reception of a matching remote frame, the TXRQST bit of this
CANIFnARB2 register
message object is set. The rest of the message object remains
unchanged, and the controller automatically transfers the data in
■ RMTEN = 1 (set the TXRQST bit of the
the message object as soon as possible.
CANIFnMCTL register at reception of the frame
to enable transmission)
■ UMASK = 1 or 0
■ DIR = 1 (direction = transmit); programmed in the At the reception of a matching remote frame, the TXRQST bit of this
CANIFnARB2 register
message object remains unchanged, and the remote frame is
ignored. This remote frame is disabled, the data is not transferred
■ RMTEN = 0 (do not change the TXRQST bit of the _{and there is no indication that the remote frame ever happened.}
CANIFnMCTL register at reception of the frame)
■ UMASK = 0 (ignore mask in the CANIFnMSKn
register)
■ DIR = 1 (direction = transmit); programmed in the At the reception of a matching remote frame, the TXRQST bit of this
CANIFnARB2 register
message object is cleared. The arbitration and control field (ID +
XTD + RMTEN + DLC) from the shift register is stored into the
■ RMTEN = 0 (do not change the TXRQST bit of the _{message object in the message RAM and the NEWDAT bit of this}
CANIFnMCTL register at reception of the frame) _{message object is set. The data field of the message object remains}
unchanged; the remote frame is treated similar to a received data
■ UMASK = 1 (use mask (MSK, MXTD, and MDIR in _{frame. This is useful for a remote data request from another CAN}
the CANIFnMSKn register) for acceptance filtering) _{device for which the Stellaris controller does not have readily}
available data. The software must fill the data and answer the frame
manually.
Receive/Transmit Priority
The receive/transmit priority for the message objects is controlled by the message number. Message
object 1 has the highest priority, while message object 32 has the lowest priority. If more than one
transmission request is pending, the message objects are transmitted in order based on the message
object with the lowest message number. This should not be confused with the message identifier
as that priority is enforced by the CAN bus. This means that if message object 1 and message object
2 both have valid messages that need to be transmitted, message object 1 will always be transmitted
first regardless of the message identifier in the message object itself.
June 18, 2012
547
Texas Instruments-Production Data