By: David Cohen & Gadi Gilad
Instructor: Boaz Mizrahi
Project Final Presentation
CAN Bus LoggerPart B
Spring 2012
CAN - Controller Area Network.
CAN is a vehicle bus standard designed to allow
microcontrollers and devices to communicate with
each other within a vehicle without a host
computer.
It’s a message-based protocol, designed
specifically for automotive applications, such as
reading the values of sensors and control units in
the vehicle.
Introduction
Reminder
The First Part Of The Project
This project was a continuation of the first project
we’ve done in the HSDS lab. In part A we focused
on embedding CAN bus capabilities on the lab’s
PCB.
The main goal of this project was to receive CAN
messages from a vehicle, and showing them on the
PCB’s screen.
Differences between the
projectsThe significant differences between the
previous project and the current one
Current Project Previous Project
dsPIC33 – the MAC and MCU are on the same chip
PIC18 - the MAC unit and processing unit are separate
Controller
USB and BT connection via an external terminal
Connected to the device itself
Keyboard and screen
16 bits architecture. DMA
8 bits architecture Memory structure
Differences between the
projectsThe significant differences between the
previous project and the current one
Current Project Previous Project
Using AT commands via a laptop’s terminal
Sending and receiving CAN messages via the PCB’s “GUI”
Type of connection
A part of a big and complex code, meant for other uses too
Independent code meant mainly for CAN communication
Code
Some None Experience
Find and purchase the correct evaluation board for
the project need, and connect it to an external
hardware
Program and install the software for the board’s USB,
and to the board’s transceiver, and making them
work together
Send and receive packets in internal and “external”
Loopback mode
Configure the device to communicate with the old
PCB and then with the car
Fixing code and hardware to work with the new MW-
board
Send CAN queries to the car and receive the
responses in high frequencies
Main Goals
These devices have been in use for the communication
A computer’s terminalFrom the terminal we send commands via a USB
connection to the demo board (or via Bluetooth, in the new MW-board)
The hardware
These devices have been in use for the communication
Microchip’s dsPIC33E, upon a USB Demo Board
We configured 2 of the chip’s remappable peripherals to use CAN, and connected them to the other board via the connector
The hardware
These devices have been in use for the communication
MCP2551 CAN transceiver, upon an ELM327 (commercial board designed to communicate with vehicles)
Here we attached ground and power, and connected the cables coming from the PIC
The hardware
These devices have been in use for the communication
An OBD II connector
From the ELM, the cables go to the OBD connector, and from there connect to the vehicle
The hardware
These devices have been in use for the communication
The whole board
Eventually we have connected the 2 ELMs from both sides of the demo board. The cables are connecting power, ground and data
The hardware
The configuration process
Performing internal Loopback
PICdsPIC33e
Connector
STARTER KIT
USB
PICdsPIC33e
Connector
PHYMCP2551
CAN-High
CAN-Low
STARTER KIT ELM327
USB
RX
TX
CAN1PHYMCP2551
CAN-High
CAN-Low
ELM327CAN2 RX
TX
The configuration process
Performing “external” Loopback
PICdsPIC33e
Connector
PHYMCP2551
CAN-High
Ground
CAN-Low
STARTER KIT ELM327
USB
RX
TX
The configuration process
Connecting to the car
Stages in getting the vehicle status1. Using the keyboard to write AT commands (e.g. “at
010d”), and sending it to the device via USB/BT
Stages in getting the vehicle status2. Going to the OBD-query section in the program
memory of the device
Stages in getting the vehicle status3. The CAN query (e.g. “7DF 02 01 0D”) is transmitted
to the vehicle from the TX buffer on the board
Stages in getting the vehicle status4. The packet is sent from the CANH-CANL pins to the
OBDII connector of the vehicle
Stages in getting the vehicle status5. The relevant MCU inside the vehicle is receiving the
packet, then sending back the requested status in a
CAN response structure (e.g. “7E8 03 41 0D 100”)
Stages in getting the vehicle status6. The response packet is entered the RX buffer in the
device and an interrupt is generate
Stages in getting the vehicle status7. The data received and kept in the flash memory,
then sent back to the screen.
Working on the projectSome of the problems we had during our work,
and their solutions
The problem: Both code versions of sending and
receiving messages in loopback, and communicating
between the computer and device via USB were
working OK separately, but didn’t work combined.
The solution: The variable which held the message
that needed to be transmit got corrupted when using
the USB code. Putting this variable in a protected area
in the memory, with access to both DMA and MCU,
resolved the problem.
Working on the project
The problem: When trying to perform an “external”
loopback the data hadn’t been transformed between
the two ELM-transceiver parts.
The solution: After Scope checking we noticed one
of the ELM is out of order. Since there was a signal
from the other ELM, we connected it to the PCB.
Some of the problems we had during our work,
and their solutions
Working on the project
The problem: After already having a good stable
signal, suddenly no signal had occur.
The solution: Checking the Demo Board parts with
a Scope and a DVM showed that one diode coming
from the USB connector is burned, thus the PIC
doesn’t get enough power. Replacing the diode
brought the board to work properly.
Some of the problems we had during our work,
and their solutions
Working on the project
The problem: The device could get messages
properly, but when receiving them in a high rate, a
lot of errors had occurred.
The solution: Trying different methods of received
packet handling, such as using FIFO for incoming
messages, didn’t solve the problem. Eventually,
code debugging and a more stable MW code have
brought to satisfying results.
Some of the problems we had during our work,
and their solutions
Working on the project
The problem: When using the MW-board, based on
BT communication, instead of the USB based board,
it couldn’t send and receive data.
The solution: Checking soldering and connections
on the board, then checking the voltage on several
places on it, showed that the PHY chip is burned,
and needs to be replace.
Some of the problems we had during our work,
and their solutions
Using one AT command to send a query to the car,
receive it’s response and print it to the screen
Using other important AT commands
Working on the USB device in very high rates,
including “monitor all” command (about 1300
packets/sec)
Working on the BT device, also in high rates (monitor
all command works well when sending to the BT only
2 chars, due to it’s lower band-width)
Capabilities
Notes…