At91sam7 - Can

CAN
SAM7
Controller Area Network
04/15/11 1
CAN
CAN Agenda
 What is CAN ?
 Why CAN ?
 CAN Protocol
 CAN Higher Layer Protocols
 CAN Applications
 AT91 CAN Microcontrollers – Roadmap
04/15/11 2
CAN
What is CAN ?
 Controller Area Network
 Invented by Robert Bosch GmbH in 1980 for automotive
applications
 Asynchronous Serial Bus
 Simple 2-wire differential bus
 Absence of node addressing
• Message identifier specifies contents and priority
• Lowest message identifier has highest priority
 Non-destructive arbitration system by CSMA with collision
detection
 Multi-master / Broadcasting concept
 Sophisticated error detection & handling system
04/15/11 3
CAN
What is CAN ?
 The CAN is an ISO standard (ISO 11898) for serial communication
 Today CAN has gained widespread use:
 Industrial Automation
 Automotive, …etc.
 The CAN standard includes:
 Physical layer
 Data-link layer
• Some message types
• Arbitration rules for bus access
• Methods for fault detection and fault confinement
04/15/11 4
CAN
Why CAN ?
 Mature Standard
 CAN protocol more than 16 years
 Numerous CAN products and tools on the market
 Hardware implementation of the protocol
 Combination of error handling and fault confinement with high
transmission speed (up to 1Mb/s)
 Simple Transmission Medium
 Twisted pair of wires is the standard, but also just one wire will
work
 Other links works, too: Opto - or radio links
 Excellent Error Handling
 CRC error detection mechanism
 Fault Confinement
 Built-in feature to prevent faulty node to block system
 Most used protocol in industrial and automotive world
04/15/11 5
Protocol - CAN
CAN Protocol
04/15/11 6
Protocol - CAN
ISO-OSI Reference Model

7. Application Layer HLPs: CANopen, DeviceNet, OSEK/VDX
6. Presentation Layer
CAN Layers
5. Session Layer Partially Implemented

by High Layer
4. Transport Layer Protocol (HLP)
3. Network Layer
2. Data Link Layer

CAN Protocol
1. Physical Layer
04/15/11 7
Protocol - CAN
ISO-OSI Reference Model (2)
CAN Controller
CAN Transceiver
04/15/11 8
Protocol - CAN
CAN Bus Logic

‘1’ Recessive (r)
‘0’ Dominant (D)
Two logic states on the CAN bus
Node 1 Node 2 Node 3 Bus

D D D D Wired-AND Function
D D r D
D r D D
D r r D Bus in dominant state
r D D D
r D r D
r r D D
r r r r Bus in recessive state
or idle
04/15/11 9
Protocol - CAN
Typical CAN Node
TXD CAN_H
CAN Bus
µController CAN CAN
Controller Transceiver
RXD CAN_L
CAN Bus is a simple 2-wire differential serial bus

CAN Bus is terminated on each side by a 120 Ohm resistor
04/15/11 10
Protocol - CAN
CAN Bit Coding & Bit Stuffing

 Bit Coding : NRZ (Non-Return-To-Zero code) does not ensure enough edges
for synchronization
 Stuff Bits are inserted after 5 consecutive bits of the same level
 Stuff Bits have the inverse level of the previous bit.
 No deterministic encoding, frame length depends on transmitted data
Number of consecutive bits

with the same polarity
04/15/11 11
Protocol - CAN
CAN Bus Access and Arbitration:

CSMA/CD and AMP
 CSMA/CD: Carrier Sense Multiple Access / Collision Detection

 AMP: Arbitration by Message Priority
04/15/11 12
Protocol - CAN
CAN Bus Synchronization

 Hard synchronization at Start Of Frame bit
 Re-Synchronization on each Recessive to Dominant bit
04/15/11 13
Protocol - CAN
CAN Bit Construction

 CAN Bit Period  Four Time Segments
 Each Time Segment represents a number of Time Quanta (TQ)
 1 Time Quantum  1 period of CAN Controller Clock
 SYNC_SEG: synchronize the different nodes

 PROP_SEG: compensate for signal delays across the network
 PHASE_SEG1 & 2: compensate for edge phase errors
1 Bit Time  8 to 25 Time Quanta
04/15/11 14
Protocol - CAN
Relation between Baud Rate and Bus Length
04/15/11 15
Protocol - CAN
Frame Formats
 SOF: Start Of Frame

 CRC: Cyclic Redundancy Code
 ACK: Acknowledge
 EOF: End of Frame
 IFS: Inter Frame Space
04/15/11 16
Protocol - CAN
Frame Formats (2)

 CAN V2.0A Standard Frame: Identifier is 11 bits long
 CAN V2.0B Extended Frame: Identifier is 29 bits long
 ID: Identifier  SRR: Substitute Remote Request

 IDE: Identifier Extension  RB0/1: Reserved bits
 RTR: Remote Transmission Request  DLC: Data Length Code
Our CANs supports CAN V2.0A & CAN V2.0B Specification

04/15/11 17
Protocol - CAN
Frame Formats (3)

 Four different frame formats:
 Data Frame : RTR Dominant ‘0’
 Remote Frame : RTR Recessive ‘1’ and No Data Field
Data Frame has priority on Remote Frame
04/15/11 18
Protocol - CAN
Frame Formats (4)

 Error Frame: sent after a violation frame format
 Overload Frame: prevents data overflow from a slower CAN
Overload Frames are not really used
04/15/11 19
Protocol - CAN
Fault Confinement
 CAN Node Error States:

 Error Active: Normal state, node can send all frames (error frames
included)
 Error passive: Node can send all frames excluding error frames
 Bus off: Node is isolated from bus
 Internal Counters: TEC & REC

 TEC: Transmit Error Counter
 REC: Receive Error Counter
TEC and REC counters allows to prevent from faulty nodes
04/15/11 20
Protocol - CAN
Error Detection Analysis
 Error statistics depend on the entire environment

 Total number of nodes
 Physical layout
 EMI disturbance
 Automotive example
 2000 hours/year
 Baud rate: 500 kbps
 25% bus load
One undetected error every 1000 years !!!
04/15/11 21
HLP - CAN
CAN High Layer Protocols
04/15/11 22
HLP - CAN
HLP Definition
 CAN protocol defines only the physical and a low data link layer !
 The HLP defines:
 Start-up behavior
 Definition of message identifiers for the different nodes
 Flow control
 Transportation of messages > 8bytes
 Definition of contents of Data Frames
 Status reporting in the system
One undetected error every 1000 years !!!
04/15/11 23
HLP - CAN
CANopen
 Features
 CANopen is a subset from CAL (CAN Application Layer) developed by CiA
 Auto configuration the network
 Easy access to all device parameters
 Device synchronization
 Cyclic and event-driven data transfer
 Synchronous reading or setting of inputs, outputs or parameters
 Applications
 Machine Automation
 Advantages
 Accommodating the integration of very small sensors and actuators
 Open and vendor independent
 Supports inter-operability of different devices
 High speed real-time capability
CiA (CAN in Automation)

04/15/11 24
HLP - CAN
DeviceNet
 Features
 Created by Allen-Bradley (Rockwell Automation nowadays), now
presented by the users group ODVA (Open DeviceNet Vendor
Association)
 Power and signal on the same network cable
 Bus addressing by: Peer-to-Peer with multi-cast & Multi-Master & Master-
Slave
 Supports only standard CAN
 Applications
 Advantages
 Low cost communication link and vendor independent
 Removal and replacement of devices from the network under power
CANopen (Europe) – DeviceNet (USA)

04/15/11 25
HLP - CAN
CAN Kingdom
 CAN Kingdom is more than a HLP (Meta Protocol):
 Introduced by KVASER, Sweden
 A ‘King’ (system designer) takes the full responsibility of the system
 The King is represented by the Capital (supervising node)s
 CAN Kingdom provides simple unique identification of system nodes
 Applications
 Advantages
 Designed for safety critical applications
 Real time performance
 Scalability
 Integration of DeviceNet modules in CAN Kingdom possible
04/15/11 26
HLP - CAN
SAE J1939
 Features
 Developed by Society of Automotive Engineers heavy trucks and bus
division (SAE)
 Use of the 29 identifiers
 Support of real-time close loop control
 Applications
 Light to heavy trucks
 Agriculture equipment e.g. tractors, harvester etc…
 Engines for public work
04/15/11 27
HLP - CAN
X-by-wire systems &

Time-triggered protocols
 Predictable new protocols
 Applications
 Automotive, aircraft…
 TTCAN: Time Triggered CAN:

 Robert Bosch GmbH, CiA.
 FLexRay:
 General Motors, DaimlerChrysler, BMW, Motorola, Philips
Semiconductors and Bosch Automotive Group.
 TTP: Time Triggered Protocol:
 PSA Peugeot Citroen, Audi,Volkswagen, Honeywell and Delphi
Automotive Systems.
FlexRay is becoming the reference

04/15/11 28
HLP - CAN
OSEK/VDX
 Initiative of:
 BMW, Bosch, DaimlerChrysler, Opel, Siemens,VW & IIIT of the
University of Karlsruhe / PSA and Renault
 Goal: Portability and re-usability of the application software
 OSEK/VDX includes:
 Communication (Data exchange within and between Control Units)
 Network Management (Configuration determination and monitoring)
 Operating System (Real-time executive for ECU software)
 Applications
 Automotive
 Advantages: Saving in costs and development time
Usually called OSEK

04/15/11 29
Applications - CAN
CAN Applications
04/15/11 30
Applications - CAN
CAN: a Large Field of Applications

 Building Automation:
 Heating control, Air Conditioning, Security, Access & Light
Control…
 Domestic & Food distribution appliances
 Washing machines, dishes cleaner, self-service bottle
distributors…
 Automotive & Transportation
 Dash Board, Power train & Car Body
 Train, bus and truck equipment…
 Robotic
 Production Automation:
 Control & link of production machines…
 Medical
 Agriculture
 Harvester, seeding, sowing machines, tractor control...
04/15/11 31
AT91SAM7 - CAN
AT91SAM7 CAN Embedded Controllers

A1 - A2 - A3 - X
04/15/11 32
AT91SAM7 - CAN
CAN Controllers Types

 3 types of CAN controllers exist:
 CAN Controllers 2.0 Part A: standard frames
 CAN Controllers 2.0 Part B Passive or ‘extended frames passive’
 CAN Controllers 2.0 Part B Active or ‘extended frames active’
 CAN Implementations: 2 main implementations strategy

 BasicCAN: cheaper CAN Controller
• 1 or 2 Rx buffers (FIFO) and 1 Tx buffer
• Minimal Filtering
 FullCAN: high performance CAN Controllers
• Set of buffers called Mailboxes
• Dedicated Mailbox Filtering
Our CANs: 2.0A/2.0B (Active) & FullCAN

04/15/11 33
AT91SAM7 - CAN
CAN Controllers Features

 Two different CAN implementations for the AT91SAM7 family:
 CAN embedded in SAM7A1 & SAM7A2 (Europe Technologies CAN)
 CAN embedded in SAM7A3 & SAM7X (ATMEL Rousset CAN)
 AT91SAM7A1:
 1 CAN Controller 2.0A and 2.0B FullCAN with 16 Mailboxes
 AT91SAM7A2:
 4 CAN Controllers 2.0A and 2.0B FullCAN
• 1 with 32 Mailboxes, 3 with 16 Mailboxes
 AT91SAM7A3:
 2 CAN Controllers 2.0A and 2.0B FullCAN with 16 Mailboxes
 AT91SAM7X:
 1 CAN Controller 2.0A and 2.0B FullCAN with 8 Mailboxes
SAM7A1-A2 Specific / SAM7A3-X Specific

04/15/11 34
AT91SAM7 - CAN
CAN Controllers Features (2)

■ Fully Compliant with CAN 2.0 Part A and 2.0 Part B
■ High Speed CAN: Bit Rates up to 1Mbit/s
■ Data, Remote, Error and Overload Frame Handling
■ Mailboxes with the Following Properties:
 Standard or Extended ID Programmable for Each Message
 Mailbox Configurable in Receive (with Overwrite or Not) or Transmit Modes
 Producer & Consumer Mailbox Feature
 Independent 29-bit Identifier and Mask Defined for Each Mailbox
 Uses a 16-bit / 32-bit Timestamp on Receive and Transmit Messages
 Hardware Concatenation of ID Masked Bitfields To Speed Up Family ID Processing
■ Global 16-bit / 32-bit Internal Timer for Time stamping
■ Priority Management between Transmission Mailboxes:
 Mailbox number prioritization
 Message ID prioritization
■ Autobaud Mode
■ Automatic retransmission of corrupted messages
■ Low Power Mode and Programmable Wake-up
SAM7A1-A2 Specific / SAM7A3-X Specific

04/15/11 35
SAM7A3 / SAM7X - CAN
AT91SAM7A3 – AT91SAM7X
CAN Controller
04/15/11 36
CAN on SAM7X-EK & SAM7A3-EK Boards
■ PMC has to be programmed 1st for CAN to work: Clock Enabling

- Set the PMC_PCER (Peripheral Clock Enable Register).
■ PIO CAN_TX and CAN_RX have to be configured in peripherals.
■ CAN Transceiver must be enabled through a PIO configured in Output.
■ CAN Internal Timer is 16-bit long.
■ 8 Mailboxes for SAM7X
■ 16 Mailboxes for SAM7A3
04/15/11 37
CAN Controller Structure
04/15/11 38
CAN Initialization
Status Registers Mode Register
0 2
Error Flags CANEN ABM
 CANEN = 1: Enable CAN Controller

 Wait for bus synchronization (11 consecutive
recessive bits are scanned)
 WAKEUP flag is set
 ABM = 1: Enable Autobaud Mode

 Error counters are disabled
 Transmission is disabled
04/15/11 39
CAN Bit Timing Configuration

Baudrate Register
16
BRP
 Sample Point: point in time at which the bus level is read as the value of that
respective bit.
 1 Time Quantum  1 period of CAN Controller Clock
Time Quantum = (BRP + 1) / MCK
TBIT =TSYNC + TPRS + TPHS1 + TPHS2

04/15/11 40
CAN Bit Timing Configuration (2)

Baudrate Register
8 0
SJW 12
PROPAG PHASE1 4
PHASE2
 Nominal Bit Time: 8 to 25 TQ long.

 Information Processing Time (IPT): time required to determine the bit level of a
sampled bit.
 SYNC_SEG is 1 TQ long.
 PROP_SEG: 1 to 8 TQ TPRS =TCSC * (PROPAG+1)
 PHASE_SEG1: 1 to 8 TQ TPHS1 =TCSC * (PHASE1+1)
 PHASE_SEG2 = Max(IPT, PHASE_SEG1) TPHS2 =TCSC * (PHASE2+1)
 SJW = Min(PHASE_SEG1, 4TQ) TSJW =TCSC * (SJW+1)
IPT is 2 TQ for ATMEL CANs

04/15/11 41
Low Power Mode

Mode Register Status Register
1 20
LPM SLEEP WAKEUP 21
 Low Power Mode: Send or receive messages is disabled (Mailboxes inactive)

 Enter Low Power Mode:
 Set LPM flag
 All pending transmit messages are sent before
 Wait for SLEEP signal raising
 Internal Counter (CAN_TIM) is reset and stuck to 0x0000.
 The user can disable CAN Clock (PMC)
 Exit Low Power Mode:
 Enable CAN Clock (PMC)
 Clear LPM flag
 Wait for bus synchronization  WAKEUP signal raising
 All pending transmit messages are sent before
 Internal Counter is reset and stuck to 0
04/15/11 42
Time Management Unit

Mode Register Status Register Message Mode Register
0
TTM 5
TEOF 4
TSTP 23
MTIMEMARK
 The CAN controller offers optimized features useful to support the Time-
Triggered protocols.
 Time Management Unit can operate in two modes:
 Time Stamping Mode (TTM = 0): the value of the internal timer (CAN_TIM)
is captured in the CAN Timestamp register (CAN_TIMESTP) at each:
• start of frame (TEOF = 0)
• end of frame (TEOF = 1)
 Time Triggered Mode (TTM = 1): a mailbox transfer operation is processed

when the internal counter reaches the mailbox trigger value (MTIMEMARK
field in corresponding mailbox CAN_MMR).
 TSTP = 1: A start or an end of frame has been detected
04/15/11 43
Time Management Unit (2)

Transfer Cmd Reg Status Register Mode Register
31 22 6
TIMRST TOVF TIMFRZ
 CAN_TIM register: Free-running 16-bit timer

 TIMRST = 1: Allows to clear the counter
 TIMFRZ = 1: Allows to freeze the counter
 TOVF = 1: A timer overflow is detected
 CAN_TIMESTP register: copy of the CAN_TIM after a successful transfer
04/15/11 44
Data, Remote, Error & Overload Frames Handling

Mailbox Status Register Mode Register
23 22 3 7
MRDY MABT OVL DRPT
 Data & Remote Frames can be sent/received thanks to the different mailboxes:
 A successful transfer raises the Mailbox Ready flag (MRDY) in the mailbox
status register.
 When a transmit mailbox looses bus arbitration, the transfer request remains
pending.
 Disable Repeat DRPT = 1:
• Transfer request is aborted if the transmit mailbox looses bus arbitration.
• Mailbox Abort flag (MABT) in the mailbox status register raises.
 Error Frames are automatically handled by the macro.
 Overload Frames can be generated by setting OVL flag in the Mode Register:
 OVL = 1: an overload is generated after each successful reception.
04/15/11 45
Mailbox Organisation
Mailbox x
CAN_MMRx
CAN_MMRx
 Eight 32-bit registers by mailbox
CAN_MAMx
CAN_MAMx
 Mailbox x Mode Register CAN_MIDx
CAN_MIDx
 Mailbox x Acceptance Mask Register
 Mailbox x ID Register CAN_MFIDx
CAN_MFIDx
 Mailbox x Family ID Register
CAN_MSRx
CAN_MSRx
 Mailbox x Status Register
 Mailbox x Data Low Register CAN_MDLx
CAN_MDLx
 Mailbox x Data High Register
 Mailbox x Control Register CAN_MDHx
CAN_MDHx
CAN_MCRx
CAN_MCRx
Mailbox  Channel  Buffer

04/15/11 46
Message Acceptance Procedure

Mailbox ID & Acceptance Mask Register
29
MIDE
 CAN_MIDx: defines the message ID

 MIDE = 0: standard message
 MIDE = 1: standard or extended message
 CAN_MAMx: defines the mask ID value

 Allows a mailbox to receive different
messages ID.
 CAN_MFIDx: concatenation of ID & mask ID

 Speed up message ID decoding
04/15/11 47
Push / Pull Model

 Push Model: Classical Tx Rx
 Producer  Tx Mailbox
 Consumer  Rx Mailbox
 Pull Model:
 Producer  Producer Mailbox
 Consumer  Consumer Mailbox
 Consumer transmit a remote frame
to the Producer.
 Producer transmit the answer to the
Consumer.
Pull Model:
 With Tx Rx mailboxes: 1 Tx+ 1 Rx Mailbox for each node  4 Mailboxes
 With Consumer Producer mailboxes: 2 Mailboxes only !

04/15/11 48
Mailbox Object Type

Mailbox Mode Register
24
MOT
 Five programmable type of mailboxes (MOT field in CAN_MMRx)
Reception Mailbox Types:
 Receive mailbox:
 The first message received is stored in mailbox data registers.
 Other messages are ignored by this mailbox.
 Receive with Overwrite mailbox:
 The first message received is stored in mailbox data registers.
 The next message overwrites the previous one.
 Consumer mailbox (Enhanced Reception Mailbox):
 Sends a remote frame to a producer mailbox.
 Waits automatically for a data frame with the same ID from a producer mailbox.
04/15/11 49
Mailbox Object Type (2)

24
MOT
Transmission Mailbox Types:
 Transmit mailbox:
 Sends either a remote frame or a data frame.
 Producer mailbox (Enhanced Transmit Mailbox):
 Waits for a remote frame from a consumer mailbox.
 Once the remote frame received, sends automatically a data frame with the same
ID to the consumer mailbox.
04/15/11 50
Mailbox Priority
16
PRIOR
Reception Modes:
 In this modes, the mailbox with the lowest number is serviced first.
Transmission Modes:
 Mailbox with the highest priority  PRIOR lowest value.
 When several mailboxes try to transmit a message at the same time, the mailbox with
the highest priority is services first.
 If at least two mailboxes have the same priority (same PRIOR value), the mailbox with
the lowest number is serviced first.
04/15/11 51
Transmit Mailbox Handling

Mailbox Control Register Mailbox Status Register
23
MTCR 23
MACR 22
MDLC 16
MRTR 20
MRDY
 Size of the message is defined in the Mailbox Data Length Code field (MDLC)
 Mailbox Transfer Command Request (MTCR = 1):
 Allows transmission of the current message.
 Message can be aborted (MACR =1).
 Mailbox Remote Transmission Request (MRTR = 1):
 Allows to send a remote frame (MDLC value is ignored).
04/15/11 52
Receive Mailbox Handling

23
MTCR 23
MRDY MMI 24
 Mailbox Transfer Command MTCR = 1:

 Allows reception of the next message.
 When MRDY flag is set, mailbox data registers content is available.
 MMI flag is set  a message has been lost by the mailbox
04/15/11 53
Receive with Overwrite Mailbox Handling

23
MTCR 23
MRDY MMI 24

 Allows to reset MRDY flag
 MMI flag is set  a new message has overwritten a previous one.
04/15/11 54
Chaining Receive Mailboxes
Allows to receive buffer split into several messages with the same ID  buffer size > 8 bytes.
04/15/11 55
Producer Mailbox Handling

23
MTCR 23
MACR 22
MRDY MMI 24

 Allows to wait for a remote frame reception
 Data is automatically sent after the reception of a remote frame
 MRDY remains at 0 as long as the message has not been transmitted or aborted
(MACR =1).
04/15/11 56
Consumer Mailbox Handling

23
MTCR 23
MRDY

 Allows to send a remote frame.
 Then, waits automatically for a data frame from a producer mailbox.
 MRDY remains at 0 as long as the data frame has not been received or aborted.
04/15/11 57
Multiple Transfer or Abort Requests
 The CAN Transfer Command Register (CAN_TCR) allows to perform several transfer
requests at the same time.
 The CAN Abort Command Register (CAN_ACR) allows to perform several abort
requests at the same time.
04/15/11 58

At91sam7 - Can

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

At91sam7 - Can

Hochgeladen von

Copyright:

Verfügbare Formate

CAN

Controller Area Network

ISO-OSI Reference Model

5. Session Layer Partially Implemented

2. Data Link Layer

ISO-OSI Reference Model (2)

CAN Bus Logic

‘0’ Dominant (D)

Two logic states on the CAN bus

Node 1 Node 2 Node 3 Bus

Typical CAN Node

CAN Bus is a simple 2-wire differential serial bus

CAN Bit Coding & Bit Stuffing

Number of consecutive bits

CAN Bus Access and Arbitration:

 CSMA/CD: Carrier Sense Multiple Access / Collision Detection

CAN Bus Synchronization

 Re-Synchronization on each Recessive to Dominant bit

CAN Bit Construction

 SYNC_SEG: synchronize the different nodes

1 Bit Time  8 to 25 Time Quanta

Relation between Baud Rate and Bus Length

 SOF: Start Of Frame

Frame Formats (2)

 CAN V2.0B Extended Frame: Identifier is 29 bits long

 ID: Identifier  SRR: Substitute Remote Request

Our CANs supports CAN V2.0A & CAN V2.0B Specification

Frame Formats (3)

 Remote Frame : RTR Recessive ‘1’ and No Data Field

Data Frame has priority on Remote Frame

Frame Formats (4)

 Overload Frame: prevents data overflow from a slower CAN

Overload Frames are not really used

 CAN Node Error States:

 Internal Counters: TEC & REC

TEC and REC counters allows to prevent from faulty nodes

Error Detection Analysis

 Error statistics depend on the entire environment

One undetected error every 1000 years !!!

CAN High Layer Protocols

One undetected error every 1000 years !!!

CiA (CAN in Automation)

CANopen (Europe) – DeviceNet (USA)

X-by-wire systems &

 TTCAN: Time Triggered CAN:

FlexRay is becoming the reference

Usually called OSEK

CAN: a Large Field of Applications

AT91SAM7 CAN Embedded Controllers

CAN Controllers Types

 CAN Implementations: 2 main implementations strategy

Our CANs: 2.0A/2.0B (Active) & FullCAN

CAN Controllers Features

SAM7A1-A2 Specific / SAM7A3-X Specific

CAN Controllers Features (2)

SAM7A1-A2 Specific / SAM7A3-X Specific

CAN on SAM7X-EK & SAM7A3-EK Boards

■ PMC has to be programmed 1st for CAN to work: Clock Enabling

CAN Controller Structure

 CANEN = 1: Enable CAN Controller

 ABM = 1: Enable Autobaud Mode

CAN Bit Timing Configuration