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…