XA-C3 Datasheet, PDF (55/68 Pages) NXP Semiconductors – 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-proce

Philips Semiconductors
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
Preliminary specification
XA-C3
condition will always be generated at the end of each successfully
transmitted frame.
There is a control bit associated with each Message Object
indicating whether a message complete condition should generate
an interrupt, or just set a “message complete status flag” (for polling)
without generating an interrupt. This is the INT_EN bit in the object’s
MnCTL register, MnCTL[3].
There are two 16–bit MMRs, MCPLH and MCPLL, which contain the
message complete status flags for all 32 objects. When a message
complete (Tx or Rx) condition is detected for a particular Message
Object, the corresponding bit in the MCPLH or MCPLL register will
be set. This will occur regardless of whether the INT_EN bit is set
for that object (in MnCTL[3]), or whether message complete status
flags have already been set for any other objects.
In addition to these 32 message complete status flags, there is a Tx
Message Complete Interrupt Flag and an Rx Message Complete
Interrupt Flag (CANINTFLG[1] and CANINTFLG[0] respectively),
which will generate the actual Event interrupt requests to the XA
core. When an end of message occurs, at the same moment that
the message complete status flag is set, the appropriate Tx or Rx
Message Complete Interrupt flip–flop will also be set provided that
INT_EN = 1 for the object, and the interrupt is not already set and
pending.
The message complete interrupt flags should always be cleared
using the 2–step process outlined below:
1. Message Complete Status Flags for all interrupt enabled objects
of that type (Tx or Rx) should first be cleared by writing ‘1’ to
their bit positions.
2. The Message Complete Interrupt Flag itself can now be cleared
by writing ‘1’ to its bit position.
Warning: Message Complete Interrupt Flags may be cleared before
all Message Complete Status Flags for interrupt enabled objects of
that type (Rx or Tx) are removed. However, the interrupt flag will not
be reset to ‘1’ by hardware, unless a new message complete
condition occurs for some other interrupt enabled object. Therefore,
it is strongly recommended that Message Complete Interrupt Flags
be cleared only after removing all Message Complete Status Flags
for interrupt enabled objects of the same type, and at the end of the
interrupt service routine.
The newest addition is the Message Complete Info Register (MCIR).
MCIR[4:0] will encode the lowest object number of all objects whose
INT_EN bits are set AND who currently have a message complete
condition (objects whose message complete status flags are set). A
‘1’ in bit 5 means that one or more objects whose INT_EN bits are
set have a message complete condition. A ‘0’ in bit 5 means that no
objects whose INT_EN bits are set have a message complete
condition. Bits 6 and 7 are unused.
Rx Buffer Full Interrupt
As successive frames of a Fragmented message are transferred by
DMA into an object’s message buffer, it is possible to reach the end
of the designated buffer space before the complete message has
been received. When this occurs, it is necessary for the processor to
intervene in order that the remainder of the message be stored
without any loss of data.
If the system protocol is DeviceNet, CANopen, or OSEK, then a
message buffer is considered full when the number of bytes
remaining in the buffer space, at the end of a complete frame, is less
than seven.
If the system protocol is CAN, i.e., [Prtcl1 Prtcl0] = 00, then Rx
Buffer Full is defined as “less than 9 bytes remaining” after storage
of a complete CAN frame. When the DMA pointer wraps around, it
will be reset to offset ‘1’ in the buffer, not offset ‘0’, and there will be
no Byte Count written.
This condition could occur if the application has underestimated the
message size, or deliberately established a small buffer to conserve
memory. The condition will always occur with messages containing
more than 255 data bytes (excluding Fragmentation information
bytes), since the maximum message buffer size is 256 bytes.
The following discussion only applies to frames which are not the
last frame of a message (which also, necessarily, excludes
non–Fragmented, single–frame messages). After DMA of the last
data byte of the frame is completed, a check will be performed to
determine if the current byte count is less than 7 bytes from the end
of the assigned message buffer. If it is, then there is the potential for
the next frame to overrun the buffer. We will consider this
“less–than–seven–bytes–remaining” situation to be a buffer–full
condition. When this condition is detected, the following will occur:
D The current byte count will be written into buffer location ‘0’
except in CAN systems. If [Prtcl1 Prtcl0] = 00, no byte count will
be written.
D The address pointer will be initialized to location ‘1’
D The Rx Buffer Full interrupt will be generated
As subsequent frames are received, the data bytes will be stored,
beginning at location ‘1’. The semaphore byte will not be written to
again, since message assembly is still in progress. Once the
end–of–message is finally received, the DMP will respond as usual,
writing the byte–count to location ‘0’ and setting the Rx Message
Complete Interrupt Flag. Note that the byte count will now reflect
the number of bytes received since the buffer wrapped around,
not the total number of bytes in the message. Software will have
to calculate the difference.
The software has two choices as to how to respond to this Rx Buffer
Full interrupt:
1. Read the contents of the buffer, thereby freeing up space in the
buffer for any remaining frames.
2. Reposition the buffer by modifying the address pointer. Note: The
least significant bit of the address pointer will already be set to
‘1’, and must remain so. The bottom location must be reserved
for the byte–count which will be written at the end of the
message.
If option 1 is selected, the software will retrieve the current byte
count from the bottom of the buffer. It will then retrieve the
designated number of data bytes from the buffer. Subsequent data
received will be loaded into the buffer, beginning at location ‘1’.
When the end–of–message occurs, the byte–count stored in
location ‘0’ will indicate how many new bytes have been received
which must now be retrieved.
For option 2, subsequent bytes will actually be written into a different
buffer space, elsewhere in memory. The processor can wait until the
entire message is received before retrieving any data. At that time,
the ‘0’ location of the 1^st buffer will indicate how many bytes are
stored there, and likewise for the second buffer (or third or so on).
Note that option 2 is far more efficient and can be implemented with
very few instructions.
2000 Jan 25
48