SCHOOL OF ENGINEERING

EEET2394 – ELECTRONIC SYSTEMS FOR AUTOMOTIVE APPLICATIONS

LABORATORY 3

CAN BUS COMMUNICATION AND CONTROL

1 AIMS

(i) To develop firmware on an industry standard microprocessor to emulate the lower

(ii) To understand the method in which the CAN Bus transfers information to various
nodes on the network.

(iii) To develop an appreciation of the complex nature of the CAN Bus and how the
parameters within the published specifications relate to the physical data
transmission.

2 INTRODUCTION

Students may work in groups of up to three (3), however each student must submit and individual
report which will be assessed by the laboratory demonstrator. This laboratory project will run for
three weeks (weeks 7–9), with submission due by the end of week 9 (electronic submission via the
subject Canvas website).

In this laboratory project, you will be required to design and implement firmware for an industry
standard microcontroller (the STM32F103) to communicate over the Controller Area Network
(CAN) bus.

In a modern motor vehicle, various microprocessor systems are required to communicate with each
other. Developed by Bosch in the early 1990s, the CAN bus is the typical means in which various
devices can share information. This typically results in a reduction of the overall cost and complexity
of the various systems. Furthermore, by sharing information every device on the network contains
the same data (data consistency) and can act upon it simultaneously if necessary. A device on the
network is referred to as a ‘node’.

The CAN bus forms the lowest level of the communication stack. The CAN specification [1] is
concerned only with the physical and data-link layers of the 7-layer Open Systems Interconnection
(OSI) reference model. Additional protocols build on top of the CAN specification to provide support
for network addressing (both source and target), multi-packet payloads and packet routing.

To limit errors caused by noise, the CAN bus is designed around a differential signalling system. Two
wires, termed CAN_H and CAN_L are used to transmit the signal.

Page 1 of 4
EEET2394 Laboratory 3 – CAN Bus Communication and Control

The CAN bus uses a non-return to zero (NRZ) encoding scheme, representing binary data using two
distinct states – ‘dominant’ (logic 0) and ‘recessive’ (logic 1). A CAN bus idles in the ‘recessive’
state, with both signal wires typically close to VCC/2. When a logic 0 bit is to be sent over the bus,
the transmitter asserts the ‘dominant’ state, driving the signalling wires (CAN_H and CAN_L) in
opposite directions to obtain a differential signal (between 0.9 and 5.0V difference).

Figure 1 illustrates the basic structure of a CAN data frame.

Figure 1. CAN data frame structure [2].

A CAN data frame consists of five fields which can be summarised follows:

a) Arbitration. The arbitration field is used to describe the ‘type’ of data that is present in the
payload (a CAN network only specifies the type of data being sent rather than device addresses).
Arbitration fields with lower numerical values have higher priority. In standard CAN addressing,
the arbitration field contains an 11-bit CAN Identifier, whereas in extended CAN addressing the
arbitration field contains a 29-bit CAN Identifier. The arbitration field includes a single bit to
indicate which addressing mode is in operation.

b) Control. The control field is used to indicate the size of the data payload. The payload can
contain a maximum of eight (8) bytes (64-bits).

c) Data. The data field contains the payload. The size of the payload must match that specified in
the control field.

d) CRC. A CRC is used to determine whether the data packet has been transmitted successfully.

e) Ack. An acknowledgement field is used to signify the message has ended. In the case of the
transmitter this will be two ‘recessive’ bits. The receivers will acknowledge by sending a single
‘dominant’ bit.

In this laboratory project, you are required to design and implement a basic CAN bus node. The
firmware will be developed (and assessed) using the STM32F103 simulator provided within Keil
uVision [3]. The hardware context (assumed in the specifications below) is that of the Keil
MCBSTM32E development board [4].

Figure 2 depicts the basic configuration of the laboratory. You are required to develop firmware for
CAN Node 1. CAN Node 1 must monitor the state of the ‘USER’ and ‘WAKEUP’ switches and
sample a single analog input (using an analog to digital converter, ADC), transmitting these three
values over the CAN bus 5 time per second. CAN Node 1 must also receive messages over the CAN
bus (from CAN Node 2), and correctly interpret and respond to them as described below.

Page 2 of 4
EEET2394 Laboratory 3 – CAN Bus Communication and Control

Figure 2. Laboratory CAN bus structure.

The required functionality of the firmware for CAN Node 1 is summarised in Table 1. A set of debug
and ‘signal’ functions will be provided to simulate the external inputs to CAN Node 1 (i.e., the USER
and WAKEUP switches, and the analog input signal, as well as traffic on the CAN bus from CAN
Node 2).
CAN Node 1 Value Notes
Addressing mode 29-bit
CAN data rate 250 kBit/s
CAN update rate 5 Hz Tx update rate of 5 Hz is required
Transmit
ADC CAN identifier 0xBADCAFE Transmit lower 4 bytes
USER switch CAN identifier 0x01AEFCA 1 byte payload (0x00 = Closed, 0x01 = Open)
WAKEUP switch CAN identifier 0x0002BEF 1 byte payload (0x00 = Closed, 0x01 = Open)
Receive
LED14 CAN identifier 0x01A4F2B 1 byte payload (0x00 = Off, 0x01 = On)
LED15 CAN identifier 0x0024FCE 1 byte payload (0x00 = Off, 0x01 = On)

Table 1. CAN Node 1 requirement specifications1.

From Table 1 it can be seen that CAN Node 1 must send the lower 4 bytes from the A/D converter
over the CAN bus with CAN Id 0xBADCAFE. Similarly, CAN Node 1 must send the state of the
USER and WAKEUP switches with CAN Ids 0x01AEFCA and 0x0002BEF, respectively.

Furthermore, if CAN Node 1 receives a payload of 0x01 (1 byte) with CAN Id 0x01A4F2B then
LED14 should turn on (a payload of 0x00 should turn LED14 off). A similar requirement exists for
LED15 (with CAN Id 0x0024FCE).

3 LABORATORY DEVELOPMENT

The development of this laboratory is significantly different to that of the two previous laboratory
projects. The requirements, outlined above, have been designed to allow the firmware implementation
to be divided into three approximately equal sections (CAN transmission, CAN reception and I/O
(Input/Output) handling). Students may work in groups of up to three (3). However, each member of
the group must submit an individual report explaining the design and implementation of their code in
detail.

1
Refer to the MCBSTM32E Base Board Schematic in [4] for MCU pins corresponding to the ADC, USER and
WAKEUP switches, LEDs 14 and 15, and the CAN_Tx and CAN_Rx signals.

Page 3 of 4
EEET2394 Laboratory 3 – CAN Bus Communication and Control

As noted above, students should utilise the simulation tools for the STM32F103 microcontroller
provided within the development environment (Keil µVision). A code limited licence of Keil uVision
can be downloaded from the Keil website [3].

To develop and test the CAN functionality using the simulator, the CAN transceiver should be placed
in ‘loop back’ mode. In this mode, data transmitted by the CAN transceiver will be immediately
‘echoed’ back to the device.

To receive full marks for the laboratory you will need to demonstrate that your code performs as per
the specifications in Table 1.

4 REPORT

At a minimum, your laboratory report should include the following:

a) A flowchart illustrating the various steps and function calls utilised.

b) Pseudocode for the user-defined functions that have been developed.

c) A description of the testing undertaken and how faults were rectified.

d) A breakdown of the tasks completed by the individual group members.

Note: The source code (as a Keil uVision project) for each group must be submitted for assessment
via Canvas, by the due date of the laboratory. Failure to upload the code so that it can be tested will
result in a maximum mark of 30%.

At a minimum, the source code submitted must compile otherwise that component will score 0%.

Your report should not exceed 10 content pages.

5 SUGGESTED REFERENCES
[1] Robert Bosch, CAN Specification, version 2.0. Stuttgart, 1991.
[2] Di Natale, Marco, "Understanding and using the Controller Area Network", Figure 2.7, pp.
18, 2008.
[3] Keil, MDK Product Page, http://www2.keil.com/demo/eval/arm.htm [Online]. Accessed
2020-04-19.
[4] Keil, MCBSTM32E Product Page, https://www.keil.com/boards2/keil/mcbstm32e/ [Online].
Accessed 2020-04-19.
[5] ST Microelectronics, "STM32F103xx Performance Line Datasheet", Revision 13, July
2018.
[6] ST Microelectronics, "RM0008 – Reference Manual, STM32F10x Technical Reference
Manual (TRM)", Revision 20, pp. 113, 2018.

Page 4 of 4