1 / 28

By: David Cohen & Gadi Gilad Instructor: Boaz Mizrahi

Project Final Presentation. CAN Bus Logger Part B. By: David Cohen & Gadi Gilad Instructor: Boaz Mizrahi. Spring 2012. Introduction. CAN - Controller Area Network.

joan-schneider
Download Presentation

By: David Cohen & Gadi Gilad Instructor: Boaz Mizrahi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project Final Presentation CAN Bus Logger Part B By: David Cohen & Gadi Gilad Instructor: Boaz Mizrahi Spring 2012

  2. Introduction 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.

  3. 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.

  4. Differences between the projects The significant differences between the previous project and the current one

  5. Differences between the projects The significant differences between the previous project and the current one

  6. Main Goals • 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

  7. The hardware • These devices have been in use for the communication • A computer’s terminal • From the terminal we send commands via a USB connection to the demo board (or via Bluetooth, in the new MW-board)

  8. 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

  9. 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

  10. 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

  11. 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

  12. The configuration process • Performing internal Loopback

  13. The configuration process • Performing “external” Loopback

  14. The configuration process • Connecting to the car

  15. Stages in getting the vehicle status • Using the keyboard to write AT commands (e.g. “at 010d”), and sending it to the device via USB/BT

  16. Stages in getting the vehicle status • Going to the OBD-query section in the program memory of the device

  17. Stages in getting the vehicle status • The CAN query (e.g. “7DF 02 01 0D”) is transmitted to the vehicle from the TX buffer on the board

  18. Stages in getting the vehicle status • The packet is sent from the CANH-CANL pins to the OBDII connector of the vehicle

  19. Stages in getting the vehicle status • 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”)

  20. Stages in getting the vehicle status • The response packet is entered the RX buffer in the device and an interrupt is generate

  21. Stages in getting the vehicle status • The data received and kept in the flash memory, then sent back to the screen.

  22. Working on the project • Some 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.

  23. Working on the project • Some of the problems we had during our work, and their solutions 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.

  24. Working on the project • Some of the problems we had during our work, and their solutions 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.

  25. Working on the project • Some of the problems we had during our work, and their solutions 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.

  26. Working on the project • Some of the problems we had during our work, and their solutions 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.

  27. Capabilities • 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)

  28. Notes…

More Related