PXAC37KFA/00,512 NXP Semiconductors, PXAC37KFA/00,512 Datasheet - Page 50
![IC XA MCU 16BIT 32K OTP 44-PLCC](/photos/6/98/69845/568-44-plcc_sot187-2_sml.jpg)
PXAC37KFA/00,512
Manufacturer Part Number
PXAC37KFA/00,512
Description
IC XA MCU 16BIT 32K OTP 44-PLCC
Manufacturer
NXP Semiconductors
Series
XAr
Datasheet
1.PXAC37KFA00512.pdf
(68 pages)
Specifications of PXAC37KFA/00,512
Core Processor
XA
Core Size
16-Bit
Speed
32MHz
Connectivity
CAN, EBI/EMI, SPI, UART/USART
Peripherals
DMA, POR, PWM, WDT
Number Of I /o
32
Program Memory Size
32KB (32K x 8)
Program Memory Type
OTP
Ram Size
1K x 8
Voltage - Supply (vcc/vdd)
4.5 V ~ 5.5 V
Oscillator Type
External
Operating Temperature
-40°C ~ 85°C
Package / Case
44-PLCC
Lead Free Status / RoHS Status
Lead free / RoHS Compliant
Eeprom Size
-
Data Converters
-
Other names
568-3533-5
935266516512
PXAC37KFA
935266516512
PXAC37KFA
Available stocks
Company
Part Number
Manufacturer
Quantity
Price
Company:
Part Number:
PXAC37KFA/00,512
Manufacturer:
NXP Semiconductors
Quantity:
10 000
Philips Semiconductors
The Frame Info byte contains the following bits:
FRAME INFO
The actual incoming Screener ID which caused the Match can be
retrieved from the MnMIDH and MnMIDL registers as shown in
Figure 39.
MNMIDH
MNMIDL
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
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.
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.
2000 Jan 25
ID.28
ID.12
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
15
15
Figure 40. Memory Image for Fragmented CTL Messages
Data Byte 2 (next)
Data Byte 3 (next)
IDE
Data Byte DLC
7
Data Byte 2
Data Byte 3
Byte count
ID.27
ID.11
14
14
(FRAG = 1 and Prtcl1 Prtcl0
ID.26
ID.10
13
13
RTR
6
ID.25
ID.9
12
12
Figure 39. Retrieving the Screener ID for an Extended CAN Frame
Direction of increasing
ID.24
00), the first CAN frame data
ID.8
11
11
SEM1
5
address
address
ID.23
ID.7
10
10
00)
ID.22
ID.6
9
9
SEM0
4
ID.21
ID.5
8
8
43
ID.20
ID.4
7
7
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
Figure 41. Memory Image for CAN Frame Buffering (FRAG = 1
DLC.3
3
Data Byte 1 (next)
Data Byte 2 (next)
FrameInfo (next)
Data Byte DLC
ID.19
ID.3
Data Byte 1
Data Byte 2
FrameInfo
6
6
ID.18
ID.2
5
5
DLC.2
2
and Prtcl1 Prtcl0
ID.17
ID.1
4
4
Direction of increasing
Direction of increasing
dd
dd
Direction of increasing
ID.16
ID.0
3
3
DLC.1
1
address
address
ID.15
00)
IDE
Preliminary specification
2
2
ID.14
1
1
–
XA-C3
DLC.0
0
ID.13
0
0
–