XA-C3 Datasheet, PDF (50/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
The Frame Info byte contains the following bits:
FRAME INFO
7
6
IDE
RTR
5
SEM1
4
SEM0
3
DLC.3
2
DLC.2
1
DLC.1
0
DLC.0
The actual incoming Screener ID which caused the Match can be
retrieved from the MnMIDH and MnMIDL registers as shown in
Figure 39.
MNMIDH
15
14
ID.28 ID.27
13
ID.26
12
ID.25
11
ID.24
10
ID.23
9
ID.22
8
7
ID.21 ^ID.20
6
5
4
3
2
1
0
ID.19 ID.18 ID.17 ID.16 ID.15 ID.14 ID.13
MNMIDL
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
ID.12 ID.11 ID.10 ID.9 ID.8 ID.7 ID.6 ID.5 ID.4 ID.3 ID.2 ID.1 ID.0 IDE
–
–
Figure 39. Retrieving the Screener ID for an Extended CAN Frame
Fragmented Message Assembly
Masking of the 11/29 bit CAN Identifier field by User software (but
only the actual bits of the Identifier itself!) is disallowed for any
Message Object which employs auto–Fragmentation assembly. The
identifier which resulted in the Match is, therefore, known
unambiguously and is not included in the receive buffer. If the
software needs access to this information, it can retrieve it from the
appropriate MnMIDH and MnMIDL registers.
As subsequent frames of a Fragmented message are received, the
new data bytes are appended to the end of the previously received
packets. This process continues until a complete multi–frame
message has been received and stored.
If an object is enabled with FRAG = 1, under protocols DeviceNet,
CANopen, and OSEK (Prtcl1 Prtcl0 ≠ 00), the first CAN frame data
byte is used to encode Fragmentation information only. That byte
will not be stored in the buffer area. The storage will start with the
second data byte (Data Byte 2) and proceed to the end of the frame.
See Figure 40.
Byte count
Data Byte 2
Direction of increasing
address
Data Byte 3
…
Data Byte DLC
Data Byte 2 (next)
Data Byte 3 (next)
…
Figure 40. Memory Image for Fragmented CTL Messages
(FRAG = 1 and Prtcl1 Prtcl0 ≠ 00)
If an object is enabled with FRAG = 1, with CAN as the system
protocol (Prtcl1 Prtcl0 = 00), then CAN frames are stored
sequentially in that object’s message buffer using the format shown
in . Also, if [Prtcl1 Prtcl0] = 00, 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.
FrameInfo
Data Byte 1
Direction of increasing
address
Data Byte 2
…
Data Byte DLC
FrameInfo (next)
Data Byte 1 (next)
Data Byte 2 (next)
…
Direction of incr…easing
dd
Figure 41. Memory Image for CAN Frame Buffering (FRAG = 1
and Prtcl1 Prtcl0 = 00)
During buffer access, the DMA will generate addresses
automatically starting from the base location of the buffer. If the DMA
has reached the top of the buffer, but the message has not been
completely transferred to memory yet, the DMA will wrap around by
generating addresses starting from the bottom of the buffer again.
Some time before this happens, a warning interrupt will be
generated so that the User application can take the necessary
action to prevent data loss.
The top location of the buffer is determined by the size of the buffer
as specified in MnBSZ.
The XA-C3 automatically receives, checks and reassembles up to
32 Fragmented messages automatically. When the FRAG bit is set
on a particular message, the message handler hardware will use the
Fragmentation information contained in Data Byte 1 of each frame.
To enable automatic Fragmented message handling for a certain
Message Object, the User is responsible for setting the FRAG bit in
the object’s MnCTL register.
The message handler will keep track of the current address location
and the number of bytes of each CTL message as it is being
assembled in the designated message buffer location. After an “End
of Message” is decoded, the message handler will finish moving the
complete message and the byte count into the message buffer via
2000 Jan 25
43