XA-C3 Datasheet, PDF (56/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
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:
D Bus Error
D Pre–Buffer Overflow
D Arbitration Lost
D Error Warning
D Error Passive
D Bus Off
D 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:
1. The six individual Frame Error Status Flags in the FESTR
register must first be cleared. Details on clearing these flags will
be found in the following sections.
2. The FERIF bit can then be cleared by writing ‘1’ to the flag’s bit
position in CANINTFLG[4].
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).
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
Register (ECCR)
ECCR[7:6]
Interpretation
00
Bit Error
01
Form Error
10
Stuff Error
11
Other Error
ECCR[5]
Interpretation
0
Tx Error, error occurred during
transmission
1
Rx Error, error occurred during
reception
ECCR[4:0]
Interpretation
00011
Start of Frame
00010
00110
ID28 … ID21
ID20 … ID18
00100
SRR Bit
00101
IDE Bit
00111
01111
01110
01100
ID17 … ID13
ID12 … ID5
ID4 … ID0
RTR Bit
01101
Reserved Bit 1
01001
Reserved Bit 0
01011
Data Length Code
01010
Data Field
01000
CRC Sequence
11000
CRC Delimiter
11001
Acknowledge slot
11011
Acknowledge Delimiter
11010
End Of Frame
10010
Intermission (go buy popcorn)
10001
Active Error Flag
10110
Passive Error Flag
10011
Tolerate DOM bits
10111
Error Delimiter
11100
Overload Flag
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.
2000 Jan 25
49