XA-C3 NXP Semiconductors, XA-C3 Datasheet - Page 46

• Manufacturer Part Number: XA-C3
• Description: The XA-C3 is a member of the Philips XA (eXtended Architecture) family of high-performance 16-bit single-chip microcontrollers
• Manufacturer: NXP Semiconductors

Philips Semiconductors
CAN/CTL MESSAGE HANDLER
Message Objects
The XA-C3 supports 32 independent Message Objects, each of
which can be either a transmit or a receive object. A receive object
can be associated either with a unique CAN ID, or with a set of CAN
IDs which share certain ID bit fields.
Each Message Object has access to its own block of data memory
space, which is known as the object’s message buffer. Both the size
and base address of an object’s message buffer is programmable.
However, all message buffers must reside in the same 64Kbyte
segment of data memory, as the contents of a single register
(MBXSR Message Buffer and XRAM Segment Register) are used
to form the most significant byte of all 24–bit message buffer
addresses.
Each Message Object is associated with a set of eight MMRs
dedicated to that object. Some of these registers function differently
for Tx than they do for Rx objects. The names of the eight MMRs
are
Table 22. Message Object Register Functions for Tx and Rx
Receive Message Objects and the Receive
Process
During reception, the XA-C3 will store the incoming message in a
temporary (13–byte) buffer. Once it is determined that a complete,
error–free CAN frame has been successfully received, the XA-C3
will initiate the acceptance filtering (“Mask and Match”) process. If
acceptance filtering produces a Match with an enabled receive
object’s Match ID, the message is stored by the DMA engine in that
object’s message buffer.
Acceptance Filtering
The XA-C3 will sequentially compare the 30–bit Screener ID
extracted from the incoming frame to the corresponding Match ID
values specified in the MnMIDH and MnMIDL registers for all
currently enabled receive objects. Any of the bits which are Masked
will be excluded from this comparison. Masking is accomplished on
an object–by–object basis by writing a logic ‘1’ in the desired bit
position(s) in the appropriate MnMSKH or MnMSKL register.
Any screener ID bits which are not intended to participate in
acceptance filtering for a particular object must be Masked by the
User (e.g., ID bits 0 & 1 for a Standard CAN frame, and possibly one
or both data bytes).
If the acceptance filter determines that there is a Match between the
incoming frame and any enabled receive object, the contents of the
2000 Jan 25
MnMIDH
MnMIDL
MnMSKH
MnMSKL
MnCTL
MnBLR
MnBSZ
MnFCR
* After reception, the actual incoming Screener ID (without regard to Mask bits) will be stored by hardware in MnMIDH and MnMIDL for the
benefit of the User application.
** Typically written to only by hardware. Exceptions are the CANopen and OSEK protocols in which the User application must also initialize
this register.
XA 16-bit microcontroller family
32K/1024 OTP CAN transport layer controller
1 UART, 1 SPI Port, CAN 2.0B, 32 CAN ID filters, transport layer co-processor
Message Object Register
(n = 0 – 31)
Match ID* [28:13]
Match ID* [12:0][IDE][–][–]
Mask [28:13]
Mask [12:0][–][–][–]
Control
Buffer base address [a15:a0]
Buffer size
Fragmentation count**
Rx Function
39
1. MnMIDH – Message n Match ID High
2. MnMIDL – Message n Match ID Low
3. MnMSKH – Message n Mask High
4. MnMSKL – Message n Mask Low
5. MnCTL – Message n Control
6. MnBLR – Message n Buffer Location Register
7. MnBSZ – Message n Buffer Size
8. MnFCR – Message n Fragment Count Register
where n ranges from 0 to 31. In general, setting up a Message
Object involves configuring some or all of its eight MMRs.
Additionally, there are several MMRs whose bits control global
parameters that apply to all objects. Table 22 summarizes the eight
Message Object MMRs and their functions for receive and transmit
objects. Details can be found in the sections that follow.
frame will be stored, via DMA, into the designated message buffer
space associated with that object. If there is a Match to more than
one Message Object, the frame will be considered to have matched
the one with the lowest object number.
To summarize, Acceptance Filtering proceeds as follows:
Screener ID Field for Standard CAN Frame
The following table shows how the Screener ID field is assembled
from the incoming bits of a Standard CAN Frame, and how it is
compared to the Match ID and Mask fields of Object n.
The “Screener ID” field is extracted from the incoming CAN
Frame. The Screener ID field is assembled differently for
Standard and Extended CAN Frames.
The assembled Screener ID field is compared to the Match ID
fields of all enabled receive Message Objects.
Any bits which an object has Masked (by having ‘1’ bits in its
Mask field) are not included in the comparison. That is, if there is
a ‘1’ in some bit position of an object’s Mask field, the
corresponding bit in the object’s Match ID field becomes a don’t
care (i.e., always yields a Match with the Screener ID).
If filtering in this manner produces a Match, the frame will be
stored via the DMA engine in that object’s message buffer. If there
is a Match with more than one object, the frame will be considered
to have matched the one with the lowest object number.
CAN ID [28:13]
CAN ID [12:0][IDE][–][–]
DLC
Not used
Control
Buffer base address [a15:a0]
Buffer size
Not used
Tx Function
Preliminary specification
n0h
n2h
n4h
n6h
n8h
nAh
nCh
nEh
XA-C3
Address
Offset