CIS 622 RealTime Operating Systems Controller Area Networks

1
CIS 622 - Real-Time Operating Systems Controller
Area Networks

• Mitch Neilsenneilsen_at_ksu.edu
• Office N219D

2
Outline

• Real-Time Networks
• Controller Area Networks (CAN)
• Implementation (next week)
• C167CR On-Chip CAN Module
• CAN Library (AppNote 2922)
• CAN Interrupt Structure (AppNote 1621)
• Tasking Development Environment
• C/C Compiler
• On-board Debugger
• Phytec Flash Programmer

3
Controller Area Network (CAN)

• A Controller Area Network is an advanced serial
  bus communication system that efficiently
  supports distributed, real-time control.
• Originally developed for use in automobiles by
  Bosch GmbH, Germany, in the late 1980s.
• Refer to can2spec.pdf (c. 1991)
• CAN is internationally standardized by the
  International Organization for Standardization
  (in ISO 11898) and by other standards
  organizations.

4
Typical Automobile Wiring
5
Automobile Wiring With CAN
6
ISO Reference Model

• CAN protocols fall within the Data Link Layer and
  the Physical Layer.
• CAN is most widely used in the automotive and
  industrial automation markets.

7
Physical Layer

• The two wire bus is usually twisted pair
  (shielded or unshielded). Flat pair (telephone
  type) cable also performs well but generates more
  noise itself, and may be more susceptible to
  external sources of noise (EMI).
• Non Return to Zero (NRZ) bit encoding (with
  bit-stuffing) for data communication on a
  differential two wire bus. NRZ encoding ensures
  compact messages with a minimum number of
  transitions and high resilience to external
  disturbance.

8
Recessive and Dominant Bits
9
Basic Concepts
10
Bus Length vs. Bit Rate
11
CAN Operating Principles

• Data messages transmitted on a CAN bus do not
  contain the address of either the sender or the
  receiver.
• The content of each message is labeled by an
  identifier that is unique throughout the network.
• All other nodes on the network receive the
  message (e.g., broadcast).
• Messages can be filtered based on relevance.
• If a message is not relevant, the message can be
  filtered out in hardware by the receiver (e.g., a
  poor man's multicast).

12
Identifiers

• The unique identifier also determines the
  priority of the message. The lower the numerical
  value of the identifier, the higher the priority.
  
• The highest priority message is guaranteed to
  gain access to the bus.
• Lower priority messages are automatically
  retransmitted in the next bus cycle, or in a
  subsequent bus cycle if there are still other,
  higher priority messages waiting to be sent.

13
Non-destructive Bitwise Arbitration

• The priority of a CAN message is determined by
  the binary value of its identifier.
• The numerical value of each message identifier is
  assigned during the initial phase of system
  design.
• The identifier with the lowest numerical value
  has the highest priority. Any potential bus
  conflicts are resolved by bitwise arbitration, in
  accordance with the wired-and mechanism, by which
  a dominant bit (0) over writes a recessive bit
  (1).

14
Non-destructive Bitwise Arbitration
A "I Lost!"
A B C On Bus
1 1 1 1
0 0 0 0
1 0 0 0
1 1 1
1 0 0
1 1
B "I Lost!"
C "I Won!"
...
arbitration interval
time
15
CAN Message Format

• In a CAN system, data is transmitted and received
  using Message Frames. Message Frames carry data
  from a transmitting node to one, or more,
  receiving nodes.
• The Standard CAN protocol (version 2.0A) supports
  messages with 11 bit identifiers.
• The Extended CAN protocol (version 2.0B) supports
  both 11 bit and 29 bit identifiers.

16
Arbitration Field

• Determines message priority.
• For CAN 2.0A, an 11-bit Identifier and one bit,
  the RTR bit, which is dominant.
• For CAN 2.0B, a 29-bit Identifier (which includes
  two recessive bits SRR and IDE) and the RTR bit.
  

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
CRC
Identifier
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
17
CAN 2.0B Format

• The CAN 2.0B Format uses a 29-bit identifier
  divided into an 11-bit base identifier and a
  18-bit extended identifier.
• All other fields are the same as 2.0A.

ACK Slot
Arbitration Field
Control Field (6)
End Of Frame (7)
Data Field (0-64)
ID (11)
CRC (14)
ID (18)
1
1
1
1
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
SRR
IDE
r0, r1, DLC (4)
18
Worst-Case Tx Time (CAN 2.0B)

• Let Cm denote the worst-case transmission time
  for a data frame.
• For a data frame carrying 8 bytes of data
• Sm 8 bytes 64 bits of user data in the data
  field.
• Cm 154 tbit , where tbit is the bit transfer
  rate e.g., for a 250 kbps CAN bus, tbit is 4
  microsecond, so Cm 616 microseconds or about
  1623 frames per second.

19
Bit Stuffing
20
Message Types

• There are four different message types (frame
  types) on a CAN bus
• the Data Frame,
• the Remote Frame,
• the Error Frame, and
• the Overload Frame.

21
1. Data Frame

• Data Frames are used to transmit messages to one
  or more receivers (multicast).
• The CAN 2.0A Data Frame Format is shown below.

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
22
Control Field

• The Control Field contains six bits
• two dominant bits (r0 and r1) that are reserved
  for future use, and
• a four bit Data Length Code (DLC). The DLC
  indicates the number of bytes in the Data Field.

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
23
Data Field

• The Data Field contains from zero to eight bytes
  of data.

24
Cyclic Redundancy Code (CRC)

• The CRC Field contains a 15-bit CRC code used for
  error detection and one recessive bit used as a
  delimiter.
• G(x) x15 x14 x10 x8 x7 x4 x3 1

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
25
Acknowledgement Slot

• Any CAN controller that is able to correctly
  receive the message sends an Acknowledgement bit
  at the end of the message.
• The transmitter checks for the presence of the
  Ack bit and retransmits the message if no
  acknowledgement was detected.

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
26
End Of Frame

• The End of Frame Field consists of seven
  recessive bits (1's).

27
Intermission Field

• Following the End Of Frame are three recessive
  bits called the Intermission Field.
• After the Intermission interval, the bus is
  recognized to be idle (free).

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC Field
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
28
Notes

• The presence of an Acknowledgement Bit on the bus
  does not mean that any of the intended addressees
  has received the message. The only thing we know
  is that one or more nodes on the bus has received
  it correctly.
• The Identifier in the Arbitration Field does not,
  despite its name, necessarily identify the
  contents of a message.
• Bus Idle time may be of any arbitrary length
  including zero.

29
CAN 2.0B Format

• The CAN 2.0B Format uses a 29-bit identifier
  divided into an 11-bit base identifier and a
  28-bit extended identifier.

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC Field
Identifier
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
SRR
IDE
30
CAN 2.0B Format

• The CAN 2.0B Format uses a 29-bit identifier
  divided into an 11-bit base identifier and a
  18-bit extended identifier.

ACK Slot
Arbitration Field
Control Field
End Of Frame
Data Field
Identifier
CRC Field
Identifier
CRC Delimiter
ACK Delimiter
Start Of Frame
RTR
SRR
IDE
31
Version 2.0A and 2.0B Compatibility

• Most 2.0B controllers are completely backward
  compatible with 2.0A controllers and can
  transmit, and receive messages in either format.
• However, there are two types of 2.0A controllers
  
• The first is capable of transmitting and
  receiving only messages in 2.0A format.
• The second, called 2.0B passive, is able to send
  and receive 2.0A messages, and acknowledge
  receipt of 2.0B messages. However, 2.0B messages
  are then ignored (dropped).

32
SRR and IDE Bits

• The distinction between the two formats is made
  using the Identifier Extension (IDE) bit.
• For an extended frame (29-bit ID), IDE 1.
• A Substitute Remote Request (SRR) bit is also
  included in the Arbitration Field.
• The SRR bit is always transmitted as a recessive
  bit to ensure that, in the case of arbitration
  between a Standard Data Frame and an Extended
  Data Frame, the Standard Data Frame will always
  have higher priority if both messages have the
  same base id (11-bit ID).
• Note The SRR bit appears in the same position as
  the RTR bit in a Standard Data Frame.

33
2. Remote Frame

• The Remote Transmission Request (RTR) bit is used
  to discriminate between a transmitted Data Frame
  and a request for data from a remote node e.g.,
  a Remote Frame.
• If the RTR bit is set (1), the frame is a Remote
  (Request) Frame.
• If the RTR bit is not set (0), the frame is the
  corresponding Data (Response) Frame.
• Several higher-level CAN protocols, such as SAE
  J1939 and NMEA 2000 do not use remote frames.

34
Notes

• In the unlikely event that a Data Frame and a
  Remote Frame with the same identifier are
  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 requested data immediately.

35
3. Error Frame

• An Error Frame is transmitted in response to an
  error condition.
• An active Error Frame has higher priority than
  Data Frames.
• A passive Error Frame does not.

36
Types of Errors

• Bit Error - the sending node monitors the bus to
  ensure that the data transmitted is the same as
  the data received exceptions include Ack bits
  and Arbitration field bits.
• Stuff Error - bit stuffing is used, if a 6th
  successive bit (either 0s or 1s) is detected,
  then a stuff error is reported.
• CRC Error - the CRC code computed is different
  than the code transmitted.

37
Types of Errors (continued)

• Form Error - a form error is detected when a
  fixed form bit (constant bit) is different than
  what is expected.
• Acknowledgement Error - an ack. error is detected
  whenever the sender does not monitor a dominant
  bit in the Ack Slot e.g., no other node
  acknowledges receipt of the frame.

38
Fault Confinement

• A node may be in one of three states
• Active Error State - normal operation
• Passive Error State - dont generate active error
  messages
• Bus Off - dont generate any messages
• An error count gt 96 indicates a heavily
  disturbed bus.

39
Error States
R Receive Error Count, S Send (Transmit)
Error Count
40
4. Overload Frame

• An Overload Frame is used by an overwhelmed
  receiver to indicate an overload by inserting
  some dummy bits onto the bus.
• Most higher level protocols do not use overload
  frames.

41
CAN Examples

• can204\example.c
• send message 0x204, receive message 0x205
• can204r\example.c - ROM monitor version
• can205\example.c
• send message 0x205, receive message 0x204

42
Version 2.0A and 2.0B Compatibility

• 2.0B controllers are completely backward
  compatible with 2.0A controllers and can transmit
  and receive messages in either format.
• However, there are two types of 2.0A controllers
  
• The first is capable of transmitting and
  receiving only messages in 2.0A format.
• The second, called 2.0B passive, is able to send
  and receive 2.0A messages, and acknowledge
  receipt of 2.0B messages. However, 2.0B messages
  are then ignored (dropped).

43
Comparison
44
Higher Level Protocols

• SAE J1939 - for in-vehicle, heavy truck, and
  agricultural networking
• NMEA 2000 - for networking marine craft
• CANopen - CiA (CAN in Automation)
• DeviceNet - ODVA, (Allen-Bradley, etc.)
• SDS - Honeywell
• CDA 101 - DoD
• CAN Kingdom - Kvaser

45
J1939 in OSI Reference Model

• J1939/11 - Physical Layer - twisted pair, twisted
  quad, ...
• J1939/21 - Data Link Layer - define frame
  (Protocol Data Unit (PDU)) format, point-to-point
  and broadcast (BLAST) protocols
• J1939/31 - Network Layer
• J1939/71 - Application Layer
• J1939/81 - Network Management
• J1939/0 - General documentation
• 01 - Truck and Bus
• 02 - Agricultural Equipment
• ...

46
Typical On-Highway Truck Implementation(From SAE
J1939/01 DRAFT)
47
Controller Area Network (SAE J1939)
Management Computer
Implement
Node
Task Controller
VT
Gateway
Tractor to
Bridge
GPS
Implement
Bridge
Engine
Hitch
Tractor Bus
Implement
Node
48
Common Digital Architecture(CDA 101)

• A standard architecture for interconnecting
  target vehicle electronics

• Interface standards
• Hardware
• Software

CDA
Autopilot
Transponder
GPS
TA/AS
49
Seaborne Target ST2000
50
Seaborne Target ST2000
CAN Bus
System Controller (King)
Sensors
xponder
Engine Controller 1
Actuator
Instrument Cluster 1
Instruments, Switches, Lights
Sensors
Engine Controller 2
Actuator
Instrument Cluster 2
Instruments, Switches, Lights
Rudder Sensor
Rudder Controller
Throttle
Rudder Pump
Mather Throttle
Fiber to TP
GPS
Pitch, Roll Heading
Windspeed
Lights
Pitch,Roll, Heading
Windbird
51
Typical CAN Node
Optically Isolated RS-232
RAM
FLASH
CAN Choke
CAN Transceiver
Optically Isolated I/O
Fiber Optic Transceivers
Extra CAN Controller (SJA1000)
uController
52
Outline

• Real-Time Networks
• Controller Area Networks (CAN)
• Implementation
• C167CR On-Chip CAN Module
• CAN Library (AppNote 2922)
• CAN Interrupt Structure (AppNote 1621)
• Tasking Development Environment
• C/C Compiler
• On-board Debugger
• Phytec Flash Programmer

53
C167CR On-Chip CAN Interface

• The C167CR supports Full CAN 2.0B functionality
• Data transfer rates up to 1Mbps
• Data integrity (built in error checking)
• Host processor unloading the CAN controller
  handles most of the tasks autonomously
• Flexible and powerful message passing
• Fifteen message objects

54
Message Objects (15)

• All message objects can be updated independently.
• Maximum message length is 8 bytes.
• Each message objects has a unique identifier and
  its own set of control and status bits.
• Each object can be configured with its direction
  as either transmit or receive, except the last
  message (object 15) which is only a double
  receive buffer with a special mask register.

55
Registers and Message Objects

• All registers and message objects of the CAN
  controller are located in the special CAN address
  area of 256 bytes, which is mapped into segment 0
  and uses addresses 00EF00H through 00EFFFH.
• All registers are organized as 16-bit registers,
  located on word addresses. However, all registers
  may be accessed bytewise in order to select
  special actions without effecting other
  mechanisms.

56
CAN Module Address Map
57
include ltcanr16x.hgt(c\c166\include\canr16x.h)

• / Define CAN module control registers /
• define CR (unsigned char) 0xef00
• define SR (unsigned char) 0xef01
• define IR (unsigned char) 0xef02
• define BTR (unsigned int ) 0xef04
• define GMS (unsigned int ) 0xef06
• define UGML (unsigned int ) 0xef08
• define LGML (unsigned int ) 0xef0a
• define UMLM (unsigned int ) 0xef0c
• define LMLM (unsigned int ) 0xef0e

58
CAN Module Address Map
59
(No Transcript)
60
(No Transcript)
61
CAN Module Address Map
62
(No Transcript)
63
CAN Module Address Map
64
(No Transcript)
65
CAN Module Address Map
66
Mask Registers

• Messages can use standard or extended
  identifiers. Incoming frames are masked with
  their appropriate global masks.
• Bit IDE of the incoming message determines, if
  the standard 11-bit mask in Global Mask Short is
  to be used, or the 29-bit extended mask in Global
  Mask Long.
• Bits holding a 0 mean dont care, ie. do not
  compare the messages identifier in the
  respective bit position.
• The last message object (15) has an additional
  individually programmable acceptance mask.

67
(No Transcript)
68
CAN Module Address Map
69
Message Objects

• The message object is the primary means of
  communication between CPU and CAN controller.
• Each of the 15 message objects uses 15
  consecutive bytes (see below) and starts at an
  address that is a multiple of 16.

70
Message Control Register

• Each element of the Message Control Register is
  made of two complementary bits.
• This special mechanism allows for the selective
  setting or resetting of specific elements
  (leaving others unchanged) without requiring
  read-modify-write cycles. None of these elements
  will be affected by reset. The table below shows
  how to use and interpret these 2-bit fields.

71
(No Transcript)
72
Arbitration Registers

• The Arbitration Registers are used for acceptance
  filtering of incoming messages and to define the
  identifier of outgoing messages.
• A received message is stored into the valid
  message object with a matching identifier and
  DIR0 (data frame) or DIR1 (remote frame).
• Extended frames can be stored only in message
  objects with XTD1, standard frames only in
  message objects with XTD0.
• For matching, the corresponding global mask has
  to be considered (in case of message object 15
  also the Mask of Last Message).
• If a received message (data frame or remote
  frame) matches with more than one valid message
  object, it is stored into that with the lowest
  message number.

73
(No Transcript)
74
Message Configuration Register
75
Initialization

• To initialize the CAN Controller, the following
  actions are required
• configure the Bit Timing Register
• set the Global Mask Registers
• initialize each message object.
• CAN Library
• init_can_16x(baud rate, eie, sie, ie)
• to initialize CAN Controller global settings
• source code in appnotes/AP292201.EXE

76
Tasking 80C166 Tool-Chain
CAN library
77
Tool-Chain (continued)
78
C CAN Driver RoutinesSiemens Application Note
AP292201.PDF

• Initialization routine for the CAN module
  init_can_16x(..)
• Define a message object in the CAN module
  def_mo_16x(..)
• Load the data bytes of a message object
  ld_modata_16x(..)
• Read the data bytes of a message object
  rd_modata_16x(..)
• Read the contents of message object 15
  rd_mo15_16x(..)

79
CAN Driver Routines (cont.)

• Send message object
• send_mo_16x(..)
• Check for new data in a message object
  check_mo_16x(..)
• Check for new data or remote frame in message
  object 15 check_mo15_16x(..)
• Check if a bus off situation has occurred and
  recover from bus off check_busoff_16x(..)

80
(No Transcript)
81
CAN Examples

• can204\example.c
• send message 0x204, receive message 0x205
• can204r\example.c - ROM monitor version
• can205\example.c
• send message 0x205, receive message 0x204

82
Outline

• Real-Time Networks
• Controller Area Networks (CAN)
• Implementation (next week)
• C167CR On-Chip CAN Module
• CAN Library (AppNote 2922)
• CAN Interrupt Structure (AppNote 1621)
• Tasking Development Environment
• C/C Compiler
• On-board Debugger
• Phytec Flash Programmer

83
CAN Module Address Map
84
General CAN Registers(C\c166\include\canr_16x.
h)

• / Define CAN module control registers /
• define CR (unsigned char) 0xef00
• define SR (unsigned char) 0xef01
• define IR (unsigned char) 0xef02
• define BTR (unsigned int ) 0xef04
• define GMS (unsigned int ) 0xef06
• define UGML (unsigned int ) 0xef08
• define LGML (unsigned int ) 0xef0a
• define UMLM (unsigned int ) 0xef0c
• define LMLM (unsigned int ) 0xef0e

85
CAN Module Address Map
86
(No Transcript)
87
Example can204i\can_msg.h

• define MY_IEN_BIT 1 / General Interrupt
  Enable yes /
• define MY_BAUD_RATE 250 / 250 kBit/s on the CAN
  bus /
• define IE_BIT 1 / ENABLE
  interrupts from CAN module /
• define EIE_BIT 0 / No
  error interrupts from the CAN module /
• define SIE_BIT 0 / No status
  interrupts from the CAN module /
• / Specify Message Object (MO) Features
  /
• define MO1_XTD_BIT 0 / MO1 uses 11 bit ID
  /
• define MO1_ID 0x204 / 11-bit identifier
  /
• define MO1_DIR_BIT 1 / MO1 transmits data
  /
• define MO1_DLC 8 / MO1 data length /
• define MO1_TXIE_BIT 0 / no transmit
  interrupts /
• define MO1_RXIE_BIT 0 / no receive interrupts
  /
• define MO2_XTD_BIT 0 / MO2 uses 11 bit ID
  /
• define MO2_ID 0x205 / 11-bit identifier
  /
• define MO2_DIR_BIT 0 / MO2 receives data
  /
• define MO2_DLC 8 / MO2 data length /
• define MO2_TXIE_BIT 0 / no transmit
  interrupts /
• define MO2_RXIE_BIT 1 / receive interrupts
  /

88
(No Transcript)
89
CAN Module Address Map
90
(No Transcript)
91
CAN Module Address Map
92
Message Objects

• The message object is the primary means of
  communication between CPU and CAN controller.
• Each of the 15 message objects uses 15
  consecutive bytes (see below) and starts at an
  address that is a multiple of 16.

93
Message Control Register

• Each element of the Message Control Register is
  made of two complementary bits.
• This special mechanism allows for the selective
  setting or resetting of specific elements
  (leaving others unchanged) without requiring
  read-modify-write cycles. None of these elements
  will be affected by reset. The table below shows
  how to use and interpret these 2-bit fields.

94
(No Transcript)
95
Read Message Object(appnotes\RDMOD16x.c)

• void rd_modata_16x(unsigned char nr, unsigned
  char downl_data_ptr)
• unsigned char i, dummy_char
• unsigned char dummy_dbptr
• if ((nrlt15) (nr))
• do
• dummy_charmsgconf_ptr_16xnr
• dlc_16xnr(dummy_chargtgt4) / store actual
  data length code /
• msgctrl_ptr_16xnr0xfdfd / clear NEWDAT
  and INTPND /
• dummy_dbptrdb0_ptr_16xnr / load dummy ptr
  (db 0) /
• for (i0iltdlc_16xnri) downl_data_ptr
  dummy_dbptr
• / move data bytes from MO's data bytes to
  download buffer /
• while (msgctrl_ptr_16xnr 0x0200) /
  while NEWDAT1 /

96
Message Configuration Register
97
Read Message Object(appnotes\RDMOD16x.c)

• void rd_modata_16x(unsigned char nr, unsigned
  char downl_data_ptr)
• unsigned char i, dummy_char
• unsigned char dummy_dbptr
• if ((nrlt15) (nr))
• do
• dummy_charmsgconf_ptr_16xnr
• dlc_16xnr(dummy_chargtgt4) / store actual
  data length code /
• msgctrl_ptr_16xnr0xfdfd / clear NEWDAT
  and INTPND /
• dummy_dbptrdb0_ptr_16xnr / load dummy ptr
  (db 0) /
• for (i0iltdlc_16xnri) downl_data_ptr
  dummy_dbptr
• / move data bytes from MO's data bytes to
  download buffer /
• while (msgctrl_ptr_16xnr 0x0200) /
  while NEWDAT1 /

98
Initialize CAN Controller(appnotes\INCAN16x.c)

• void init_can_16x(unsigned int baud_rate,
  unsigned char eie,
• unsigned char sie, unsigned char ie)
• unsigned char i, n
• unsigned char dummy_dbptr
• / Initialization PORT4 (CAN) (P4.6 to output
  P4.5 to input) /
• _bfld (P4, 0x0060, 0x0060)
• _bfld (DP4, 0x0060, 0x0040)
• / Load C167 pointers /
• for (i1ilt16i)
• db0_ptr_16xi (unsigned char
  )(0xef07i16) / ptrs. to data bytes 0 of MOs
  /
• id_ptr_16xi (unsigned int
  )(0xef02i16) / ptrs. to id's of MO
  1..15 /
• msgconf_ptr_16xi (unsigned char
  )(0xef06i16) / ptrs. to msg cfg regs./
• msgctrl_ptr_16xi (unsigned int
  )(0xef00i16) / ptrs. to msg cntrl regs. /
• dir_bit_16xi 0 / clear DIR bit array /
• xtd_bit_16xi 0 / clear XTD bit array /
• dlc_16xi 0 / clear data length code
  array /

99
Initialize CAN Controller (cont.)

• / Load General CAN-Registers /
• CR0x41 / set CCE and INIT in Control Register
  (EF00h) /
• SR0x00 / Clear Status Partition (EF01h) /
• switch (baud_rate)
• case 50 BTRBTR_VALUE_50KBAUD
• break
• case 125 BTRBTR_VALUE_125KBAUD
• break
• (etc)
• GMS0xe0ff / Global Mask Short (EF06h) /
• / each bit of standard ID must match to store
  mess. /
• UGML0xffff / Upper Global Mask Long (EF08h)
  /
• LGML0xf8ff / Lower Global Mask Long (EF0Ah)
  /
• / each bit of extended ID must match to store
  mess. /

100
Initialize CAN Controller (cont.)

• UMLM0x0000 / Upper Mask of Last Message
  (EF0Ch) /
• LMLM0x0000 / Lower Mask of Last Message
  (EF0Eh) /
• / every message into MO 15 (Basic CAN
  Feature)/
• / reset all elements incl MSGVAL in all Message
  Object Ctrl. Reg. /
• for (i1ilt16i) msgctrl_ptr_16xi 0x5555
• / reset all data bytes in all Message Objects
  /
• for (i1ilt16i)
• dummy_dbptrdb0_ptr_16xi
• for (n0nlt8n) dummy_dbptr 0x00
• / end initialization (CCE0, INIT0)
  Interrupts EIE, SIE, IEuser /
• CR (0x00 (eieltlt3) (sieltlt2) (ieltlt1))

101
C CAN Driver RoutinesSiemens Application Note
AP292201.PDF

• Initialization routine for the CAN module
  init_can_16x(..)
• Define a message object in the CAN module
  def_mo_16x(..)
• Load the data bytes of a message object
  ld_modata_16x(..)
• Read the data bytes of a message object
  rd_modata_16x(..)
• Read the contents of message object 15
  rd_mo15_16x(..)

102
CAN Driver Routines (cont.)

• Send message object
• send_mo_16x(..)
• Check for new data in a message object
  check_mo_16x(..)
• Check for new data or remote frame in message
  object 15 check_mo15_16x(..)
• Check if a bus off situation has occurred and
  recover from bus off check_busoff_16x(..)

103
CAN Interrupt Sources

• Many different interrupt sources generate one
  global CAN interrupt request.
• The INTID code in the CAN Interrupt Register
  (EF02H) indicates which source has activated the
  request.
• Bit IE in the CAN Control/Status Register (EF00H)
  globally enables (IE1) or disables all interrupt
  sources for the CAN module.

104
Types Of Interrupts

• Status Interrupts
• Error Interrupts
• Message Specific Interrupts

105
Status Interrupts

• Status Interrupts are generated after a status
  change
• a successful transmission (TXOK is set) or
• reception (RXOK is set) of any message,
• or the occurrence of an error during transmission
  (LEC).
• Interrupt type is indicated by the flags in the
  status part (high byte) of the CAN Control/Status
  Register
• Status Interrupts are enabled by setting bit SIE
  in the CAN Control/Status Register.

106
Error Interrupts

• Error Interrupts are generated after each change
  of the flags EWRN or BOFF which indicate the
  level of the two internal error counters
  (transmit error counter and receive error
  counter).
• If one of these counters reaches the value of 96,
  the error warning flag EWRN is set.
• If the send error counter exceeds the value of
  255, the bus off flag BOFF is set. Furthermore,
  bit INIT is automatically set and the device
  stops all action on the CAN bus, it goes bus-off.
  A resynchronisation on the CAN bus can be
  achieved by resetting bit INIT by software.
• Error Interrupts are enabled by setting bit EIE.

107
Message Specific Interrupts

• Message Specific Interrupts are generated by each
  message object after successful transmission or
  reception.
• They are enabled by setting bits TXIE and/or RXIE
  in the corresponding CAN Message Control Register
  located at address EFn0H, with n (1..15) being
  the number of the corresponding message object.

108
Define Message Objects(appnotes\DEFMO16x.c)

• void def_mo_16x(unsigned char nr, unsigned char
  xtd, unsigned long id,
• unsigned char dir, unsigned char dlc, unsigned
  char txie, unsigned char rxie)
• unsigned int dummy_int
• unsigned int dummy_idptr
• if ((nrlt16) (nr))
• // Load Arbitration Register(s) for Message
  Object nr
• // Prepare Message Control Register
• / prepare Message Control Register /
• if (txie1) (txie0x20) else (txie0x10)
• if (rxie1) (rxie0x08) else (rxie0x04)
• if (dir1) dummy_int (0x5981 txie
  rxie) / CPUUPD set /
• else dummy_int (0x5581 txie rxie)
  / MSGLST reset /
• msgctrl_ptr_16xnrdummy_int / Load
  Mess. Contr. Reg. /

109
Define Message Object (cont.)

• / prepare Message Configuration Register /
• if (dlcgt8) dlc8
• dlc_16xnrdlc
• dir_bit_16xnrdir
• xtd_bit_16xnrxtd
• msgconf_ptr_16xnr (dlcltlt4) (dirltlt3)
  (xtdltlt2)

110
INTID Code

• An INTID code of 0 indicates that all requested
  interrupts have been correctly serviced and no
  more interrupts are pending. This should be the
  condition to leave the CAN interrupt service
  routine.
• An INTID value of 1 indicates a status interrupt
  (if enabled by SIE) or an error interrupt (if
  enabled by EIE), which cause the interrupt with
  the highest priority. In the case of a status
  change due to a successful message transfer, one
  of the flags TXOK or RXOK in the CAN Status
  Register is set.
• An erroneous message transfer is indicated by the
  LEC bit field. In the case of an error interrupt,
  at least one of the error flags EWRN and BOFF has
  changed.

111
INTID Code (cont.)

• An INTID code of 2 indicates the reception of a
  message by msg. object 15.
• An INTID code of 3..16 indicates a message
  specific transmit (if TXIE set) or receive (if
  RXIE set) interrupt concerning the message
  objects 1 to 14 (e.g., INTID - 2). In addition,
  the global flags TXOK and RXOK can be checked to
  decide if it was an interrupt on a received or on
  a transmitted message.
• A successful message transfer sets bit INTPND in
  the corresponding Message Control Register, which
  must be cleared by software to reset this
  interrupt request (recall read message object
  code).

112
General Interrupt Handling

• The status part (high byte) of the CAN
  Control/Status Register must be read in the
  interrupt service procedure in order to identify
  the interrupt source and to reset the pending
  interrupt request. Flags TXOK and RXOK in this
  part of the register must be cleared by software.
• The priority of the internal CAN interrupt
  sources decreases with an increasing INTID code.
  This structure must also be taken into account
  for the identification of the interrupt source.
  Successful transmission of only one message
  object can cause two independent interrupt
  requests if bit SIE and the corresponding bit
  TXIE have been set. If the status interrupt
  (highest priority) is serviced and bit INTPND of
  this message object is not cleared, the message
  specific interrupt remains pending.

113

• // CAN interrupt service routine
• interrupt(0x40)
• void int_can (void)
• unsigned char status, intid
• while (intid IR)
• status SR SR 0 // read and reset CAN
  status register
• switch (intid)
• case 1 // status and error interrupt
• if (status 0x04) // status
  interrupts
• if (status 0x08) ... //
  transmit interrupt
• if (status 0x10) ... //
  receive interrupt
• if (status 0x07) ... // error
  interrupt
• if (status 0x08) // error
  interrupts

114

• case 3 // message 1 interrupt
• ..
• if (status 0x08) ... // transmit
  interrupt
• if (status 0x10) ... // receive
  interrupt
• break
• case 16 // message 14 interrupt
• ..
• if (status 0x08) ... // transmit
  interrupt
• if (status 0x10) ... // receive
  interrupt
• break

115
CAN Examples

• can204\example.c
• send message 0x204, receive message 0x205
• can205\example.c
• send message 0x205, receive message 0x204
• can204r\example.c
• ROM monitor version
• can204i\example.c
• interrupt-driven receives version

116
Summary

• Real-Time Networks
• Controller Area Networks (CAN)
• Implementation (next week)
• C167CR On-Chip CAN Module
• CAN Library (AppNote 2922)
• CAN Interrupt Structure (AppNote 1621)
• Tasking Development Environment
• C/C Compiler (Tasking EDE)
• On-board Debugger (CrossView Pro)
• Phytec Flash Programmer (FlashTools 16W or 3)