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

The XA-C3 is a member of the Philips XA (eXtended Architecture) family of high-performance 16-bit single-chip microcontrollers

XA-C3

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
Datasheet
Philips Semiconductors
for transmission, regardless of the priority level represented by its
CAN identifier.
Message Retrieval
Once a Message Object is selected for transmission, the DMA will
begin retrieving the data from the message buffer area in memory
and transferring the data to the CAN core block for transmission.
The same DMA engine and address pointer logic is used for
message retrieval of transmit messages as for message storage of
receive messages. Message buffer location and size information is
specified in the same way. Please refer to the section entitled
Message Storage on page 41 for a complete description.
When a message is retrieved, it will be written to the CCB
sequentially. During this process, the DMA will keep requesting the
bus, reading from memory and writing to the CCB.
To prepare a message for transmission, the User application is
required to put the message in the appropriate object’s message
buffer area in the format shown below:
Transmission of Fragmented Messages
The XA-C3 does not handle the transmission of Fragmented
messages in hardware. It is the User’s responsibility to write each
frame of a Fragmented message to the transmit buffer, enable the
object for transmission, and wait for a completion before writing the
next frame to the message buffer. The User application must
therefore transmit multiple frames one by one until the whole
message is transmitted.
However, by using multiple Tx objects whose object numbers
increase sequentially, and whose CAN IDs have been configured
identically, several frames of a Fragmented message can be
queued–up and enabled, and will be transmitted in order.
RTR Handling
This section describes how to receive or transmit Remote Transmit
Request (RTR) frames.
Receiving an RTR Frame
1. The software must setup an Rx object with the RTR bit in
2. An RTR frame is received when the CAN ID Matches that of the
3. If interrupt is enabled for that Message Object, an interrupt will
4. The software would usually have a transmit object available with
Transmitting an RTR Frame
1. The software must setup a Tx object with the RTR bit in
2. The software sets the object enable bit (OBJ_EN) which will
2000 Jan 25
15
x
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
MnCTL[0] set to ‘1’.
enabled receive object whose RTR bit set to ‘1’.
be generated upon the RTR message reception.
the same ID. Upon receiving an RTR frame, the software should
update the data for the corresponding transmit object and send it
out.
MnCTL[0] set to ‘1’.
enable the object to participate in pre–arbitration.
14
x
13
x
12
x
11
x
10
x
9
x
Figure 42. Format for Storing the Tx Frame Info in MnMSKH
8
x
7
x
6
x
5
x
4
x
46
Please observe that the CAN identifier field and frame info must not
be included in the transmit buffer. The transmit logic retrieves this
information from the appropriate MnMIDH, MnMIDL, and MnMSKH
registers. The format for storing the frame information in the
MnMSKH register is shown in Figure 42.
3. After the object wins pre–arbitration, an RTR frame will be sent
4. At the end of a successful RTR transmission, the OBJ_EN bit will
5. It is possible for an incoming message, with CAN ID Matching
Data integrity issues
The data stored in the message buffer area can be accessed both
by the CPU and by the DMA engine. Measures have been taken to
ensure that the application does not read data from an object as it is
being updated by the DMA. This is especially important if receive
interrupts have been disabled or have not been responded to before
a new message could have arrived. The general principle is,
Using the Semaphore Bits, SEM1 and SEM0
A three–state semaphore is used to signal whether a given buffer is:
1. Ready for CPU to read
2. Being accessed by DMA (therefore not ready for CPU read)
3. Being read by CPU
The semaphore is encoded by two semaphore bits, SEM1 and
SEM0, which are in bit positions [5] and [4] of the Frame Info byte,
the first byte of the receive buffer.
DLC.3
When DMA is accessing the buffer, the CPU should NOT attempt
to read from and write to the buffer.
When CPU is accessing the buffer, the DMA is still allowed to
access the buffer. When this happens the CPU should be able to
detect and abandon the data read.
out with a ‘1’ in the RTR bit position.
be cleared. An interrupt could be generated if it is enabled.
that of the transmitting RTR object, to arrive while the
transmitting RTR object is in pre–arbitration, or even during
transmission. In this case, the OBJ_EN bit of the transmitting
RTR object will be cleared to ‘0’, but no interrupt will be
generated.
3
Data Byte 0
Data Byte 1
Data Byte 2
Data Byte 3
Data Byte 4
Data Byte 5
Data Byte 6
Data Byte 7
DLS.2
2
Direction of increasing
DLC.1
1
address
address
Preliminary specification
XA-C3
DLC.0
0

Related parts for XA-C3