Difference between revisions of "ECE497 CAN Cape"

From eLinux.org
Jump to: navigation, search
(Created CANcape variant of project description page)
 
m
 
(32 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:ECE497 |PC]]
+
 
 +
[[Category:ECE497Fall2016 |PC]]
 
{{YoderHead}}
 
{{YoderHead}}
  
Team members: [[user:Mehlda|David Mehl]], (List all the team members here with link to their eLinux User page.  Use my format.)
+
Team members: [[user:Mehlda|David Mehl]] and [[user:Khansa| Sabeeh Khan]]
  
 
== Grading Template ==
 
== Grading Template ==
 +
 
I'm using the following template to grade.  Each slot is 10 points.
 
I'm using the following template to grade.  Each slot is 10 points.
 
0 = Missing, 5=OK, 10=Wow!
 
0 = Missing, 5=OK, 10=Wow!
  
 
<pre style="color:red">
 
<pre style="color:red">
00 Executive Summary
+
10 Executive Summary
00 Installation Instructions  
+
10 Installation Instructions  
00 User Instructions
+
10 User Instructions
00 Highlights
+
10 Highlights
00 Theory of Operation
+
10 Theory of Operation
00 Work Breakdown
+
10 Work Breakdown
00 Future Work
+
10 Future Work
00 Conclusions
+
10 Conclusions
00 Demo
+
10 Demo
00 Late
+
10 Not Late
Comments: I'm looking forward to seeing this.
+
Comments: Very nice project.  Well presented both in demo and in wiki.
  
Score:  10/100
+
Score:  100/100
 
</pre>
 
</pre>
  
<span style="color:red">(Inline Comment)</span>
+
== WARNING ==
 +
Accessing your vehicle's CAN bus can be a dangerous endeavor. Reading the bus is typically not a problem, however sending messages can disrupt the operation of the vehicle, cause trouble codes, and potentially lead to undesired operation of the vehicle, up to and including moving under its own discretion. Needless to say, this can FATALLY INJURE YOU, so be careful. We are not responsible for any outcomes that the use of the provided hardware design or software may cause. There is no warranty.
  
 
== Executive Summary ==
 
== Executive Summary ==
Our project combines a cape circuit board design with the necessary software to view the messages on a CAN bus, and the use of jumpers allows for the cape to be adaptable to different situations (such as CAN development, sniffing a vehicle bus, evaluating CAN transceivers, etc) by allowing the user to select whether or not to use a terminating resistor, 3.3V or 5V for the transceiver chip, and if they would like an OBD-II signal ground to be connected to the ground pour of the board.
+
Our project combines a cape circuit board design with the necessary software to configure the Beaglebone Black in order to view the messages on a CAN bus using the can-utils package. The use of jumpers allows for the cape to be adaptable to different situations (such as CAN development, sniffing a vehicle bus, evaluating CAN transceivers, etc) by allowing the user to select whether or not to use a terminating resistor, 3.3V or 5V for the transceiver chip Vcc, and if they would like an OBD-II signal ground to be connected to the ground of the board.
 +
 
 +
The second revision of the circuit board has been tested and is fully functioning as expected, and the configuration script is setting up the pins properly. We were able to read the CAN messages off of a homemade CAN bus built out of two dsPIC33EV256GM102 microcontrollers, and we were able to read the CAN messages off of a 2012 Mazda CX-5. We have used a couple different CAN transceivers and achieved success with both.
 +
 
 +
This CAN cape will be an excellent tool for anyone wishing to look at CAN communication traffic on a bus or attempting to explore CAN system development. It will be flexible enough to meet almost all CAN development needs with only minor adjustments required to the setup steps to achieve different functionality (active bus participant vs. spy, setting bitrate, etc).
 +
 
 +
== Packaging ==
 +
 
 +
This project includes a printed circuit board. The project files can be found in the Github repository. The schematic symbols and part footprints are also found in the repo. See the below Installation Instructions and Hardware Instructions for information on how to use the included files. Further, see Theory of Operation for the functional description of the physical cape PCB
 +
 
 +
== Installation Instructions ==
 +
 
 +
The installation of this project is relatively simple. First, begin by cloning the github repository:
 +
'''root@beagle$ git clone https://github.com/SabeehKhan18/Beaglebone-CAN-Cape.git'''
 +
 
 +
Be sure you have disabled the HDMI in /boot/uEnv.txt by uncommenting:
 +
'''dtb=am335x-boneblack-emmc-overlay.dtb'''
 +
 
 +
If you had not previously done the above, you will need to reboot after uncommenting the line.
 +
 
 +
Next, run the installation script included in the repo. The installation script installs the linux package 'can-utils' on the beaglebone. This package has the software necessary to make sense of the messages on the bus and provides a display interface:
 +
'''root@beagle$ cd Beaglebone-CAN-cape/'''
 +
'''root@beagle$ ./install.sh'''
 +
 
 +
Then, be sure you are operating as root, and then source the setup script. This will configure the pin muxes for dcan1, which operates on P9_24 and P9_26. It also uses P8_13 to control the CAN transceiver STANDBY pin. Then it sets up the interface can1. You must provide the bitrate of the CAN bus as an argument, replacing 'BITRATE' in the command below. If you are developing your own network, you should know this value as you should have selected it. If you are attempting to sniff a production vehicle, your best bet is to start with 500000, which is representative of 500 kbps. If this doesn't work, try a google search to see if you can find the bitrate:
 +
'''root@beagle$ source setup.sh BITRATE'''
  
A preliminary board has been printed and will soon be tested. This section will be updated once the board has been evaluated
+
After the above steps complete successfully, the can1 interface should be up and running. You can confirm this by running:
 +
'''root@beagle$ ifconfig'''
 +
You should see an interface 'can1' and, if you have connected to a bus and have entered the correct bitrate, you should see an RX count above 0.
  
We only have hardware so far and have preliminary exploration on the software side. I will update this section once we get a more solid software foundation
+
There may be times where you may want to reconfigure the CAN network connection yourself. Before making any changes, be sure to first turn off the network connection via:
 +
'''root@beagle$ ifconfig can1 down'''
  
The CAN cape will be an excellent tool for anyone wishing to look at CAN communication traffic on a bus or attempting to explore CAN system development. It will be flexible enough to meet almost all CAN development needs with only minor adjustments required to the setup steps to achieve different functionality (active bus participant vs. spy, etc)
 
  
 +
== Hardware Instructions ==
 +
To use the board and schematic files included in this repository, you will need to install EAGLE by Cadsoft. The freeware version is enough to open and edit this board. Simply copy the CAN-Cape directory to your EAGLE project directory, or change your EAGLE project directory to this repo on your machine. You will also need to include a library in your project, which is found in the Eagle-Libraries directory. You can find an EAGLE download here:
  
== Packaging ==
+
https://cadsoft.io/
  
If you have hardware, consider [http://cpprojects.blogspot.com/2013/07/small-build-big-execuition.html Small Build, Big Execuition] for ideas on the final packaging.
+
The board can be printed by sending gerber files to a PCB fab company. I used the Sparkfun DRU and CAM processor in order to check the board and generate the gerber files. They can be found here:
  
== Installation Instructions ==
+
https://www.sparkfun.com/tutorials/115
  
Give step by step instructions on how to install your project.
+
A list of components can be found in PartsList.ods. Feel free to modify the hardware design to accomodate any components you would like to use.
  
* Include your [https://github.com/ github] path as a link like this to the read-only git site:  [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn].
 
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.
 
* Include a Makefile for you code.
 
* Include any additional packages installed via '''opkg'''.
 
* Include kernel mods.
 
* If there is extra hardware needed, include links to where it can be obtained.
 
  
 
== User Instructions ==
 
== User Instructions ==
 +
If you have a can1 interface up and running, you now have a couple of can-utils you can use to view the messages. The first is:
 +
'''root@beagle$ candump can1'''
 +
This will dump all of the received CAN messages to the terminal. However, this is very hard to read and is really only useful to determine if the bus is actually running.
  
Once everything is installed, how do you use the program?  Give details here, so if you have a long user manual, link to it here.
+
If you want a more organized view, then cansniffer is your best bet. Run:
 +
'''root@beagle$ cansniffer can1 -c'''
 +
The cansniffer utility will display the messages received in the terminal as well, but it isn't a scrolling list. When a message is received, and a previous message with that ID has already been received, the new data overwrites the old data. Further, the -c flag causes any differences in the data received from one message to the next to be highlighted in red.
  
 
== Highlights ==
 
== Highlights ==
  
Here is where you brag about what your project can do.
+
Click [https://youtu.be/FzIJ83zwgUM here] for a demo of the CAN cape being used to sniff a vehicle CAN bus.
 +
 
 +
== Theory of Operation ==
 +
The provided scripts simply install the can-utils package and then use config-pin to enable the dcan1 port through the pin muxes. The hardware contains adjustment jumpers to be adaptable to the user's specific needs. The specific GPIO used by the cape are: P9_24, P9_26, and P8_13. The cape also uses 3.3V and 5V. Below is a picture that shows the functionality of the jumper positions:
 +
[[File:CANCapePicture.jpg|frameless|center|Figure 1: CAN Cape with labels of major components]]
  
Include a [http://www.youtube.com/ YouTube] demo.
+
The clamp connector on the bottom left of the cape allows for the connection of hook-up wires directly in to the board with no need for a connector. This is valuable when breadboarding a CAN bus prototype as using wires is extremely convenient. The 9-pin SIP on the bottom right of the cape allows for the attachment of a DB9 Breakout board from SparkFun which allows for the use of a DB9 to OBD-II cable. This is the interface all modern vehicles use, and thus a vehicle can be accessed with this cape.
  
== Theory of Operation ==
+
The set of three 3-pin jumpers are selectable settings for the CAN transceiver, which allows for the cape to become a transceiver evaluation device.
 +
 
 +
On the top jumper nearest the Ethernet port, the left position selects 3.3V Vcc for the transceiver and the right position selects 5V.
 +
 
 +
The next jumper down selects whether to connect the 120 ohm terminating resistor across CANH and CANL. All production vehicles will have the appropriate terminating resistors installed, so this should be selected off when accessing a vehicle bus. When developing a bus however, you might not have two nodes yet, so you would use this terminating resistor in place of adding a second one to your breadboard or trying to solder one into the lines.
  
Give a high level overview of the structure of your software. Are you using GStreamer?  Show a diagram of the pipeline.  Are you running multiple tasks?  Show what they do and how they interact.
+
The lowest jumper selects whether to attach the vehicle or bus signal ground to the ground of the cape. This is not necessary for proper operation of the cape, but has been included to ensure that if anyone wants to do testing involving the grounds being attached then they would be able to do so.
  
 
== Work Breakdown ==
 
== Work Breakdown ==
  
List the major tasks in your project and who did what.
+
Create PCB Footprints: Sabeeh and David
 +
 
 +
Create Schematic: David
 +
 
 +
Create PCB Layout: David
 +
 
 +
Explore Device Tree Overlays: Sabeeh
  
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.
+
Create Setup Script: Sabeeh
 +
 
 +
Verify First Revision PCB: Sabeeh and David
 +
 
 +
Verify Second Revision PCB: Sabeeh and David
 +
 
 +
Verify Overall Functionality: Sabeeh and David
  
 
== Future Work ==
 
== Future Work ==
  
Suggest addition things that could be done with this project.
+
The first next step is to interpret the data off of the CAN bus. This is very difficult to do as one would have to understand the id as well as the bytes of data being sent. However, a decryption program of the CAN bus allows one to have a much better understanding of the CAN bus as well as the car itself.
 +
 
 +
Next is to turn the cape and Beaglebone into a device that can attach to the car's OBD-II port without a cable. So we could 3D print a case for the Beaglebone and cape that could just hang off the car's OBD-II port. There is a 12V line on the port that could be regulated to power the device. The idea is to setup systemd scripts so that we can log the CAN data into a file. It would then be possible to review this data at a later point in time.
  
 
== Conclusions ==
 
== Conclusions ==
  
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.
+
The idea behind this project was to explore a communication protocol that is used by modern day cars. We achieved that by developing a cape for the Beaglebone Black. We expected this project to also be heavy on the software side. However, we found a package (linux can-utils) that properly displays the CAN bus data into the terminal. We also believe that the cape is a very optimal solution as it can accommodate different transceivers, an OBD-II port or just the CANH and CANL wires, and the ability to switch between 3V3 and 5V logic.
  
 
{{YoderFoot}}
 
{{YoderFoot}}

Latest revision as of 07:39, 26 October 2017

thumb‎ Embedded Linux Class by Mark A. Yoder


Team members: David Mehl and Sabeeh Khan

Grading Template

I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!

10 Executive Summary
10 Installation Instructions 
10 User Instructions
10 Highlights
10 Theory of Operation
10 Work Breakdown
10 Future Work
10 Conclusions
10 Demo
10 Not Late
Comments: Very nice project.  Well presented both in demo and in wiki.

Score:  100/100

WARNING

Accessing your vehicle's CAN bus can be a dangerous endeavor. Reading the bus is typically not a problem, however sending messages can disrupt the operation of the vehicle, cause trouble codes, and potentially lead to undesired operation of the vehicle, up to and including moving under its own discretion. Needless to say, this can FATALLY INJURE YOU, so be careful. We are not responsible for any outcomes that the use of the provided hardware design or software may cause. There is no warranty.

Executive Summary

Our project combines a cape circuit board design with the necessary software to configure the Beaglebone Black in order to view the messages on a CAN bus using the can-utils package. The use of jumpers allows for the cape to be adaptable to different situations (such as CAN development, sniffing a vehicle bus, evaluating CAN transceivers, etc) by allowing the user to select whether or not to use a terminating resistor, 3.3V or 5V for the transceiver chip Vcc, and if they would like an OBD-II signal ground to be connected to the ground of the board.

The second revision of the circuit board has been tested and is fully functioning as expected, and the configuration script is setting up the pins properly. We were able to read the CAN messages off of a homemade CAN bus built out of two dsPIC33EV256GM102 microcontrollers, and we were able to read the CAN messages off of a 2012 Mazda CX-5. We have used a couple different CAN transceivers and achieved success with both.

This CAN cape will be an excellent tool for anyone wishing to look at CAN communication traffic on a bus or attempting to explore CAN system development. It will be flexible enough to meet almost all CAN development needs with only minor adjustments required to the setup steps to achieve different functionality (active bus participant vs. spy, setting bitrate, etc).

Packaging

This project includes a printed circuit board. The project files can be found in the Github repository. The schematic symbols and part footprints are also found in the repo. See the below Installation Instructions and Hardware Instructions for information on how to use the included files. Further, see Theory of Operation for the functional description of the physical cape PCB

Installation Instructions

The installation of this project is relatively simple. First, begin by cloning the github repository:

root@beagle$ git clone https://github.com/SabeehKhan18/Beaglebone-CAN-Cape.git

Be sure you have disabled the HDMI in /boot/uEnv.txt by uncommenting:

dtb=am335x-boneblack-emmc-overlay.dtb

If you had not previously done the above, you will need to reboot after uncommenting the line.

Next, run the installation script included in the repo. The installation script installs the linux package 'can-utils' on the beaglebone. This package has the software necessary to make sense of the messages on the bus and provides a display interface:

root@beagle$ cd Beaglebone-CAN-cape/
root@beagle$ ./install.sh

Then, be sure you are operating as root, and then source the setup script. This will configure the pin muxes for dcan1, which operates on P9_24 and P9_26. It also uses P8_13 to control the CAN transceiver STANDBY pin. Then it sets up the interface can1. You must provide the bitrate of the CAN bus as an argument, replacing 'BITRATE' in the command below. If you are developing your own network, you should know this value as you should have selected it. If you are attempting to sniff a production vehicle, your best bet is to start with 500000, which is representative of 500 kbps. If this doesn't work, try a google search to see if you can find the bitrate:

root@beagle$ source setup.sh BITRATE

After the above steps complete successfully, the can1 interface should be up and running. You can confirm this by running:

root@beagle$ ifconfig

You should see an interface 'can1' and, if you have connected to a bus and have entered the correct bitrate, you should see an RX count above 0.

There may be times where you may want to reconfigure the CAN network connection yourself. Before making any changes, be sure to first turn off the network connection via:

root@beagle$ ifconfig can1 down


Hardware Instructions

To use the board and schematic files included in this repository, you will need to install EAGLE by Cadsoft. The freeware version is enough to open and edit this board. Simply copy the CAN-Cape directory to your EAGLE project directory, or change your EAGLE project directory to this repo on your machine. You will also need to include a library in your project, which is found in the Eagle-Libraries directory. You can find an EAGLE download here:

https://cadsoft.io/

The board can be printed by sending gerber files to a PCB fab company. I used the Sparkfun DRU and CAM processor in order to check the board and generate the gerber files. They can be found here:

https://www.sparkfun.com/tutorials/115

A list of components can be found in PartsList.ods. Feel free to modify the hardware design to accomodate any components you would like to use.


User Instructions

If you have a can1 interface up and running, you now have a couple of can-utils you can use to view the messages. The first is:

root@beagle$ candump can1

This will dump all of the received CAN messages to the terminal. However, this is very hard to read and is really only useful to determine if the bus is actually running.

If you want a more organized view, then cansniffer is your best bet. Run:

root@beagle$ cansniffer can1 -c

The cansniffer utility will display the messages received in the terminal as well, but it isn't a scrolling list. When a message is received, and a previous message with that ID has already been received, the new data overwrites the old data. Further, the -c flag causes any differences in the data received from one message to the next to be highlighted in red.

Highlights

Click here for a demo of the CAN cape being used to sniff a vehicle CAN bus.

Theory of Operation

The provided scripts simply install the can-utils package and then use config-pin to enable the dcan1 port through the pin muxes. The hardware contains adjustment jumpers to be adaptable to the user's specific needs. The specific GPIO used by the cape are: P9_24, P9_26, and P8_13. The cape also uses 3.3V and 5V. Below is a picture that shows the functionality of the jumper positions:

Figure 1: CAN Cape with labels of major components

The clamp connector on the bottom left of the cape allows for the connection of hook-up wires directly in to the board with no need for a connector. This is valuable when breadboarding a CAN bus prototype as using wires is extremely convenient. The 9-pin SIP on the bottom right of the cape allows for the attachment of a DB9 Breakout board from SparkFun which allows for the use of a DB9 to OBD-II cable. This is the interface all modern vehicles use, and thus a vehicle can be accessed with this cape.

The set of three 3-pin jumpers are selectable settings for the CAN transceiver, which allows for the cape to become a transceiver evaluation device.

On the top jumper nearest the Ethernet port, the left position selects 3.3V Vcc for the transceiver and the right position selects 5V.

The next jumper down selects whether to connect the 120 ohm terminating resistor across CANH and CANL. All production vehicles will have the appropriate terminating resistors installed, so this should be selected off when accessing a vehicle bus. When developing a bus however, you might not have two nodes yet, so you would use this terminating resistor in place of adding a second one to your breadboard or trying to solder one into the lines.

The lowest jumper selects whether to attach the vehicle or bus signal ground to the ground of the cape. This is not necessary for proper operation of the cape, but has been included to ensure that if anyone wants to do testing involving the grounds being attached then they would be able to do so.

Work Breakdown

Create PCB Footprints: Sabeeh and David

Create Schematic: David

Create PCB Layout: David

Explore Device Tree Overlays: Sabeeh

Create Setup Script: Sabeeh

Verify First Revision PCB: Sabeeh and David

Verify Second Revision PCB: Sabeeh and David

Verify Overall Functionality: Sabeeh and David

Future Work

The first next step is to interpret the data off of the CAN bus. This is very difficult to do as one would have to understand the id as well as the bytes of data being sent. However, a decryption program of the CAN bus allows one to have a much better understanding of the CAN bus as well as the car itself.

Next is to turn the cape and Beaglebone into a device that can attach to the car's OBD-II port without a cable. So we could 3D print a case for the Beaglebone and cape that could just hang off the car's OBD-II port. There is a 12V line on the port that could be regulated to power the device. The idea is to setup systemd scripts so that we can log the CAN data into a file. It would then be possible to review this data at a later point in time.

Conclusions

The idea behind this project was to explore a communication protocol that is used by modern day cars. We achieved that by developing a cape for the Beaglebone Black. We expected this project to also be heavy on the software side. However, we found a package (linux can-utils) that properly displays the CAN bus data into the terminal. We also believe that the cape is a very optimal solution as it can accommodate different transceivers, an OBD-II port or just the CANH and CANL wires, and the ability to switch between 3V3 and 5V logic.




thumb‎ Embedded Linux Class by Mark A. Yoder