PXAC37KFA/00,512 NXP Semiconductors, PXAC37KFA/00,512 Datasheet - Page 56
![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
Message Error Interrupt
There are two possible sources of a Message Error Interrupt: Tx
Buffer Underflow, and Fragmentation Error. When either of these
conditions occur for any Message Object, the Message Error
Interrupt Flag (CANINTFLG[3]) will be set. In addition, the Message
Error Info Register (MEIR) will be updated to reflect the number of
the object which suffered the message error, and the specific type of
message error encountered (Tx Buffer Underflow or Fragmentation
Error).
The MERIF interrupt flag is cleared by writing ‘1’ to the flag’s
position in CANINTFLG[3].
Tx Buffer Underflow
This condition occurs when the transmit engine is “starved” due to
the inability of the DMA to gain access to the bus. This interrupt
condition is predominantly for system debugging. It should never
occur during normal operation unless there is a serious flaw in the
system (e.g., a peripheral which asserts the WAIT signal for an
extended period).
Fragmentation Error
Fragmentation Error is an out–of–sequence Fragment count. For
each successive frame of a Fragmented message, the new
Fragment count must equal the previous count plus one. For
DeviceNet, the Fragment count field is 6 bits wide, for OSEK it is 4
bits wide, and for CANopen it is merely a single, toggling bit.
If a new start–of–message indicator is received for an object, while
the XA-C3 is already in the process of assembling a message for
that object, the pointers for that object will be automatically reset and
assembly will re–commence at the bottom of that object’s message
buffer. The previous, in–progress message will be overwritten, and
no interrupt or error flag of any kind will be generated.
Frame Error Interrupt
There are six conditions generated from within the CAN core, any of
which may cause the Frame Error Interrupt Flag (the FERIF bit in
CANINTFLG[4]) to be set:
1. The six individual Frame Error Status Flags in the FESTR
2. The FERIF bit can then be cleared by writing ‘1’ to the flag’s bit
Bus Error
When a Bus Error occurs, the BERR status flag in FESTR[3] will be
set, generating a Frame Error interrupt, if enabled. The BERR status
flag is cleared by executing a read of the Error Code Capture
Register (ECCR).
2000 Jan 25
Bus Error
Pre–Buffer Overflow
Arbitration Lost
Error Warning
Error Passive
Bus Off
Each condition has a corresponding status flag in the Frame Error
Status Register (FESTR), which will be set when that condition
occurs. Each condition also has a corresponding enable bit in the
Frame Error Enable Register (FEENR). If a particular condition’s
enable bit is set, then when hardware sets that condition’s status
flag, the Frame Error Interrupt Flag will also be set. The Frame
Error Interrupt Flag is cleared using a 2–step process:
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
register must first be cleared. Details on clearing these flags will
be found in the following sections.
position in CANINTFLG[4].
49
The type and location of the error within the bit stream will be
encoded and stored in the Error Code Capture register for the
benefit of the User application. The ECCR register must be read by
the CPU in order to be reactivated for capturing the next error code,
as well as to clear the BERR status flag. Error codes in the ECCR
register are interpreted as shown in Table 25. A read of the ECCR
register should be executed before the Bus Error interrupt is
enabled.
Table 25. Error Codes for the Error Code Capture
Pre–Buffer Overflow
The XA-C3 stores one complete frame (which can be up to 13
bytes) in a receive “pre–buffer” while the previous frame is being
processed. Even under extreme conditions, this should provide
ample time for the previous frame to be written to memory by DMA.
If for some reason the DMA is unable to gain access to the bus for a
long period of time, the pre–buffer could overflow. In this event, the
XA-C3 will stop accepting the new message. That is, once the five
pre–buffer bytes are full, subsequent incoming bits will be ignored.
ECCR[7:6]
ECCR[4:0]
Register (ECCR)
ECCR[5]
00011
00010
00110
00100
00101
00111
01110
01100
01101
01001
01011
01010
01000
11000
11001
11011
11010
10010
10001
10110
10011
10111
11100
01111
00
01
10
11
0
1
Rx Error, error occurred during
Tx Error, error occurred during
Intermission (go buy popcorn)
Acknowledge Delimiter
Passive Error Flag
Data Length Code
Tolerate DOM bits
Acknowledge slot
Active Error Flag
CRC Sequence
Reserved Bit 1
Reserved Bit 0
Start of Frame
CRC Delimiter
Error Delimiter
End Of Frame
Overload Flag
Interpretation
Interpretation
Interpretation
Preliminary specification
ID28
ID20
ID17
transmission
ID12
Other Error
Form Error
ID4
Stuff Error
Data Field
reception
Bit Error
SRR Bit
RTR Bit
IDE Bit
ID21
ID18
ID13
ID0
ID5
XA-C3