EEET2227 Microcomputer Systems Design

EEET2227 Microcomputer Systems Design
Laboratory #5: CAN Bus
Lecturer: Dr. Heiko E. R. Rudolph (heiko.rudolph@rmit.edu.au)

Tutor: Prof John Kneen (e00041@ems.rmit.edu.au, john.kneen@rmit.edu.au)
Group: Wednesday 15:30 – 17:30
Submision Date: 2007/06/01
Student: Xiang Li (s3148918@student.rmit.edu.au)

Wilson Castillo Bautista (s3143667@student.rmit.edu.au)
Subject Code: EEET2227 Microcomputer Systems Design
Melbourne, June 1st, 2007

EEET2227 Microcomputer Systems Design CAN Bus
Tutor: Prof. John Kneen Laboratory # 5 Report
Table of Contents
1 Introduction ......................................................................................................................................4
2 Aim......................................................................................................................................................4
3 Materials and Methods ..................................................................................................................4
3.1 Materials..................................................................................................................................4
3.2 Methods ..................................................................................................................................4
3.2.1 Initialize msCAN12 Controller..........................................................................................5
3.2.1.1 Soft Reset Mode ...........................................................................................................6
3.2.1.2 Clock Source.................................................................................................................6
3.2.1.3 Configure the Synchronization Jump Width and Prescaler.................................7
3.2.1.4 Set time segment .........................................................................................................8
3.2.1.5 Set Identifier Acceptance Filter ................................................................................9
3.2.1.6 Message Handle ........................................................................................................11
3.3 Answer Questions ................................................................................................................12
3.4 Configuration for this laboratory ......................................................................................17
3.4.1 Enabling the serial port..................................................................................................18
3.4.2 Program in operation.....................................................................................................18
3.4.3 Configuring the OC Console........................................................................................19
3.4.4 The BOSCH box ...............................................................................................................20
Annex 1 – Setup12.s file ........................................................................................................................21
Annex 2 – Lab5.c file.............................................................................................................................22
Annex 3 – definitions.h file....................................................................................................................26
4 Conclusions .....................................................................................................................................28
5 References ......................................................................................................................................29
RMIT University © 2007 2 of 29

School of Electrical and Computer Engineering Melbourne, 1st June, 2007
Table of Figures
Figure 1: Architecture of this laboratory..............................................................................................5

Figure 2: The CAN system from motorola M68HC12D60A (www.freescale.com, 2007/05/15).6
Figure 3: msCAN12 Module Control Register 0 ..................................................................................6
Figure 4: msCAN12 Module Control Register 1 ..................................................................................6
Figure 5: msCAN12 Bus Timing Register 0 ............................................................................................7
Figure 6: BOSCH Box Timing ...................................................................................................................7
Figure 7: SJW Bits in the M68HC12D60A...............................................................................................7
Figure 8: Table to define the prescaler value ....................................................................................8
Figure 9: msCAN12 Bus Timing Register 1 and its possible values...................................................8
Figure 10: msCAN12 Identifier Acceptance Control Register.........................................................9
Figure 11: Bits to define the operation mode of the Identifier Acceptance Filters ....................9
Figure 12: CAN 2.0A Frame (http://hem.bredband.net/stafni/developer/CAN.htm,
2007/05/15) ...............................................................................................................................................9
Figure 13: CAN 2.0B Frame (http://hem.bredband.net/stafni/developer/CAN.htm,
2007/05/15) .............................................................................................................................................10
Figure 14: Demo box message list (Kneen J, Heiko R, 2007)..........................................................11
Figure 15: ACK Field. The ACK slot is used by the receiver to indicate successfully reception
of the message. Sending a dominant bit in the ACK slot. ............................................................13
Figure 16: msCAN12 receiver interrupt enable register (CRIER) ...................................................17
Figure 17: Linker file created into the COSMIC software (6812lkf.lkf) ..........................................18
Figure 18: Application running, display shows OC Console receiving information regarding
CAN modules .........................................................................................................................................19
Figure 19: Configuring the OC Console ............................................................................................19
Figure 20: Loading the file into the M68HC12 device. In this example the bosch.s19 file ......20
Figure 21: BOSCH box operating with BOSCH.S19 file loaded into the M68HC12 ....................20
Figure 22: Setup12.s file used in COSMIC software (Setup12.s) ....................................................21
Figure 23: Lab3.c code.........................................................................................................................26
Figure 24: definitions.h file. Some constant values are defined ...................................................27

CAN Bus
1 Introduction
Controller Area Network (CAN) is a serial network that was originally designed for the
automotive industry. However, it has also become a popular bus in industrial automation as
well as in other applications. The CAN bus is primarily used in embedded systems, and as its
name implies, is the network established among microcontrollers. It is a two-wire, half
duplex, high-speed network system and is well suited for high speed applications using
short messages. Its robustness, reliability and the large following from the semiconductor
industry are some of the benefits with CAN. For this laboratory we used a MC68HC12 system
as the computer to monitor and control activity on a CAN demonstration box donated by
Bosch Australia. This demo box contains CAN modules for the passenger and driver door.
2 Aim
The aim of this laboratory is:
Use monitor program OCCONSOL.EXE for program development

Gain experience with CAN bus and msCAN12 module
Develop a program to monitor and control some of the operations of the BOSCH Door
Module.
3 Materials and Methods
The following list of materials was used for the development of this laboratory:
3.1 Materials
Laboratory requirements document: 50_Lab5_Requirements_CAN_Bus_Ver2.1.doc

Lab5_CAN_bus_Background_and_overview.doc
Lab5_CAN_bus_BOSCH_BOX_overview_and_data.doc
Lab5_CAN_bus_how_to_use_D60_Card12__get_started.doc
Computer connected to evaluation boards in 87.3.07 lab.
BOSCH Demo Box located in 87.3.12 lab
Blackboard EEET2227: https://dls.rmit.edu.au/learninghub/hub.asp
3.2 Methods
The purpose of this laboratory is to program station five in order to establish communication
with the BOSCH box which is composed by two CAN modules. One module for the driver
and other for the passenger.
The architecture of this laboratory is shown if the following figure.

CAN Driver
Memory Module
CPU BOSH Box

CAN Passenger
Registers msCAN Module
BOSH Box with two CAN

Modules
68HC912D60A or Card 12 System 2 wires
Serial RS232
RxD, TxD GND
OCCONSOL.
exe
Host PC (Running OCCONSOL.EXE)

Figure 1: Architecture of this laboratory.
In order to achieve this goal some configuration needs to be performed. This is shown in the
following sections:
3.2.1 Initialize msCAN12 Controller
The msCAN12 is the specific implementation of the Motorola scalable CAN (msCAN)
concept targeted for the Motorola M68HC12 microcontroller family. A typical CAN system
with msCAN12 is shown as:

Figure 2: The CAN system from motorola M68HC12D60A (www.freescale.com, 2007/05/15)
3.2.1.1 Soft Reset Mode
Set msCAN12 in SOFT_RESET mode which is used to initialize the module configuration, bit
timing, and the CAN message filter:
Figure 3: msCAN12 Module Control Register 0
#define SFTRES 0x1

CMCR0 = SFTRES; //Soft Reset
When setting the SFTRES bit the msCAN12 immediately stops all ongoing transmissions and
receptions.
3.2.1.2 Clock Source
Set clock source to be EXTALi = 16MHz. The Card 12 System is working with an external clock
with 16 Mhz frequency.
Figure 4: msCAN12 Module Control Register 1

CMCR1 = 0; // Clock source EXTALi = 16Mhz
3.2.1.3 Configure the Synchronization Jump Width and Prescaler
Set Synchronization Jump Width (SJW1, SJW0) and Baud Rate Prescaler (BRP5 – BRP0).
Figure 5: msCAN12 Bus Timing Register 0
According to the RMIT BOSCH demo box configuration:
CAN Speed 62.5 Kbps

Quantum 2 uS
Sync Jump Width 2
Segment 1 5
Segment 2 2
Figure 6: BOSCH Box Timing
SJW1 and SJW0 are set 0 and 1 respectively by table:
Figure 7: SJW Bits in the M68HC12D60A
A time quantum is the atomic unit of time handled by the msCAN12 and a bit time is
subdivided into three segments:
SYNC_SEG: this segment has a fixed length of one time quantum.
Time segment 1: This segment includes the PROP_SEG and the PHASE_SEG of the CAN
standard.
Time segment 2: This segment represents the PHASE_SEG2 of the CAN standard.
According to the formula and above configuration table:
and
Bit Rate = 62.5Kbps
number of TimeQuanta = 1 + 5 +2 = 8

fTq = 62.5K * 8 = 500K
Presc value = 16M / 500K = 32
Figure 8: Table to define the prescaler value
Consequently, BRP5 – BRP0 = 011111

#define SJW 2
#define PRESCALER 32
CBTR0 = (SJW-1)<<6 | (PRESCALER-1); //SJW1,0=01 , preescale value=32
3.2.1.4 Set time segment
At this stage the time segments are defined. It is important in real applications (as it is this)
to contrast with the standard defined by (CAN Specification 2.0, part B) in the numeral 10
Bit Timing Requirements. This is because there are some constrains related with the number
of quanta that each segment can have.
Figure 9: msCAN12 Bus Timing Register 1 and its possible values
According to Demo box configuration: Time segment 1 = 5, Time segment 2 = 2
TSEG22 – TSEG20 = 001, and TSEG13 – TSEG10 = 0100

CBTR1 = (TSEG2-1) <<4 | (TSEG1-1); //Seg1 = 5, Seg2= 2, Sampling = 1 per bit.

3.2.1.5 Set Identifier Acceptance Filter
The identifier acceptance registers (CIDAR0 - 7) define the acceptable patterns of the
standard or extended identifier (ID10 – ID0 or ID28 – ID0). Any of these bits can be marked
don’t care in the identifier mask registers (CIDMR0 - 7).
A filter hit is indicated to the application software by a set RXF (receive buffer full flag) and
three bits in the identifier acceptance control register (CIDAC). These identifier hit flags
(IDHIT2 - 0) clearly identify the filter section that caused the acceptance.
Figure 10: msCAN12 Identifier Acceptance Control Register
In the case of this laboratory, the filter is programmable to operate in mode defined
following.
Two identifier acceptance filters: this mode implements two filters of 32 bits each.
Figure 11: Bits to define the operation mode of the Identifier Acceptance Filters
CIDAC = 0; //IDAM1 - IDAM0 = 0,0 Two 32 bit Acceptance Filters
On reception each message is written into the background receive buffer. If it passes the
criteria in the identifier acceptance and identifier mask registers (accepted); otherwise the
message is overwritten by the next message (dropped). CAN bus message frame shown as:
Figure 12: CAN 2.0A Frame (http://hem.bredband.net/stafni/developer/CAN.htm, 2007/05/15)

Figure 13: CAN 2.0B Frame (http://hem.bredband.net/stafni/developer/CAN.htm, 2007/05/15)
Because we used extended identifiers, all four acceptance and mask registers are applied:
From Demo box message list we can see messages with identifier 00BEEF1A and 00BEEF21
are receiving messages, so we define the ID acceptance filters for the two:
00BEEF1A: 0000 0101 111(1) (1)101 1101 1110 0011 010 (0) = 05FDDE34
00BEEF21: 0000 0101 111(1) (1)101 1101 1110 0100 001(0) = 05FDDE42
Where the number into the parenthesis refer to SRR, IDE and RSR bits respectively.
SRR = Substitute Remote Request Bit (Present only in extended Mode)

IDE = Identifier Extended Flag (1 indicates that Extended Format is used in this frame)
RTR = Remote Transmission request (0=Data Frame – as it is used in this laboratory and 1
= Remote Frame)
CIDAR0 = (IDRXMESS_1 & 0xFF000000) >> 24;

CIDAR1 = (IDRXMESS_1 & 0x00FF0000) >> 16;
CIDAR3 = (IDRXMESS_1 & 0x000000FF);

The masking registers are left in default value, ‘0’s in all bits.
Body Driver Passenger Byte

Identifier Bit Description Cycle Time
Computer Module Module DLC
00BEEF01 Talker Listener Listener 0 7..0 Command: Modules wake up. 25mS
3 Activate Mirrors
Listener 0 Ignition Enable (Also activates
Listener 0
Door Modules)
00BEEF03 Talker - 4 Unlock Drivers Door 20mS
2 Unlock Passengers Door
- Listener 5
1 Lock Passengers Door
Listener - 0 Lock Drivers Door
00BEEF04 Talker Listener Listener 1 4 Command: Switch Illumination. 80mS
00BEEF1 - Talker Listener 2 7 Mirror select Bit 0 40mS
A
6 Joystick Active

5 Joystick State Bit 1

4 Joystick State Bit 0
6 Passenger Window Down
5 Passenger Window Up
4 Drivers Window Down
- 3
3 Drivers Window Up
0 Mirror Select Bit 2
Listener
1 Mirror Select Bit 1
1 Lock Door Request
Listener - 4
0 Unlock Door Request
6 Passenger's Window Down
- 3
5 Passenger's Window Up
00BEEF21 - Talker 40mS
0 Lock Door Request
Listener 4
1 Unlock Door Request
Body Driver Passenger Byte
Identifier Bit Description Cycle Time
Computer Module Module DLC
Figure 14: Demo box message list (Kneen J, Heiko R, 2007)
The following shows the subroutine implemented to initialize the CAN interface:
void initCAN()
{
CMCR0 = SFTRES; //Soft Reset
CMCR1 = 0; // Clock source EXTALi = 16Mhz
CBTR0 = (SJW-1)<<6 | (PRESCALER-1); //SJW1,0=01 , preescale value=32
CBTR1 = (TSEG2-1)<<4 | (TSEG1-1); //Seg1 = 5, Seg2= 2, Sampling = 1 per bit.
//CRFLG and CTFLG are cleared since SFTRES = 1
CRIER = 0; //Interrupts disabled.

CTCR = 0; //TX Empty Interrupt disabled. It was disabled with SFTRES = 1
CIDAC = 0; //IDAM1 - IDAM0 = 0,0 Two 32 bit Acceptance Filters


//All of the bits in the MASK register are left to zero.
CMCR0 = 0; //Leave Soft Reset State.

}
3.2.1.6 Message Handle
After initializing the msCAN12 controller, we wrote MC68HC12 code to monitor and control
some of the operations of the BOSCH Door Module. For this laboratory the MC68HC12 will
act as the "Body Computer". According to Figure 8 (Demo box message list) we created an
infinite loop in main function to transmit and receive messages.
for (;;)

{
scheduler++;
if (scheduler >=4)
{
scheduler = 0;
}
/*
buffer 0 = 00BEEF01, buffer 1 = 00BEEF03 buffer 2 = 00BEEF04
*/
txMessage(0, 0, 0xFF); //awake message byte 0, bit=all(0xFF)
if (scheduler == 0) //Every 80 ms
{
txMessage(2, 1, 16); //Illuminate door switches Byte 1, bit 4
}
if (rxMessage())
{
//process the message
msgToTx = processMsg();
if (mirrorStatus > 0)
{
mirror[1] = mirrorStatus+ASCII_BASE;
printMsg(mirror); //Print the m and the value of the mirror
mirrorStatus = 0; //reset the mirror status
}
if (joysticStatus > 0) //Print the j and the value of the joystic
{
joystic[1] = joysticStatus + ASCII_BASE;
printMsg(joystic);
joysticStatus = 0;
}
}
txMessage(1, 0, (1 | 4)); //byte 0 bit 0 Ignition switch. Bit 2 Mirrors
PORTH = PORTH ^ 0x80; //toggle LED
delay(); //delay subroutine aprox 20 ms
}
3.3 Answer Questions
1. What is the purpose of the Start of Frame bit?
A: This start of frame bit is a dominant (logic 0) bit that indicates the beginning of the
message frame. It is used to synchronize each frame.
“The START OF FRAME (SOF) marks the beginning of DATA FRAMES and REMOTE
FRAMEs. It consists of a single ’dominant’ bit. A station is only allowed to start
transmission when the bus is idle. All stations have to synchronize to the leading
edge caused by START OF FRAME (see ’HARD SYNCHRONIZATION’) of the station
starting transmission first.” (CAN in Automation),
2. If two devices are transmitting on the CAN bus at the same time how is the priority
resolved?
A: The priority is resolved by bitwise the arbitration using the identifier. During
transmission every CAN device compares bit by bit what it is transmitting with what it is
reading from the bus. If the two values are equal the device continues transmitting
otherwise it will stop. The device that wins the bus is the one with the lowest value in the
arbitration field.

The arbitration fields from standard and extended frames can be seen in Figure 12 and
Figure 13 respectively.
3. It is possible to simultaneously use CAN 2.0A and 2.0B protocols. (11 bit and 29 bit
identifiers). How are they distinguished from each other?
A: The distinction between the two formats is made using an Identifier Extension (IDE)
bit. Furthermore, the r1 bit for the standard frame, in previous CAN specifications, is
redefined as IDE bit (CAN in Automation, 2002). Consequently, IDE=0 means standard
format and IDE=1 means extended format.
The frames for standard and extended frames can be seen in Figure 12 and Figure 13
respectively.
4. When a device has placed a message onto the CAN bus how does it know if that
message has been received? (Note: The question is not asking has a second device
responded/acted upon/used the message)
Figure 15: ACK Field. The ACK slot is used by the receiver to indicate successfully reception of the message.
Sending a dominant bit in the ACK slot.
A: This is done by Receiver by sending a dominant bit (logic 0) in the ACK slot of the
ACK field after receiving a successfully message (CAN in Automation 2002).
The transmitter normally send the ACK slot bit as a recessive but this bit is overwritten
(dominant logic 0) by the receiver as an indication of the reception of the message.
5. In Control Register 0 (address $0100) how is the bit SFTRES (Soft-Reset) used? i.e. what is
it used for a lot ?
A: When this bit is set by the CPU, the msCAN12 immediately enters the SOFT_RESET
state. When this bit is cleared by the CPU, the msCAN12 will try to synchronize to the
CAN bus: if the msCAN12 is not in BUSOFF state it will be synchronized after 11 recessive
bits on the bus; if the msCAN12 is in BUSOFF state it continues to wait for 128
occurrences of 11 recessive bits. Clearing SFTRES and writing to other bits in CMCR0
must be in separate instructions.
SOFT_RESET mode is used additionally to initialize the module configuration, bit timing,
and the CAN message filter (www.freescale.com, 2007/05/15).
6. How will the Bus Timing Registers (address $0102 and $0103) be initialized to match the
BOSCH box timings?

A: Details in sections 3.2.1.2 Clock Source, 3.2.1.3 Configure the Synchronization Jump
Width and Prescaler and 3.2.1.4 Set time segment.
7. In this experiment polling for new received messages will be used. At what address and
bit is the Receive Flag?
A: At address $0104 (CRFLG) and bit 0 (RXF). When a new message is received the CPU
reports it setting the Rx flag (RXF) to ‘1’. The user program must clear the flag writing ‘1’
into the RXF Bit.
8. Prior to transmitting a message the program should check that the last message has
been sent. How is this done?
A: The program will compare bit TXEx (x is 0, 1, 2 respectively) of the Transmitter Emply
Flag Register (CTFLG $0106). If TXEx is ‘1’, it means this transmission buffer is empty.
9. The BOSCH Demo Box will transmit two different messages (i.e. there will be two 29 bit
identifiers). How will Identifier Control Register (address $0108) be initialised to allow two
32 bit acceptance filters? How will the program know which one has been satisfied?
A: Both bits IDAM0 and IDAM1 are set to be ‘0’, and IDHIT2, IDHIT1 and IDHIT0 will
indicate which one has been satisfied. Due to the fact that we are only using two 32 bit
filters the system will only report two kind of hits (hit 0 or hit 1). Consequently, 000 means
Filter 0 Hit, 001 means Filter 1 Hit. See section 3.2.1.5 Set Identifier Acceptance Filter
10. The BOSCH Demo Box generates messages with identifiers $00BEEF1A and $00BEEF21.
How must the two 32 bit acceptance filters be initialised?
A: 00BEEF1A will be set in CIDAR0 – CIDAR3 as 05FDDE34 and 00BEEF21 will be set in
CIDAR4 – CIDAR7 as 05FDDE42. SRR (Substitute Remote Request) is always transmitter as
a recessive bit (logic 1), IDE = 1 (Extended Frame) and RTR = 0. More details about this
assignation can be seen in section 3.2.1.5 Set Identifier Acceptance Filter.
11. The BOSCH Demo Box will respond to messages with identifiers $00BEEF01, $00BEEF03
and $00BEEF04. How must the Transmitter Identifier Registers ($0150 through $0153) be
programmed.
Assuming that we are using only one buffer to transmit the three messages the following
shows how the transmitter identifier register must be configured for each message.
ID = $00BEEF01 B7 B6 B5 B4 B3 B2 B1 B0
IDR0 - $0150 = 0x05 0 0 0 0 0 1 0 1
IDR1 - $0151 = 0xFD 1 1 1 SRR=1 IDE=1 1 0 1
IDR2 - $0152 = 0xDE 1 1 0 1 1 1 1 0
IDR3 - $0153 = 0x02 0 0 0 0 0 0 1 RTR=0
ID = $00BEEF03 B7 B6 B5 B4 B3 B2 B1 B0
IDR0 - $0150 = 0x05 0 0 0 0 0 1 0 1
IDR1 - $0151 = 0xFD 1 1 1 SRR=1 IDE=1 1 0 1

IDR2 - $0152 = 0xDE 1 1 0 1 1 1 1 0

IDR3 - $0153 = 0x06 0 0 0 0 0 1 1 RTR=0
ID = $00BEEF04 B7 B6 B5 B4 B3 B2 B1 B0
IDR0 - $0150 = 0x05 0 0 0 0 0 1 0 1
IDR1 - $0151 = 0xFD 1 1 1 SRR=1 IDE=1 1 0 1
IDR2 - $0152 = 0xDE 1 1 0 1 1 1 1 0
IDR3 - $0153 = 0x08 0 0 0 0 1 0 0 RTR=0
A: In our solution we use the three buffers (one for each identifier). Consequently each
buffer is configured according with each message: 00BEEF01: 0x05FDDE02, 0x00BEEF03:
0x05FDDE06, 00BEEF04: 0x05FDDE08
volatile __uchar Tx0[16] _IO(0x150); /* CAN transmit buffer 0 */

Tx0[0] = 0x05; Tx0[1] = 0xFD; Tx0[2] = 0xDE; Tx0[3] = 0x02;
12. The message at identifier $00BEEF01 need only be one byte in length. How is this
programmed and into what register is the actual message placed.
A: This register is Data Length Register (DLR) which contains DLC3 – DLC0 data length
code bits at address $01xC (x is 4, 5, 6, 7 depending on which buffer RxFG, Tx0, Tx1, Tx2
respectively).
Tx0[0x0C] = 0x1;
13. How do you write and set bits for: The mask register ? (its not obvious, be careful !) and
The acceptance register ? (its not obvious, be careful !)
A: In order to set bits for the masking and the acceptance registers the msCAN module
must be in SOFT_RESET mode.
To receive standard identifiers in 32 bit filter mode it is required to program the last three
bits (AM2 – AM0) in the mask registers CIDMR1 and CIDMR5 to ‘don’t care’. To receive
standard identifiers in 16 bit filter mode it is required to program the last three bits (AM2
– AM0) in the mask registers CIDMR1, CIDMR5 and CIDMR7 to ‘don’t care’. In a
particular bit ‘0’ means Match corresponding acceptance code register and identifier
bits, and ‘1’ means ignore corresponding acceptance code register bit.
In acceptance register, Acceptance Code Bits (AC7 – AC0) comprise a user defined
sequence of bits with which the corresponding bits of the related identifier register
(IDRn) of the receive message buffer are compared.
14. The msCAN12 allowed two 32 bit identification filters. Indicate how the Identifier Mask
Register might be used if only one 32 bit filter were available.
A: When we have two 32 bit identification filters the configuration is the following.

ID = $00BEEF1A B7 B6 B5 B4 B3 B2 B1 B0
CIDAR0 = 0x05 0 0 0 0 0 1 0 1
CIDAR1 = 0xFD 1 1 1 SRR=1 IDE=1 1 0 1
CIDAR2 = 0xDE 1 1 0 1 1 1 1 0
CIDAR3 = 0x34 0 0 1 1 0 1 0 RTR=0
MASK for $00BEEF1A B7 B6 B5 B4 B3 B2 B1 B0

CIDMR0 = 0x00 0 0 0 0 0 0 0 0
CIDMR1 = 0x00 0 0 0 0 0 0 0 0
CIDMR2 = 0x00 0 0 0 0 0 0 0 0
CIDMR3 = 0x00 0 0 0 0 0 0 0 0
ID = $00BEEF21 B7 B6 B5 B4 B3 B2 B1 B0
CIDAR4 = 0x05 0 0 0 0 0 1 0 1
CIDAR5 = 0xFD 1 1 1 SRR=1 IDE=1 1 0 1
CIDAR6 = 0xDE 1 1 0 1 1 1 1 0
CIDAR7 = 0x42 0 0 1 0 0 0 1 RTR=0
MASK for $00BEEF21 B7 B6 B5 B4 B3 B2 B1 B0

CIDMR4 = 0x00 0 0 0 0 0 0 0 0
CIDMR5 = 0x00 0 0 0 0 0 0 0 0
CIDMR6 = 0x00 0 0 0 0 0 0 0 0
CIDMR7 = 0x00 0 0 0 0 0 0 0 0
If we had only one 32 bit acceptance filter the following could be one option for
configuring the acceptance registers and the masking registers.
ID = $00BEEF1A – 21 B7 B6 B5 B4 B3 B2 B1 B0
CIDAR0 = 0x05 0 0 0 0 0 1 0 1
CIDAR1 = 0xFD 1 1 1 SRR=1 IDE=1 1 0 1
CIDAR2 = 0xDE 1 1 0 1 1 1 1 0
CIDAR3 = 0x?? 0 ? ? ? 0 ? ? RTR=0
Mask: $00BEEF1A-21 B7 B6 B5 B4 B3 B2 B1 B0
CIDMR0 = 0x00 0 0 0 0 0 0 0 0
CIDMR1 = 0x00 0 0 0 0 0 0 0 0
CIDMR2 = 0x00 0 0 0 0 0 0 0 0
CIDMR3 = 0x00 0 1 1 1 0 1 1 0
The masking register bits ‘1’ indicate do not care. Furthermore, the application program
must compare the CIDAR3 with the values $34, $42 for the messages coming from the
Driver and Passenger modules respectively when a RXF and hit 0 are set.
15. In practice the Body Controller will receive its messages under interrupts. Indicate what
additional code will be required to handle interrupts. (Indicate in your answer any
registers that must be set)

A: In order to use interrupts in M68HC12 based systems some pre-configuration must be

done. Firstly, the global interrupt mask should be enabled. The condition code register
CCR contains the I bit which is set to I=1 after a reset occurs. This is done to disable all
interrupts (except for unmaskable interrupts1) until the program is ready for them.
Therefore, to enable global interrupts the instruction ANDCC #%11101111 should be
used, this set the I = 0 allowing the CPU to see the interrupts as the instruction ORCC
#%00010000 does the opposite (globally mask the interrupts). Secondly, it is necessary
to enable the second level of interrupt, which is associated with the interrupt source. In
this case the msCAN12 module.
Figure 16: msCAN12 receiver interrupt enable register (CRIER)
To enable reception messages by interrupts it is necessary to write ‘1’ in the bit RXFIE:
Receiver Full Interruption Enable.
Additional to this it is necessary to set the reset vector to redirect the interrupt to the
interrupt service routine (isr). Once there, the program application must receive the
data and handshake (clear the RXF) flag in order to continue receiving interrupts from
the msCAN module.
The procedure explained here is similar to the one developed in laboratory 3 (RS232
Serial Communications and Interrupts).
16. Each door module generates a message every 40mS. From your observations of the
waveforms estimate the absolute maximum number of similar modules there can be on
the bus. (A stretched limo?)
A: Each module is able to generate a frame of 128 bits approximately every 40 ms. It
means that each frame last 2.048 ms in average. Consequently, to reach the stretched
limo state around 19 devices can be in same CAN bus.
3.4 Configuration for this laboratory
As it was configured in previous laboratory (laboratory +3 standalone programs) the

following files were used:
crtsi.h12 file. It remained the same as lab3

setup12.s. This file was modified to configure SCI0 interface. Its contents can be seen in
Annex 1 – Setup12.s file.
Vector.c file Interrupts were not used in this laboratory.
1Unmaskable interrupts: RESET, Clock Monitor Fail, COP Failure, Unimplemented Code Trap,
Software Interrupt SWI and XIRQ. The order presented here represents the priority order from
1 to 6. (Cady F M and Sibigtroth J M, 2000).

Linker file 6812lkf.lkf (Figure 17). It was modified to configure the new main program
(lab5.c line 13).
Main program file lab5.c (Figure 23 in Annex 2 – Lab5.c file).
1. # LINK COMMAND FILE FOR TEST PROGRAM

2. # Copyright (c) 1996 by COSMIC Software
3. #
4. +seg .text -b 0x0200 -n .text # program start address for MC68HC812A4
5. +seg .const -a .text # constants follow code
6. +seg .data -b 0x05c0 # data start address
7. +def __sbss=@.bss # start address of bss
8. # Put you startup file here
9. setup12.o
10. "C:\Archivos de Programa\COSMIC\EVAL12\lib\crtsi.h12"
11. # Put your files here
12. #<FILE_LIST>
13. Lab5.o
14. "C:\Archivos de Programa\COSMIC\EVAL12\Lib\libi.h12"
15. "C:\Archivos de Programa\COSMIC\EVAL12\Lib\libm.h12"
16. +seg .const -b 0xffce # vectors start address
17. # Put your interrupt vectors file here if needed
18. +def __memory=@.bss # symbol used by library
19. +def __stack=0x05FF # stack pointer initial value
Figure 17: Linker file created into the COSMIC software (6812lkf.lkf)
3.4.1 Enabling the serial port.
In order to print messages in the screen regarding of the position of the mirror and the
joystick the serial port was enabled as it can be seen in the file Setup12.s in annex 1.
3.4.2 Program in operation.
The following conventions were defined in order to understand the messages printed by
the M68HC12 in the OC Console program.
P = Passenger Module.
D = Driver Module
w = window.
m = mirror.
j = joystick.
l = lock request.
u = unlock request
The following figure shows the behaviour of the program when it is running. It is possible to
observe different values sent by the M68CH12 module (through the serial port). For
example m0, m1, m2 as the position of the joystick j1, j2, etc. Additionally it is possible to
observe when the user selects the window switch; for example, Pwu (Passenger window
up), Pl(Passenger lock request), etc.

Figure 18: Application running, display shows OC Console receiving information regarding CAN modules
3.4.3 Configuring the OC Console
In order to operate with the OC Console the parameters showed in the following figures
must be configured.
Figure 19: Configuring the OC Console
Serial port (according with the host PC that is currently working). In this case COM1
Baudrate 19200, 8N1
File Transfer (wait for Handshake and character sequence ‘*’).
Once it is defined it is possible to transfer the program using the L function (loading) and
the selecting the *.s19 file to transmit it to the M68HC12 device.

Figure 20: Loading the file into the M68HC12 device. In this example the bosch.s19 file
3.4.4 The BOSCH box
As it was stated previously the BOSCH box contains two CAN devices one for the driver and
other for the passenger. The passenger module controls the side window and request the
door to be locked on unlocked. In the same way the driver module controls its window and
request the door the be locked and unlocked; and additionally, the window and door of
the driver.
In order to get familiarity with the BOSCH box it is important to load the BOSCH.S19 file into
the M68HC12 device in order to play with the switches and buttons. The procedure to load
the file is the same as explained in the previous section. The results of throwing the switches
and button are showed in the following figure.
Figure 21: BOSCH box operating with BOSCH.S19 file loaded into the M68HC12

Annex 1 – Setup12.s file
Setup12.s file used in this project. Basically, this files is used to disable the COP and to
configure and enable the serial port in order to print messages in the OC Console screen
1. COPCTL: EQU $0016 ; [A|B] COP Control Register

2. ;serial port
3.
4. TE: EQU %00001000 ;Transmitter Enable
5. RE: EQU %00000100 ;Receiver Enable
6. TDRE: EQU %10000000 ;TX Data Reg Empty
7. RDRF: EQU %00100000 ;RX Data Reg Full
8. MODE: EQU %00010000 ;Mode Bit
9. PE: EQU %00000010 ;Parity Enable
10. SC0BD: EQU $C0 ;BaudRate Register
11. SC0CR1: EQU $C2 ;Control Register 1
12. SC0CR2: EQU $C3 ;Control Register 2
13. SC0SR1: EQU $C4 ;Status Register
14. SC0DRL: EQU $C7 ;Data Register
15. IDLE: EQU %00010000 ;Idle interrupt
16. RIE: EQU %00100000 ;Receiver Interrupt
17.
18. xdef __prog
19. __prog:
20. clr COPCTL ;disable watch dog
21. ;serial port initialization
22. bclr SC0CR1,MODE ;1 start, 8 Data, 1 Stop
23. bclr SC0CR1,PE ;disable parity
24. ldd #$1A ;19200
25. std SC0BD ;baudrate 19200
Figure 22: Setup12.s file used in COSMIC software (Setup12.s)

Annex 2 – Lab5.c file
Lab5.c file is the main program executing in the M68HC12 device. A definitions.h file is
included, in this file some constants are defined. The contents of this can be seen in Annex
3 – definitions.h file.
1. #include "iod60.h"
2. #include "definitions.h"
3. #include <stdlib.h>
4.
5.
6. void initCAN();
7. //Buffer from 0..2
8. void txMessage(unsigned char buffer, unsigned char dlc, unsigned char bit);
9. int rxMessage(); //function prototype to evaluate if there is a new message
10. void delay(); //delay function aprox. 20 ms
11. int processMsg(); //this function is called if there is new message
12.
13. message_t messageRx; //structure defined to copy the message from the RxFG
14. int msgToTx;
15. void printChar(char value); //function that send a char to the serial port.
16. int printMsg(char message[]); //To print a message. This uses printChar function
17.
18. int temp=0;
19. char doorCommand=0;
20. char mirrorStatus=0;
21. char joysticStatus=0;
22. char mirror[]="m0";
23. char joystic[]="j0";
24.
25. void main(void)
26. {
27. //int i,j;
28. char scheduler=0; //scheduler counts every 20ms
29. char isNewMsg = FALSE;
30. char msgToTx = FALSE;
31.
32. resetBuffer(&Tx0[4]);
35.
36. printMsg("D,P,l,u,w,m,j\n"); //Start message printed in the OC Console
37.
38. initCAN(); //function to initialize the msCAN
39.
40. DDRH = 0x80; //led port bit 7 as an output
41.
42. for (;;) //infinite loop
43. {
44. scheduler++;
45. if (scheduler >=4) //Scheduler to tx messages. Increased every 20ms
46. {
47. scheduler = 0;
48. }
49. /*
50. buffer 0 = 00BEEF01, buffer 1 = 00BEEF03 buffer 2 = 00BEEF04
51. */
52. txMessage(0, 0, 0xFF); //awake message byte 0, bit=all(0xFF)
53.
54. if (scheduler == 0) //This event occurs Every 80 ms
55. {
56. txMessage(2, 1, 16); //Illuminate door switches Byte 1, bit 4
57. }
58.
59. if (rxMessage()) //Evaluate if there is message
60. {
61.
62. //process the message
63. msgToTx = processMsg();
64. if (mirrorStatus > 0)
65. {
66. mirror[1] = mirrorStatus+ASCII_BASE;
67. printMsg(mirror);
68. mirrorStatus = 0;
69. }
70.
71. if (joysticStatus > 0)

72. {
73. joystic[1] = joysticStatus + ASCII_BASE;
74. printMsg(joystic);
75. joysticStatus = 0;
76. }
77.
78. }
79.
80. txMessage(1, 0, (1 | 4)); //byte 0 bit 0 Ignition switch. Bit 2 Mirrors
81. PORTH = PORTH ^ 0x80; //toggle LED
82. delay(); //delay subroutine aprox 20 ms
83. }
84. }
85.
86. void initCAN()
87. {
88. CMCR0 = SFTRES; //Soft Reset
89. CMCR1 = 0; // Clock source EXTALi = 16Mhz
90. CBTR0 = (SJW-1)<<6 | (PRESCALER-1); //SJW1,0=01 , preescale value=32
91. CBTR1 = (TSEG2-1)<<4 | (TSEG1-1); //Seg1 = 5, Seg2= 2, Sampling = 1 per bit.
92.
93. //CRFLG and CTFLG are cleared since SFTRES = 1
94.
95. CRIER = 0; //Interrupts disabled.
96. CTCR = 0; //TX Empty Interrupt disabled. It was disabled with SFTRES = 1
97. CIDAC = 0; //IDAM1 - IDAM0 = 0,0 Two 32 bit Acceptance Filters
98.
99. CIDAR0 = (IDRXMESS_1 & 0xFF000000) >> 24;
100. CIDAR1 = (IDRXMESS_1 & 0x00FF0000) >> 16;
102. CIDAR3 = (IDRXMESS_1 & 0x000000FF);
103.
104. CIDAR4 = (IDRXMESS_2 & 0xFF000000) >> 24;
107. CIDAR7 = (IDRXMESS_2 & 0x000000FF);
108.
109. //ALl of the bits in the MASK register are left to zero.
110.
111. CMCR0 = 0; //Leave Soft Reset State.
112.
113. }
114.
115. /* buffer goes from 0 to 2. Where 0= IDTXMESS_1, 1=IDTXMESS_2 and 2=IDTXMESS_3
116. * dlc is the byte to transmit (from 0 to 7) and value is the value to transmit
117. * in the dlc byte.
118. */
119. void txMessage(unsigned char buffer, unsigned char dlc, unsigned char value)
120. {
121. char i;
122. switch (buffer)
123. {
124. case 0:
125. while ((CTFLG & TXE0) == 0){} //wait for TXE0 == 1 (Buffer free)
127.
128. //INIT TX BUffer.
129. Tx0[0] = (IDTXMESS_1 & 0xFF000000) >> 24;
130. Tx0[1] = (IDTXMESS_1 & 0x00FF0000) >> 16;
131. Tx0[2] = (IDTXMESS_1 & 0x0000FF00) >> 8;
132. Tx0[3] = (IDTXMESS_1 & 0x000000FF);
133.
134. Tx0[DLC_POS] = dlc+1; //assignation of dlc value; # of bytes to transmit
135. Tx0[4+dlc] = value;
136. Tx0[0xD] = 1; //Priority
137. CTFLG = CTFLG | TXE0; // Request to send info.
138. break;
139. case 1:
141.
142. //Init Tx1 Buffer
143. Tx1[0] = (IDTXMESS_2 & 0xFF000000) >> 24;
144. Tx1[1] = (IDTXMESS_2 & 0x00FF0000) >> 16;
145. Tx1[2] = (IDTXMESS_2 & 0x0000FF00) >> 8;
146. Tx1[3] = (IDTXMESS_2 & 0x000000FF);
147. //Tx1[4] = 1 | 4;
148. Tx1[4] = 0xD;
149. Tx1[5] = 0;
150. Tx1[6] = 0;
151. Tx1[7] = 0;
152. Tx1[8] = 0;
153. Tx1[9] = doorCommand;
154. Tx1[10] = 0;

155. Tx1[11] = 0;
156. Tx1[DLC_POS] = 6;
157.
160. break;
161. case 2:
163.
165.
166. //Init TX1 Buffer
167. Tx2[0] = (IDTXMESS_3 & 0xFF000000) >> 24;
168. Tx2[1] = (IDTXMESS_3 & 0x00FF0000) >> 16;
169. Tx2[2] = (IDTXMESS_3 & 0x0000FF00) >> 8;
170. Tx2[3] = (IDTXMESS_3 & 0x000000FF);
171.
172. Tx2[DLC_POS] = dlc+1; //assignation of dlc value; Number of bytes to
transmit
173. Tx2[4+dlc] = value;
176. break;
177. }
178. }
179.
180. int rxMessage()
181. {
182. char hit = FALSE;
183. char i;
184.
185. if ((CRFLG & RXF) >= 0) //New message arrived.
186. {
187. // Check for filter 0 or 1
188. switch (CIDAC & (IDHIT2 | IDHIT1 | IDHIT0))
189. {
190. //Filer 0 Hit
191. case 0:
192. messageRx.msgID = DRIVERMODULE; //msg 0x00BEEF1A (Driver Module)
193. hit = TRUE;
194. break;
195. //filter 1 Hit
196. case 1:
197. messageRx.msgID = PASSENGERMODULE; //msg 0x00BEEF21 (Passenger Module Module)
198. hit = TRUE;
199. break;
200. }
201.
202. if (hit)
203. {
204. for (i=0; i<DATA_LENGTH; i++)
205. {
206. messageRx.data[i] = RxFG[4+i];
207. }
208. messageRx.dlc = 0x0F & RxFG[DLC_POS]; //MASK last four bit in dlc
209. CRFLG = CRFLG | RXF; //Clear flag for next message.
210. }
211. return TRUE;
212. }
213. else
214. {
215. return FALSE;
216. }
217. }
218.
219. int processMsg()
220. {
221. char msgToTx=FALSE;
222. char i,temp;
223. if (messageRx.msgID == DRIVERMODULE)
224. {
225. for (i=2; i<messageRx.dlc; i++)
226. {
227. switch(i)
228. {
229. case 2:
230.
231. if ((messageRx.data[i] & JOYSTIC_BIT0) > 0)
232. {
233. joysticStatus = joysticStatus | 1;
234. }
235. if ((messageRx.data[i] & JOYSTIC_BIT1) >0)
236. {


238. }
239. if ((messageRx.data[i] & JOYSTIC_ACTIVE) > 0)
240. {
242. }
243. if ((messageRx.data[i] & MIRROR_BIT0) > 0)
244. {
245. mirrorStatus = mirrorStatus | 1;
246. }
247. break;
248. case 3:
249. if ((messageRx.data[i] & MIRROR_BIT1) > 0)
250. {
252. }
253. if ((messageRx.data[i] & MIRROR_BIT2) >0)
254. {
256. }
257. /* if ((messageRx.data[i] & DRIV_DRIVER_W_UP) > 0)
258. {
259. msgToTx = printMsg("Dwu");
260. }
261. if ((messageRx.data[i] & DRIV_DRIVER_W_DOWN) > 0)
262. {
263. msgToTx = printMsg("Dwd");
264. }/*
265. if ((messageRx.data[i] & DRIV_PASSENGER_W_UP) > 0)
266. {
267. msgToTx = printMsg("Dpwu");
268. }
269. if ((messageRx.data[i] & DRIV_PASSENGER_W_DOWN) > 0)
270. {
271. msgToTx = printMsg("Dpwd");
272. }*/
273. break;
274. case 4:
275. if ((messageRx.data[i] & DRIVER_LOCKREQUEST) > 0)
276. {
277. doorCommand = LOCKDOOR_DRIVER;
278. }
279. if ((messageRx.data[i] & DRIVER_UNLOCKREQUEST) >0)
280. {
281. doorCommand = UNLOCKDOOR_DRIVER;
282. }
283. break;
284. }
285. }
286. }
287. else if (messageRx.msgID == PASSENGERMODULE)
288. {//case PASSENGERMODULE:
289. for (i=0; i<messageRx.dlc; i++)
290. {
291. switch(i)
292. {
293. case 3:
294. if ((messageRx.data[i] & PASS_PASSENGER_W_UP) > 0)
295. {
296. msgToTx = printMsg("Pwu");
297. }
298. if ((messageRx.data[i] & PASS_PASSENGER_W_DOWN) >0)
299. {
300. msgToTx = printMsg("Pwd");
301. }
302. break;
303. case 4:
304. if ((messageRx.data[i] & PASSENGER_LOCKREQUEST) > 0)
305. {
306. doorCommand = LOCKDOOR_PASSENGER;
307. }
308. if ((messageRx.data[i] & PASSENGER_UNLOCKREQUEST) >0)
309. {
310. doorCommand = UNLOCKDOOR_PASSENGER;
311. }
312. break;
313. }
314. }
315. }
316. return TRUE;
317. }
318.
319. void printChar (char value)

320. {
321. while ((SC0SR1 & TDRE) == 0){} //Wait for RegisterEmpty
322. SC0DRL = value;
323. }
324.
325. int printMsg (char message[])
326. {
327. char i,j;
328. j = strlen(message);
329. for (i=0 ; i < j ; i++)
330. {
331. printChar(message[i]);
332. }
333. return TRUE;
334. }
335.
336. resetBuffer(char buffer[])
337. {
338. char i;
339. for (i=1;i<8;i++)
340. {
341. buffer[i] = 0;
342. }
343. }
344.
345. void delay() //Every count in i represents 1 millisecond
346. {
347. int i, j;
348. for (i=0; i<20; i++) //Every count in i represent 1 millisecond
349. {
350. for (j=0; j<1333; j++){}
351. }
352.
353.
354. }
355.
356. @interrupt void _isr(void)
357. {
358.
359. }
360.
361. @interrupt void _dummy(void)
362. {
363. }
Figure 23: Lab3.c code
Annex 3 – definitions.h file
This files defines some constant values used in the main program (lab3.c).
1. #define FALSE 0
2. #define TRUE 1
3. #define SFTRES 0x1
4. #define CSWAI 0x20
5. #define SYNCH 0x10
6. #define TLNKEN 0x08
7. #define WUPM 0x02
8. #define CLKSRC 0x01
9. #define SJW 2
10. #define PRESCALER 32
11. #define TSEG1 5
12. #define TSEG2 2
13. #define RXF 1
14. #define TXE0 1
15. #define TXE1 2
16. #define TXE2 4
17. #define IDHIT0 1
20. #define IDRXMESS_1 0x05FDDE34 //0x00BEEF1A
21. #define IDRXMESS_2 0x05FDDE42 //0x00BEEF21
22.
23. #define IDTXMESS_1 0x05FDDE02 //0x00BEEF01
26.
27. #define DLC_POS 0x0C
28. #define DATA_LENGTH 8

29.
30. #define DRIVERMODULE 1
31. #define PASSENGERMODULE 2
32.
33. #define MIRROR_BIT0 0x80
36.
37. #define JOYSTIC_ACTIVE 0x40
38. #define JOYSTIC_BIT0 0x10
39. #define JOYSTIC_BIT1 0x20
40.
41. #define DRIV_DRIVER_W_UP 0x08
42. #define DRIV_DRIVER_W_DOWN 0x10
43. #define DRIV_PASSENGER_W_UP 0x20
44. #define DRIV_PASSENGER_W_DOWN 0x40
45.
46. #define DRIVER_LOCKREQUEST 0x01
47. #define DRIVER_UNLOCKREQUEST 0x02
48.
49. #define PASS_PASSENGER_W_UP 0x20
50. #define PASS_PASSENGER_W_DOWN 0x40
51.
52. #define PASSENGER_LOCKREQUEST 0x01
53. #define PASSENGER_UNLOCKREQUEST 0x02
54.
55. #define LOCKDOOR_DRIVER 0x01
56. #define UNLOCKDOOR_DRIVER 0x10
57.
58. #define LOCKDOOR_PASSENGER 0x02
59. #define UNLOCKDOOR_PASSENGER 0x04
60.
61. #define TDRE 0x80
62. #define ASCII_BASE 0x30
63.
64. typedef struct messageStruct
65. {
66. unsigned char msgID;
67. unsigned char data[8];
68. unsigned char dlc;
69. } message_t;
Figure 24: definitions.h file. Some constant values are defined

4 Conclusions
This laboratory was a good practical exercise to work CAN bus.
In order to work with the BOSCH box is important to send continuously the wake up
message command to the modules.
It is important to understand how to configure the Identifier Acceptance Register (CIDAR)

and the masking registers.
Once again COSMIC software is a powerful tool that allows in an easier way to implement
M68HC12 applications. In order to use properly this software the programmer must
configure properly the linker file. In fact, the linker file must relate all of the files used in the
project; start-up code, crtsi.h12 file, program file, additional library files and vector file.

5 References
Cady F M, 2000, Software and Hardware Engineering Motorola 68HC12, Oxford University
Press, INC., New York, USA.
Nilsson S, 2007, ‘Controller Area Network – CAN Information’,
http://hem.bredband.net/stafni/developer/CAN.htm, 2007/05/15.
Kneen J, Rudolph H, 2007, EEET2227 Microcomputer Systems Design Learning Guide,
Lecture Notes School of Electrical and Computer Engineering, RMIT University,
Melbourne, Australia.
CAN in Automation, 2002, ‘CAN Specification 2.0, part B’, www.can-cia.org , 2007/05/15.
Spasov P, 2004, Microcontroller Technology the 68HC11 and 68HC12, Fifth Edition, Prentice
Hall, New Jersey, USA.


EEET2227 Microcomputer Systems Design

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

EEET2227 Microcomputer Systems Design

Încărcat de

Drepturi de autor:

Formate disponibile

EEET2227 Microcomputer Systems Design

Laboratory #5: CAN Bus

Lecturer: Dr. Heiko E. R. Rudolph (heiko.rudolph@rmit.edu.au)

Student: Xiang Li (s3148918@student.rmit.edu.au)

Subject Code: EEET2227 Microcomputer Systems Design

Melbourne, June 1st, 2007

RMIT University © 2007 2 of 29

Figure 1: Architecture of this laboratory..............................................................................................5

RMIT University © 2007 3 of 29

The aim of this laboratory is:

Use monitor program OCCONSOL.EXE for program development

3 Materials and Methods

Laboratory requirements document: 50_Lab5_Requirements_CAN_Bus_Ver2.1.doc

The architecture of this laboratory is shown if the following figure.

RMIT University © 2007 4 of 29

CPU BOSH Box

BOSH Box with two CAN

Host PC (Running OCCONSOL.EXE)

3.2.1 Initialize msCAN12 Controller

RMIT University © 2007 5 of 29

Figure 2: The CAN system from motorola M68HC12D60A (www.freescale.com, 2007/05/15)

3.2.1.1 Soft Reset Mode

Figure 3: msCAN12 Module Control Register 0

#define SFTRES 0x1

3.2.1.2 Clock Source

Figure 4: msCAN12 Module Control Register 1

RMIT University © 2007 6 of 29

CMCR1 = 0; // Clock source EXTALi = 16Mhz

3.2.1.3 Configure the Synchronization Jump Width and Prescaler

Figure 5: msCAN12 Bus Timing Register 0

According to the RMIT BOSCH demo box configuration:

CAN Speed 62.5 Kbps

SJW1 and SJW0 are set 0 and 1 respectively by table:

Figure 7: SJW Bits in the M68HC12D60A

SYNC_SEG: this segment has a fixed length of one time quantum.

According to the formula and above configuration table:

Bit Rate = 62.5Kbps

RMIT University © 2007 7 of 29

fTq = 62.5K * 8 = 500K

Presc value = 16M / 500K = 32

Figure 8: Table to define the prescaler value

Consequently, BRP5 – BRP0 = 011111

CBTR0 = (SJW-1)<<6 | (PRESCALER-1); //SJW1,0=01 , preescale value=32

3.2.1.4 Set time segment

Figure 9: msCAN12 Bus Timing Register 1 and its possible values

According to Demo box configuration: Time segment 1 = 5, Time segment 2 = 2

TSEG22 – TSEG20 = 001, and TSEG13 – TSEG10 = 0100

RMIT University © 2007 8 of 29

3.2.1.5 Set Identifier Acceptance Filter

Figure 10: msCAN12 Identifier Acceptance Control Register

CIDAC = 0; //IDAM1 - IDAM0 = 0,0 Two 32 bit Acceptance Filters

Figure 12: CAN 2.0A Frame (http://hem.bredband.net/stafni/developer/CAN.htm, 2007/05/15)

RMIT University © 2007 9 of 29

Figure 13: CAN 2.0B Frame (http://hem.bredband.net/stafni/developer/CAN.htm, 2007/05/15)

SRR = Substitute Remote Request Bit (Present only in extended Mode)

CIDAR0 = (IDRXMESS_1 & 0xFF000000) >> 24;

CIDAR4 = (IDRXMESS_2 & 0xFF000000) >> 24;

Body Driver Passenger Byte

RMIT University © 2007 10 of 29

5 Joystick State Bit 1

//CRFLG and CTFLG are cleared since SFTRES = 1

CRIER = 0; //Interrupts disabled.

CIDAR0 = (IDRXMESS_1 & 0xFF000000) >> 24;