PXAC37KFA/00,512 NXP Semiconductors, PXAC37KFA/00,512 Datasheet - Page 50

• Manufacturer Part Number: PXAC37KFA/00,512
• Description: IC XA MCU 16BIT 32K OTP 44-PLCC
• Manufacturer: NXP Semiconductors
• Series: XAr

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

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
–