Datasheet MCP2515 Datasheet

M

Stand-Alone CAN Controller With SPI™ Interface

MCP2515

Features

• Implements CAN V2.0B at 1 Mb/s:

- 0 - 8 byte length in the data field

- Standard and extended data and remote
frames

• Receive buffers, masks and filters:

- Two receive buffers with prioritized message
storage

- Six 29-bit filters

- Two 29-bit masks

• Data byte filtering on the first two data bytes
(applies to standard data frames)

• Three transmit buffers with prioritizaton and abort
features.

• High-Speed SPI™ Interface (10 MHz):

- SPI modes 0,0 and 1,1

• One-shot mode ensures message transmission is
attempted only one time

• Clock out pin with programmable prescaler:

- Can be used as a clock source for other

device(s)

• Start-of-Frame (SOF) signal is available for
monitoring the SOF signal:

- Can be used for time-slot-based protocols

and/or bus diagnostics to detect early bus
degredation

• Interrupt output pin with selectable enables

• Buffer Full output pins configurable as:

- Interrupt output for each receive buffer

- General purpose output

• Request-to-Send (RTS) input pins individually
configurable as:

- Control pins to request transmission for each

transmit buffer

- General purpose inputs

• Low power CMOS technology:

- Operates from 2.7V - 5.5V

- 5 mA active current (typical)

- 1 µA standby current (typical) (Sleep mode)

• Temperature ranges supported:

- Industrial (I): -40°C to +85°C

- Extended (E): -40°C to +125°C

Description

Microchip Technology’s MCP2515 is a stand-alone
Controller Area Network (CAN) controller that imple­ments the CAN specification, version 2.0B. It is capable
of transmitting and receiving both standard and
extended data and remote frames. The MCP2515 has
two acceptance masks and six acceptance filters that
are used to filter out unwanted messages, thereby
reducing the host MCUs overhead. The MCP2515
interfaces with MCUs via an industry standard Serial
Peripheral Interface (SPI™).

Package Types

PDIP/SOIC

TXCAN

RXCAN

CLKOUT/SOF

TX0RTS

TX1RTS

TX2RTS

OSC2

OSC1

Vss

20 LEAD TSSOP

TXCAN

RXCAN

CLKOUT/SOF

TX0RTS
TX1RTS

NC

TX2RTS

OSC2
OSC1

SS

V

10

1

2

3

MCP2515

4

5

6

7

8

9

1
2

MCP2515

3
4
5
6
7
8
9

18

17

16

15

14

13

12

11

10

20
19
18
17

16
15
14
13
12
11

DD

V

RESET

CS

SO

SI

SCK

INT

RX0BF

RX1BF

DD

V
RESET
CS

SO
SI
NC
SCK
INT
RX0BF
RX1BF

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 1

MCP2515

NOTES:

DS21801B-page 2

Preliminary  2003 Microchip Technology Inc.

MCP2515

1.0 DEVICE OVERVIEW

The MCP2515 is a stand-alone CAN controller
developed to simplify applications that require
interfacing with a CAN bus. A simple block diagram of
the MCP2515 is shown in Figure 1-1. The device
consists of three main blocks:

1. The CAN module, which includes the CAN pro-

tocol engine, masks, filters, transmits and
receives buffers

2. The control logic and registers that are used to

configure the device and its operation

3. The SPI protocol block

An example system implementation using the device is
shown in Figure 1-2.

1.1 CAN Module

The CAN module handles all functions for receiving
and transmitting messages on the CAN bus. Messages
are transmitted by first loading the appropriate
message buffer and control registers. Transmission is
initiated by using control register bits, via the SPI
interface or by using the transmit enable pins. Status
and errors can be checked by reading the appropriate
registers. Any message detected on the CAN bus is
checked for errors and then matched against the user­defined filters to see if it should be moved into one of
the two receive buffers.

1.2 Control Logic

The control logic block controls the setup and operation
of the MCP2515 by interfacing to the other blocks in
order to pass information and control.

Interrupt pins are provided to allow greater system
flexibility. There is one multi-purpose interrupt pin, as
well as specific interrupt pins, for each of the receive
registers that can be used to indicate a valid message
has been received and loaded into one of the receive
buffers. Use of the specific interrupt pins is optional.
The general purpose interrupt pin, as well as status
registers (accessed via the SPI interface), can also be
used to determine when a valid message has been
received.

Additionally, there are three pins available to initiate
immediate transmission of a message that has been
loaded into one of the three transmit registers. Use of
these pins is optional and initiating message
transmission can also be accomplished by utilizing
control registers, accessed via the SPI interface.

1.3 SPI Protocol Block

The MCU interfaces to the device via the SPI interface.
Writing to, and reading from, all registers is
accomplished using standard SPI read and write
commands in addition to specialized SPI commands.

FIGURE 1-1: BLOCK DIAGRAM

CAN Module

RXCAN

CAN

Protocol

Engine

TXCAN

OSC1

OSC2

CLKOUT

Timi ng

Generation

Control

and

Interrupt

Registers

TX and R X Buffers

Masks and Filters

Control Logic

SPI™

Interface

Logic

CS
SCK
SI

SO

INT

RX0BF

RX1BF

TX0RTS

TX1RTS

TX2RTS

RESET

SPI
Bus

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 3

MCP2515

FIGURE 1-2: EXAMPLE SYSTEM IMPLEMENTATION

CANH

CANL

Node

Controller

SPI™

MCP2515

TX

XCVR

RX

Node

Controller

SPI™

MCP2515

TX

XCVR

RX

Node

Controller

SPI™

MCP2515

TX

XCVR

TABLE 1-1: PINOUT DESCRIPTION

Name

TXCAN 1 1 O Transmit output pin to CAN bus

RXCAN 2 2 I Receive input pin from CAN bus

CLKOUT 3 3 O Clock output pin with programmable

TX0RTS

TX1RTS 5 5 I Transmit buffer TXB1 request-to-send.

TX2RTS 6 7 I Transmit buffer TXB2 request-to-send.

OSC2 7 8 O Oscillator output —

OSC1 8 9 I Oscillator input External clock input

V

RX1BF

RX0BF

INT

SCK 13 14 I Clock input pin for SPI interface —

SO 15 17 O Data output pin for SPI interface —

CS

RESET

V

NC — 6,15 — No internal connection

Note: Type Identification: I = Input; O = Output; P = Power

DIP/SOIC

Pin #

SS 9 10 P Ground reference for logic and I/O pins —

SI 14 16 I Data input pin for SPI interface —

DD 18 20 P Positive supply for logic and I/O pins —

TSSOP

Pin #

4 4 I Transmit buffer TXB0 request-to-send.

10 11 O Receive buffer RXB1 interrupt pin or

11 12 O Receive buffer RXB0 interrupt pin or

12 13 O Interrupt output pin —

16 18 I Chip select input pin for SPI interface —

17 19 I Active low device reset input —

I/O/P
Type

Description Alternate Pin Function

prescaler

100 kΩ internal pull-up to V

100 kΩ internal pull-up to V

100 kΩ internal pull-up to V

general purpose digital output

general purpose digital output

DD

DD

DD

Start-of-Frame signal

General purpose digital input.
100 kΩ internal pull-up to V

General purpose digital input.
100 kΩ internal pull-up to V

General purpose digital input.
100 kΩ internal pull-up to V

General purpose digital output

General purpose digital output

RX

DD

DD

DD

DS21801B-page 4

Preliminary  2003 Microchip Technology Inc.

1.4 Transmit/Receive Buffers/Masks/

Filters

The MCP2515 has three transmit and two receive
buffers, two acceptance masks (one for each receive
buffer) and a total of six acceptance filters. Figure 1-3
shows a block diagram of these buffers and their
connection to the protocol engine.

FIGURE 1-3: CAN BUFFERS AND PROTOCOL ENGINE BLOCK DIAGRAM

MCP2515

BUFFERS

TXB0

TXREQ

ABTF

MLOA

TXERR

MESSAGE

Message

Queue
Control

PROTOCOL
ENGINE

TXB1

TXREQ

ABTF

MLOA

TXERR

MESSAGE

Transmit Byte Sequencer

{Transmit<5:0>, Receive<8:0>}

TXREQ

Shift<14:0>

TXB2

ABTF

MLOA

TXERR

A
c
c
e
p

MESSAGE

t

Comparator

CRC<14:0>

Acceptance Mask

RXM0

Acceptance Filter

Acceptance Filter

R
X
B
0

Identifier

Data Field Data Field

Receive<7:0>Transm it<7:0>

RXF0

RXF1

Acceptance Mask

Acceptance Filter

Acceptance Filter

Acceptance Filter

Acceptance Filter

M

Identifier

A
B

RXM1

RXF2

RXF3

RXF4

RXF5

Receive

Error

Counter

Transm it

Error

Counter

Protocol

Finite

State

Machine

A
c
c
e
p
t

R
X
B
1

REC

TEC

ErrPas
BusOff

SOF

Transm it

Logic

TX RX

 2003 Microchip Technology Inc. Preliminary

Bit

Timing

Logic

Clock

Generator

Configuration

Regist ers

DS21801B-page 5

MCP2515

1.5 CAN Protocol Engine

The CAN protocol engine combines several functional
blocks, shown in Figure 1-4 and described below.

1.5.1 PROTOCOL FINITE STATE
MACHINE

The heart of the engine is the Finite State Machine
(FSM). The FSM is a sequencer controlling the
sequential data stream between the TX/RX shift
register, the CRC register and the bus line. The FSM
also controls the Error Management Logic (EML) and
the parallel data stream between the TX/RX shift
registers and the buffers. The FSM ensures that the
processes of reception, arbitration, transmission and
error signaling are performed according to the CAN
protocol. The automatic retransmission of messages
on the bus line is also handled by the FSM.

1.5.2 CYCLIC REDUNDANCY CHECK

The Cyclic Redundancy Check register generates the
Cyclic Redundancy Check (CRC) code, which is
transmitted after either the Control Field (for messages
with 0 data bytes) or the Data Field and is used to
check the CRC field of incoming messages.

1.5.3 ERROR MANAGEMENT LOGIC

The Error Management Logic is responsible for the
fault confinement of the CAN device. Its two counters,
the Receive Error Counter (REC) and the Transmit
Error Counter (TEC), are incremented and
decremented by commands from the bit stream
processor. According to the values of the error
counters, the CAN controller is set into the states error­active, error-passive or bus-off.

1.5.4 BIT TIMING LOGIC

The Bit Timing Logic (BTL) monitors the bus line input
and handles the bus related bit timing according to the
CAN protocol. The BTL synchronizes on a recessive­to-dominant bus transition at Start-of-Frame (hard syn­chronization) and on any further recessive-to-dominant
bus line transition if the CAN controller itself does not
transmit a dominant bit (resynchronization). The BTL
also provides programmable time segments to
compensate for the propagation delay time, phase
shifts and to define the position of the sample point
within the bit time. The programming of the BTL
depends on the baud rate and external physical delay
times.

FIGURE 1-4: CAN PROTOCOL ENGINE BLOCK DIAGRAM

Rx

Sample<2:0>

Majority

Decision

Receive<7:0> Transm it<7:0>

Bit Timing Logic

SAM

StuffReg<5:0>

BusMon

Comparator

CRC<14:0>

Comparator

Shift<14:0>

(Transmit<5:0>, Receive<7:0>)

Transmit Logic

Receive

Error Counter

Transmit

Error Counter

Protocol

FSM

Tx

REC

TEC

ErrPas

BusOff

SOF

DS21801B-page 6

RecData<7:0>

Interface to Standard Buffer

TrmData<7:0>

Rec/Trm Addr.

Preliminary  2003 Microchip Technology Inc.

MCP2515

2.0 CAN MESSAGE FRAMES

The MCP2515 supports Standard Data Frames,
Extended Data Frames and Remote Frames (standard
and extended) as defined in the CAN 2.0B
specification.

2.1 Standard Data Frame

The CAN Standard Data Frame is shown in Figure 2-1.
In common with all other frames, the frame begins with
a Start-Of-Frame (SOF) bit, which is of the dominant
state and allows hard synchronization of all nodes.

The SOF is followed by the arbitration field, consisting
of 12 bits: the 11-bit ldentifier and the Remote
Transmission Request (RTR) bit. The RTR bit is used
to distinguish a data frame (RTR bit dominant) from a
remote frame (RTR bit recessive).

Following the arbitration field is the control field,
consisting of six bits. The first bit of this field is the
Identifier Extension (IDE) bit, which must be dominant
to specify a standard frame. The following bit,
Reserved Bit Zero (RB0), is reserved and is defined as
a dominant bit by the CAN protocol. The remaining four
bits of the control field are the Data Length Code
(DLC), which specifies the number of bytes of data
(0 - 8 bytes) contained in the message.

After the control field is the data field, which contains
any data bytes that are being sent, and is of the length
defined by the DLC (0 - 8 bytes).

The Cyclic Redundancy Check (CRC) field follows the
data field and is used to detect transmission errors. The
CRC Field consists of a 15-bit CRC sequence, followed
by the recessive CRC Delimiter bit.

The final field is the two-bit Acknowledge (ACK) field.
During the ACK Slot bit, the transmitting node sends
out a recessive bit. Any node that has received an
error-free frame acknowledges the correct reception of
the frame by sending back a dominant bit (regardless
of whether the node is configured to accept that
specific message or not). The recessive acknowledge
delimiter completes the acknowledge field and may not
be overwritten by a dominant bit.

2.2 Extended Data Frame

In the Extended CAN Data Frame, shown in
Figure 2-2, the SOF bit is followed by the arbitration
field, which consists of 32 bits. The first 11 bits are the
most significant bits (Base-lD) of the 29-bit identifier.
These 11 bits are followed by the Substitute Remote
Request (SRR) bit, which is defined to be recessive.
The SRR bit is followed by the lDE bit, which is
recessive to denote an extended CAN frame.

It should be noted that if arbitration remains unresolved
after transmission of the first 11 bits of the identifier, and
one of the nodes involved in the arbitration is sending
a standard CAN frame (11-bit identifier), the standard

CAN frame will win arbitration due to the assertion of a
dominant lDE bit. Also, the SRR bit in an extended
CAN frame must be recessive to allow the assertion of
a dominant RTR bit by a node that is sending a
standard CAN remote frame.

The SRR and lDE bits are followed by the remaining
18 bits of the identifier (Extended lD) and the remote
transmission request bit.

To enable standard and extended frames to be sent
across a shared network, the 29-bit extended message
identifier is split into 11-bit (most significant) and 18-bit
(least significant) sections. This split ensures that the
lDE bit can remain at the same bit position in both
standard and extended frames.

Following the arbitration field is the six-bit control field.
The first two bits of this field are reserved and must be
dominant. The remaining four bits of the control field
are the Data Length Code (DLC), which specifies the
number of data bytes contained in the message.

The remaining portion of the frame (data field, CRC
field, acknowledge field, end-of-frame and intermis­sion) is constructed in the same way as for a standard
data frame (see Section 2.1, “Standard Data

Frame”).

2.3 Remote Frame

Normally, data transmission is performed on an
autonomous basis by the data source node (e.g., a
sensor sending out a data frame). It is possible,
however, for a destination node to request data from
the source. To accomplish this, the destination node
sends a remote frame with an identifier that matches
the identifier of the required data frame. The
appropriate data source node will then send a data
frame in response to the remote frame request.

There are two differences between a remote frame
(shown in Figure 2-3) and a data frame. First, the RTR
bit is at the recessive state and, second, there is no
data field. In the event of a data frame and a remote
frame with the same identifier being transmitted at the
same time, the data frame wins arbitration due to the
dominant RTR bit following the identifier. In this way,
the node that transmitted the remote frame receives
the desired data immediately.

2.4 Error Frame

An Error Frame is generated by any node that detects
a bus error. An error frame, shown in Figure 2-4,
consists of two fields, an error flag field followed by an
error delimiter field. There are two types of error flag
fields. Which type of error flag field is sent depends
upon the error status of the node that detects and
generates the error flag field.

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 7

MCP2515

2.4.1 ACTIVE ERRORS

If an error-active node detects a bus error, the node
interrupts transmission of the current message by
generating an active error flag. The active error flag is
composed of six consecutive dominant bits. This bit
sequence actively violates the bit-stuffing rule. All other
stations recognize the resulting bit-stuffing error and, in
turn, generate error frames themselves, called error
echo flags.

The error flag field, therefore, consists of between six
and twelve consecutive dominant bits (generated by
one or more nodes). The error delimiter field (eight
reccessive bits) completes the error frame. Upon
completion of the error frame, bus activity returns to
normal and the interrupted node attempts to resend the
aborted message.

Note: Error echo flags typically occur when a

localized disturbance causes one or more
(but not all) nodes to send an error flag.
The remaining nodes generate error flags
in response (echo) to the original error
flag.

2.4.2 PASSIVE ERRORS

If an error-passive node detects a bus error, the node
transmits an error-passive flag followed by the error
delimiter field. The error-passive flag consists of six
consecutive recessive bits and the error frame for an
error-passive node consists of 14 recessive bits. From
this it follows that, unless the bus error is detected by an
error-active node or the transmitting node, the message
will continue transmission because the error-passive
flag does not interfere with the bus.

If the transmitting node generates an error-passive
flag, it will cause other nodes to generate error frames
due to the resulting bit-stuffing violation. After
transmission of an error frame, an error-passive node
must wait for six consecutive recessive bits on the bus
before attempting to rejoin bus communications.

The error delimiter consists of eight recessive bits and
allows the bus nodes to restart bus communications
cleanly after an error has occurred.

overload delimiter consists of eight recessive bits. An
overload frame can be generated by a node as a result
of two conditions:

1. The node detects a dominant bit during the
interframe space which is an illegal condition.
Exception: the dominant is detected during the
third bit of IFS. In this case, the receivers will
interpret this as a SOF.

2. Due to internal conditions, the node is not yet
able to start reception of the next message. A
node may generate a maximum of two
sequential overload frames to delay the start of
the next message.

Note: Case 2 should never occur with the

MCP2515 due to very short internal
delays.

2.6 Interframe Space

The lnterframe Space separates a preceding frame (of
any type) from a subsequent data or remote frame.
The interframe space is composed of at least three
recessive bits called the Intermission. This allows
nodes time for internal processing before the start of
the next message frame. After the intermission, the
bus line remains in the recessive state (bus idle) until
the next transmission starts.

2.5 Overload Frame

An Overload Frame, shown in Figure 2-5, has the
same format as an active error frame. An overload
frame, however, can only be generated during an
interframe space. In this way, an overload frame can be
differentiated from an error frame (an error frame is
sent during the transmission of a message). The
overload frame consists of two fields, an overload flag
followed by an overload delimiter. The overload flag
consists of six dominant bits followed by overload flags
generated by other nodes (and, as for an active error
flag, giving a maximum of twelve dominant bits). The

DS21801B-page 8

Preliminary  2003 Microchip Technology Inc.

FIGURE 2-1: STANDARD DATA FRAME

7

End-of-

MCP2515

IFS

1 1 11

Frame

ACK Del

1 1 1 1 1 1 1

Ack Slot Bit

CRC Del

1

16

8N (0≤N≤8)

Data Frame (number of bits = 44 + 8N)

6

15

CRC Field

Data Field

Control

CRC

8

Bit-stuffing

8

DLC0

4

Field

DLC3
RB0
IDE
RTR
ID0

Data

Length

0
0

Stored in Transmit/Receive Buffers

Code

Reserved Bit

ID3

12

 2003 Microchip Technology Inc. Preliminary

11

Arbitration Field

ID 10

Start-of-Frame

0 0

Identifier

Message

Stored in Buffers

Filtering

DS21801B-page 9

MCP2515

FIGURE 2-2: EXTENDED DATA FRAME

7

End-of-

Frame

16

15

CRC Field

CRC

IFS

1 1 1

ACK Del

1 1 1 1 1 1 1 1

Ack Slot Bit

CRC Del

Data Field

8N (0≤N≤8)

8 8

DLC0

Data Frame (number of bits = 64 + 8N)

6

32

4

DLC3

Control

Field

18

Arbitration Field

RB0
RB1
RTR
EID0

EID17
IDE
SRR
ID0

ID3

Data

Length

Extended Identifier

Stored in Transmit/Receive Buffers

Code

Reserved bits

Bit-stuffing

Stored in Buffers

DS21801B-page 10

11

Message

Filtering

Identifier

ID10
Start-Of-Frame

0 1 1 0 0 0 1

Preliminary  2003 Microchip Technology Inc.

FIGURE 2-3: REMOTE FRAME

16

MCP2515

IFS

1 1 1

7

End-of-

Frame

ACK Del
Ack Slot Bit

CRC Del

1 1 1 1 1 1 1 1 1

15

CRC Field

CRC

6

32

DLC0

No data field

4

DLC3

Control

Field

18

Arbitration Field

11

RB0
RB1
RTR
EID0

EID17
IDE
SRR
ID0

ID3

Data

Length

Code

Reserved bits

Extended Identifier

Message

Filtering

Identifier

ID10
Start-Of-Frame

0 1 1 1 0 0

 2003 Microchip Technology Inc. Preliminary

Remote Frame with Extended Identifier

DS21801B-page 11

MCP2515

FIGURE 2-4: ACTIVE ERROR FRAME

Inter-Frame Space or

Overload Frame

8

Error

Delimiter

0 1 1 1 1 1 1 1 1 0
0

Error Frame

£ 6

Echo

Error

Flag

6

Error

Flag

0 0 0 0 0 0 0

8

Data Frame or

Remote Frame

Data Field

8N (0≤N≤8)

8

DLC0

Interrupted Data Frame

6

4

Control

Field

DLC3
RB0
IDE
RTR
ID0

ID3

Data

Length

Code

0

0

Bit-stuffing

Reserved Bit

DS21801B-page 12

12

11

Arbitration Field

ID 10

Start-Of-Frame

Identifier

Message

Filtering

0 0

Preliminary  2003 Microchip Technology Inc.

FIGURE 2-5: OVERLOAD FRAME

MCP2515

Inter-Frame Space or

Error Frame

8

Overload

Delimiter

Overload Frame

6

Overload

Flag

0 0 0 0 0 0 0 1 1 1 1 1 1 1 1

7

End-of-

Frame

ACK Del

1 1 1 1 1 1 1 1

Ack Slot Bit

CRC Del

1

End-of-frame or

Error Delimiter or

Overload Delimiter

16

Remote Frame (number of bits = 44)

6

12

15

CRC Field

Control

CRC

DLC0

4

Field

DLC3
RB0

0

IDE

0

RTR
ID0

11

Arbitration Field

ID 10

Start-Of-Frame

0 1

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 13

MCP2515

NOTES:

DS21801B-page 14

Preliminary  2003 Microchip Technology Inc.

MCP2515

3.0 MESSAGE TRANSMISSION

3.1 Transmit Buffers

The MCP2515 implements three transmit buffers. Each
of these buffers occupies 14 bytes of SRAM and are
mapped into the device memory map.

The first byte, TXBnCTRL, is a control register
associated with the message buffer. The information in
this register determines the conditions under which the
message will be transmitted and indicates the status of
the message transmission (see Register 3-1).

Five bytes are used to hold the standard and extended
identifiers, as well as other message arbitration
information (see Register 3-3 through Register 3-7).
The last eight bytes are for the eight possible data
bytes of the message to be transmitted (see
Register 3-8).

At a minimum, the TXBnSIDH, TXBnSIDL and
TXBnDLC registers must be loaded. If data bytes are
present in the message, the TXBnDm registers must
also be loaded. If the message is to use extended
identifiers, the TXBnEIDm registers must also be
loaded and the TXBnSIDL.EXIDE bit set.

Prior to sending the message, the MCU must initialize
the CANINTE.TXInE bit to enable or disable the
generation of an interrupt when the message is sent.

Note: The TXBnCTRL.TXREQ bit must be clear

(indicating the transmit buffer is not pend­ing transmission) before writing to the
transmit buffer.

3.2 Transmit Priority

Transmit priority is a prioritization, within the
MCP2515, of the pending transmittable messages.
This is independent from, and not necessarily related
to, any prioritization implicit in the message arbitration
scheme built into the CAN protocol.

Prior to sending the SOF, the priority of all buffers that
are queued for transmission is compared. The transmit
buffer with the highest priority will be sent first. For
example, if transmit buffer 0 has a higher priority setting
than transmit buffer 1, buffer 0 will be sent first.

If two buffers have the same priority setting, the buffer
with the highest buffer number will be sent first. For
example, if transmit buffer 1 has the same priority
setting as transmit buffer 0, buffer 1 will be sent first.

There are four levels of transmit priority. If
TXBnCTRL.TXP<1:0> for a particular message buffer
is set to 11, that buffer has the highest possible priority.
If TXBnCTRL.TXP<1:0> for a particular message
buffer is 00, that buffer has the lowest possible priority.

3.3 Initiating Transmission

In order to initiate message transmission, the
TXBnCTRL.TXREQ bit must be set for each buffer to
be transmitted. This can be accomplished by:

• Writing to the register via the SPI write command.

• Sending the SPI RTS command

• Setting the TX

transmit buffer(s) that are to be transmitted.

If transmission is initiated via the SPI interface, the
TXREQ bit can be set at the same time as the TXP
priority bits.

When TXBnCTRL.TXREQ is set, the TXBnCTRL.ABTF,
TXBnCTRL.MLOA and TXBnCTRL.TXERR bits will be
cleared automatically.

Note: Setting the TXBnCTRL.TXREQ bit does

Once the transmission has completed successfully, the
TXBnCTRL.TXREQ bit will be cleared, the
CANINTF.TXnIF bit will be set and an interrupt will be
generated if the CANINTE.TXnIE bit is set.

If the message transmission fails, the
TXBnCTRL.TXREQ will remain set. This indicates that
the message is still pending for transmission and one
of the following condition flags will be set:

• If the message started to transmit but

encountered an error condition, the
TXBnCTRL.TXERR and the CANINTF.MERRF
bits will be set and an interrupt will be generated
on the INT

• If the message is lost, arbitration at the

TXBnCTRL.MLOA bit will be set

Note: If One-shot mode is enabled

nRTS pin low for the particular

not initiate a message transmission. It
merely flags a message buffer as ready for
transmission. Transmission will start when
the device detects that the bus is
available.

pin if the CANINTE.MERRE bit is set.

(CANCTRL.OSM), the above conditions
will still exist. However, the TXREQ bit will
be cleared and the message will not
attempt transmission a second time.

3.4 One-Shot Mode

One-shot mode ensures that a message will only
attempt to transmit one time. Normally, if a CAN
message loses arbitration or is destroyed by an error
frame, the message is retransmitted. With One-shot
mode enabled, a message will only attempt to transmit
one time, regardless of arbitration loss or error frame.

One-shot mode is required to maintain time slots in
deterministic systems, such as TTCAN.

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 15

MCP2515

3.5 TXnRTS PINS

The TXnRTS pins are input pins that can be configured
as:

• request-to-send inputs, which provides an
alternative means of initiating the transmission of
a message from any of the transmit buffers

• standard digital inputs

Configuration and control of these pins is accomplished
using the TXRTSCTRL register (see Register 3-2). The
TXRTSCTRL register can only be modified when the
MCP2515 is in Configuration mode (see Section 9.0,
“Modes of Operation”). If configured to operate as a
request-to-send pin, the pin is mapped into the
respective TXBnCTRL.TXREQ bit for the transmit
buffer. The TXREQ bit is latched by the falling edge of
the TX

nRTS pin. The TXnRTS pins are designed to
allow them to be tied directly to the RX
automatically initiate a message transmission when the
RX

nBF pin goes low.

The TX
100 kΩ (nominal).

nRTS pins have internal pull-up resistors of

nBF pins to

3.6 Aborting Transmission

The MCU can request to abort a message in a specific
message buffer by clearing the associated
TXBnCTRL.TXREQ bit.

In addition, all pending messages can be requested to
be aborted by setting the CANCTRL.ABAT bit. This bit
MUST be reset (typically after the TXREQ bits have
been verified to be cleared) to continue transmitting
messages. The CANCTRL.ABTF flag will only be set if
the abort was requested via the CANCTRL.ABAT bit.
Aborting a message by resetting the TXREQ bit does
NOT cause the ABTF bit to be set.

Note: Messages that are currently transmitting

when the abort was requested will
continue to transmit. If the message does
not successfully complete transmission
(i.e., lost arbitration or was interrupted by
an error frame), it will then be aborted.

DS21801B-page 16

Preliminary  2003 Microchip Technology Inc.

FIGURE 3-1: TRANSMIT MESSAGE FLOWCHART

MCP2515

Start

No

Examine TXBnCTRL.TXP <1:0> to
Determine Highest Priority Message

Are any

TXBnCTRL.TXREQ

bits = 1

?

Yes

Clear:

TXBnCTRL.ABTF
TXBnCTRL.MLOA
TXBnCTRL.TXERR

Is

CAN bus availabl e

to start transmission ?

Yes

Transmit Message

No

The message transmi ssion
sequence begins when the
device determines that the
TXBnCTRL.TXREQ for any of
the transmit register s has been
set.

Clearing the TxBnCTRL.TXREQ bit
while it is set, or setting the CAN­CTRL.ABAT bit before the message
has started transmission, will abort
the message.

TXBnCTRL.TXREQ=0

is

or

CANCTRL.ABAT=1

?

Yes

No

Generate

Interrupt

The CANINTE.TXnIE bit
determines if an interrupt
should be gen erated when
a message is successfully
transmitted.

Was

Message Transmitted

Successfully?

Yes

Clear TxBnCTRL.TXREQ

Yes

CANINTE.TXnIE=1?

No

Set

CANTINF.TXnIF

GOTO START

No

Message error

or

Lost arbitration

?

Lost
Arbitration

Set

TxBNCTRL.MLOA

Message
Error

Set

TxBnCTRL.TXERR

CANINTE.MEERE?

No

Set

CANTINF.MERRF

Yes

Generate

Interrupt

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 17

MCP2515

REGISTER 3-1: TXBnCTRL - TRANSMIT BUFFER n CONTROL REGISTER

(ADDRESS: 30h, 40h, 50h)

U-0 R-0 R-0 R-0 R/W-0 U-0 R/W-0 R/W-0

— ABTF MLOA TXERR TXREQ — TXP1 TXP0

bit 7 bit 0

bit 7 Unimplemented: Read as “0”

bit 6 ABTF: Message Aborted Flag

1 = Message was aborted
0 = Message completed transmission successfully

bit 5 MLOA: Message Lost Arbitration

1 = Message lost arbitration while being sent
0 = Message did not lose arbitration while being sent

bit 4 TXERR: Transmission Error Detected

1 = A bus error occurred while the message was being transmitted
0 = No bus error occurred while the message was being transmitted

bit 3 TXREQ: Message Transmit Request

1 = Buffer is currently pending transmission

(MCU sets this bit to request message be transmitted - bit is automatically cleared when
the message is sent)

0 = Buffer is not currently pending transmission

(MCU can clear this bit to request a message abort)

bit 2 Unimplemented: Read as “0”

bit 1-0 TXP<1:0>: Transmit Buffer Priority

11 = Highest Message Priority
10 = High Intermediate Message Priority
11 = Low Intermediate Message Priority
00 = Lowest Message Priority

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR “1” = Bit is set “0” = Bit is cleared x = Bit is unknown

DS21801B-page 18

Preliminary  2003 Microchip Technology Inc.

MCP2515

REGISTER 3-2: TXRTSCTRL - TXnRTS PIN CONTROL AND STATUS REGISTER

(ADDRESS: 0Dh)

U-0 U-0 R-x R-x R-x R/W-0 R/W-0 R/W-0

— — B2RTS B1RTS B0RTS B2RTSM B1RTSM B0RTSM

bit 7 bit 0

bit 7 Unimplemented: Read as '0'

bit 6 Unimplemented: Read as '0'

bit 5 B2RTS: TX2RTS

- Reads state of TX2RTS

- Reads as ‘0’ when pin is in ‘request-to-send’ mode

bit 4 B1RTS: TX1RTX

- Reads state of TX1RTS

- Reads as ‘0’ when pin is in ‘Request-to-Send’ mode

bit 3 B0RTS: TX0RTS

- Reads state of TX0RTS

- Reads as ‘0’ when pin is in ‘Request-to-Send’ mode

bit 2 B2RTSM: TX2RTS

1 = Pin is used to request message transmission of TXB2 buffer (on falling edge)
0 = Digital input

bit 1 B1RTSM: TX1RTS

1 = Pin is used to request message transmission of TXB1 buffer (on falling edge)
0 = Digital input

bit 0 B0RTSM: TX0RTS

1 = Pin is used to request message transmission of TXB0 buffer (on falling edge)
0 = Digital input

Pin State

pin when in Digital Input mode

Pin State

pin when in Digital Input mode

Pin State

pin when in Digital Input mode

Pin mode

Pin mode

Pin mode

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

REGISTER 3-3: TXBnSIDH - TRANSMIT BUFFER n STANDARD IDENTIFIER HIGH

(ADDRESS: 31h, 41h, 51h)

R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x

SID10SID9SID8SID7SID6SID5SID4SID3

bit 7 bit 0

bit 7-0 SID<10:3>: Standard Identifier Bits <10:3>

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 19

MCP2515

REGISTER 3-4: TXBnSIDL - TRANSMIT BUFFER n STANDARD IDENTIFIER LOW

(ADDRESS: 32h, 42h, 52h)

R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x

SID2 SID1 SID0

bit 7 bit 0

bit 7-5 SID<2:0>: Standard Identifier Bits <2:0>

bit 4 Unimplemented: Reads as '0’

bit 3 EXIDE: Extended Identifier Enable

1 = Message will transmit extended identifier
0 = Message will transmit standard identifier

bit 2 Unimplemented: Reads as '0’

bit 1-0 EID<17:16>: Extended Identifier Bits <17:16>

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

— EXIDE —EID17EID16

REGISTER 3-5: TXBnEID8 - TRANSMIT BUFFER n EXTENDED IDENTIFIER HIGH

(ADDRESS: 33h, 43h, 53h)

R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x

EID15 EID14 EID13 EID12 EID11 EID10 EID9 EID8

bit 7 bit 0

bit 7-0 EID<15:8>: Extended Identifier Bits <15:8>

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

REGISTER 3-6: TXBnEID0 - TRANSMIT BUFFER n EXTENDED IDENTIFIER LOW

(ADDRESS: 34h, 44h, 54h)

R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x

EID7 EID6 EID5 EID4 EID3 EID2 EID1 EID0

bit 7 bit 0

bit 7-0 EID<7:0>: Extended Identifier Bits <7:0>

DS21801B-page 20

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

Preliminary  2003 Microchip Technology Inc.

REGISTER 3-7: TXBnDLC - TRANSMIT BUFFER n DATA LENGTH CODE

(ADDRESS: 35h, 45h, 55h)

R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x

—RTR— — DLC3 DLC2 DLC1 DLC0

bit 7 bit 0

bit 7 Unimplemented: Reads as '0’

bit 6 RTR: Remote Transmission Request Bit

1 = Transmitted Message will be a Remote Transmit Request
0 = Transmitted Message will be a Data Frame

bit 5-4 Unimplemented: Reads as '0’

bit 3-0 DLC<3:0>: Data Length Code

Sets the number of data bytes to be transmitted (0 to 8 bytes)

Note: It is possible to set the DLC to a value greater than 8, however only 8 bytes are trans-

mitted

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

MCP2515

REGISTER 3-8: TXBnDm - TRANSMIT BUFFER n DATA BYTE m

(ADDRESS: 36h - 3Dh, 46h - 4Dh, 56h - 5Dh)

R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x R/W-x

TXBnDm7TXBnDm6TXBnDm5TXBnDm4TXBnDm3TXBnDm2TXBnDm1TXBnDm

bit 7 bit 0

bit 7-0 TXBnD

Legend:

R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’

-n = Value at POR ’1’ = Bit is set ’0’ = Bit is cleared x = Bit is unknown

7:TXBnDM0: Transmit Buffer n Data Field Byte m

M

0

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 21

MCP2515

NOTES:

DS21801B-page 22

Preliminary  2003 Microchip Technology Inc.

MCP2515

4.0 MESSAGE RECEPTION

4.1 Receive Message Buffering

The MCP2515 includes two full receive buffers with
multiple acceptance filters for each. There is also a
separate Message Assembly Buffer (MAB) that acts as
a third receive buffer (see Figure 4-2).

4.1.1 MESSAGE ASSEMBLY BUFFER

Of the three Receive buffers, the MAB is always
committed to receiving the next message from the bus.
The MAB assembles all messages received. These
messages will be transferred to the RXBn buffers (See
Register 4-4 to Register 4-9), only if the acceptance
filter criteria is met.

4.1.2 RXB0 AND RXB1

The remaining two receive buffers are called RXB0 and
RXB1 and can receive a complete message from the
protocol engine via the MAB. The MCU can access one
buffer, while the other buffer is available for message
reception or holding a previously received message.

Note: The entire contents of the MAB is moved

into the receive buffer once a message is
accepted. This means that regardless of
the type of identifier (standard or
extended) and the number of data bytes
received, the entire receive buffer is
overwritten with the MAB contents.
Therefore, the contents of all registers in
the buffer must be assumed to have been
modified when any message is received.

4.1.3 RECEIVE FLAGS/INTERRUPTS

When a message is moved into either of the receive
buffers, the appropriate CANINTF.RXnIF bit is set. This
bit must be cleared by the MCU in order to allow a new
message to be received into the buffer. This bit
provides a positive lockout to ensure that the MCU has
finished with the message before the MCP2515
attempts to load a new message into the receive buffer.

If the CANINTE.RXnIE bit is set, an interrupt will be
generated on the INT
message has been received. In addition, the
associated RXnBF pin will drive low if configured as a
receive buffer full pin. See Section 4.4, “RX0BF and
RX1 Pins”, for details.

pin to indicate that a valid

4.2 Receive Priority

RXB0 is the higher priority buffer and has one mask
and two message acceptance filters associated with it.
The received message is applied to the mask and
filters for RXB0 first.

RXB1 is the lower priority buffer and has one mask and
four acceptance filters associated with it.

In addition to the message being applied to RB0 mask
and filters first, the lower number of acceptance filters
makes the match on RXB0 more restrictive and implies
a higher priority for that buffer.

When a message is received, bits <3:0> of the
RXBnCTRL register will indicate the acceptance filter
number that enabled reception, and whether the
received message is a remote transfer request.

4.2.1 ROLLOVER

Additionally, the RXB0CTRL register can be configured
such that if RXB0 contains a valid message and
another valid message is received, an overflow error
will not occur and the new message will be moved into
RXB1 regardless of the acceptance criteria of RXB1.

4.2.2 RXM BITS

The RXBnCTRL.RXM bits set special receive modes.
Normally, these bits are cleared to 00 to enable
reception of all valid messages as determined by the
appropriate acceptance filters. In this case, the
determination of whether or not to receive standard or
extended messages is determined by the
RFXnSIDL.EXIDE bit in the acceptance filter register.

If the RXBnCTRL.RXM bits are set to 01 or 10, the
receiver will accept only messages with standard or
extended identifiers, respectively. If an acceptance
filter has the RFXnSIDL.EXIDE bit set such that it does
not correspond with the RXBnCTRL.RXM mode, that
acceptance filter is rendered useless. These two
modes of RXBnCTRL.RXM bits can be used in
systems where it is known that only standard or
extended messages will be on the bus.

If the RXBnCTRL.RXM bits are set to 11, the buffer will
receive all messages, regardless of the values of the
acceptance filters. Also, if a message has an error
before the end-of-frame, that portion of the message
assembled in the MAB before the error frame will be
loaded into the buffer. This mode has some value in
debugging a CAN system and would not be used in an
actual system environment.

 2003 Microchip Technology Inc. Preliminary

DS21801B-page 23

MCP2515

4.3 Start-of-Frame Signal

If enabled, the Start-Of-Frame (SOF) signal is
generated on the SOF pin at the beginning of each
CAN message detected on the RXCAN pin.

The RXCAN pin monitors an idle bus for a recessive­to-dominant edge. If the dominant condition remains
until the sample point, the MCP2515 interprets this as
a SOF and a SOF pulse is generated. If the dominant
condition does not remain until the sample point, the
MCP2515 interprets this as a glitch on the bus and no
SOF signal is generated. Figure 4-1 illustrates SOF
signalling and glitch filtering.

As with One-shot mode, one use for SOF signaling is
for TTCAN type systems. In addition, by monitoring
both the RXCAN pin and the SOF pin, an MCU can
detect early physical bus problems by detecting small
glitches before they affect the CAN communications.

4.4 RX0BF and RX1BF Pins

In addition to the INT pin, which provides an interrupt
signal to the MCU for many different conditions, the
receive buffer full pins (RX0BF
used to indicate that a valid message has been loaded
into RXB0 or RXB1, respectively. The pins have three
different configurations (Register 4-1):

1. Disabled

2. Buffer Full Interrupt

3. Digital Output

and RX1BF) can be

4.4.1 DISABLED

The RXBnBF pins can be disabled to the high­impedance state by clearing BFPCTRL.BnBFE.

4.4.2 CONFIGURED AS BUFFER FULL

The RXBnBF pins can be configured to act as buffer full
interrupt pins or as standard digital outputs.
Configuration and status of these pins is available via
the BFPCTRL register (Register 4-3). When set to
operate in Interrupt mode (by setting BFPCTRL.BxBFE
and BFPCTRL.BxBFM bits), these pins are active-low
and are mapped to the CANINTF.RXnIF bit for each
receive buffer. When this bit goes high for one of the
receive buffers, indicating that a valid message has
been loaded into the buffer, the corresponding
RX

BnBF pin will go low. When the CANINTF.RXnIF bit
is cleared by the MCU, the corresponding interrupt pin
will go to the logic-high state until the next message is
loaded into the receive buffer.

FIGURE 4-1: START-OF-FRAME SIGNALING

Normal SOF Signaling

START-OF-FRAME BIT

RXCAN

SOF

Glitch Filtering

EXPECTED START-OF-FRAME BIT

Expected

RXCAN

SOF

Sample
Point

Sample
Point

ID BIT

BUS IDLE

DS21801B-page 24

Preliminary  2003 Microchip Technology Inc.