Microchip CAN Bus Analyser Tool - Review

Table of contents

RoadTest: Microchip CAN Bus Analyser Tool

Author: collink

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: There are many products in this space at comparable price point - Macchina M2, EVTVDue, CANTact, etc. There are many, many open source CAN bus capture devices. This Microchip device is one of the more developed and nice looking products.

What were the biggest problems encountered?: It doesn't come with an OBDII adapter that attaches to the DB9 port. I had one but the internal wiring pinout was wrong. I had to resolder my adapter to compensate. This wasn't too terrible as Microchip has very good documentation for pinouts and schematics. So, I could easily find the info I needed to correct the issue. Other than that, I was also unimpressed that the rows of 0.100" pins on the top of the unit have no sticker or any other indication for which pins do which functions. Once again, this is in the documentation but you have to look it up and that slowed me down a bit.

Detailed Review:

Microchip has an interesting product with their CAN Bus Analyzer. It is a nice looking product and it works quite well. The nicest thing about it is that it is one of very few commercial products where the full source code for the firmware is open as are the schematics for the board itself. This is a very welcome addition to the CAN bus analysis realm. Yes, there are many other open source CAN dongles. But, few of them have the sort of commercial backing and advertising as this product.


In my opinion, the firmware included with the device is somewhat sub-optimal. It isn't terribly well tuned and can have some trouble with higher bus loads. However, open source comes to the rescue here. There exists a modified firmware that fixes bugs in the stock firmware: https://github.com/rkollataj/mcba_firmware


I use LINUX for software development and reverse engineering so I didn't use the Microchip CAN software for Windows very much. However, it seems extremely basic and under powered. I wasn't terribly impressed with this software in the least. However, I'm very happy to see that this software is also open source. As such, others could make it better.


On LINUX there is a socketCAN driver for this device: https://github.com/rkollataj/mcba_usb    The maintainer of that code has submitted it to the LINUX kernel maintainers and it is bundled with LINUX kernel 4.12 or higher. This is excellent news for anyone who would like to use this product! I have tested the socketCAN support and it works quite well. This allows the device to work with basically any CAN software on LINUX. This is very powerful! I issued the following commands to set up the device in LINUX:

sudo modprobe mcba_usb

sudo ip link set can0 type can bitrate 500000

sudo ifconfig can0 up


This is actually pretty easy. I put those commands in a script and run it when I attach the device. Thereafter, it works with any socketCAN compatible program of which there are MANY. Linux has default apps to do a variety of CAN capturing - candump will list all frames on the bus, cangen can be used to generate traffic onto the bus, etc.


Overall I find that the hardware is sufficient for the task and presented quite well. My chief complaint would be that it feels a bit like Microchip dumped it on the market half done and expected the open source community to fill in the gaps. To an extent, that gamble did pay off and the open source community did come through. Unfortunately, that basically boils down to one rock star developer who did what Microchip failed to do. Without Remigiusz Kollataj the device wouldn't be nearly as useful or powerful.


Overall the hardware was quite nice. My only real complaint with the hardware was that the 0.100" pitch pins on the top that connect to CAN and triggers has no reference on the device itself. This seems an odd oversight as there is plenty of labeling on the device. I've attached a picture showing the CAN connections. This should have been put on a sticker like all the other labeling on the device.



I used this product in LINUX to do analysis of OBDII CAN bus communications in my 2008 Buick Enclave. I primarily used my own program called SavvyCAN to do this analysis. The socketCAN support for Microchip's device allows me to use my program with the device. Here is a view of Buick traffic that was captured by the Microchip device:



The first thing I tried was to scan the Buick for UDS (unified diagnostics service) compatible CAN nodes. UDS is essentially a superset of the OBDII diagnostics standard. OBDII is found on all vehicles 1996 or newer in the US. CAN based OBDII was mandated in 2008 and found in some vehicles before then. UDS is used to do more in-depth diagnostics and to be able to configure and re-flash the ECUs (engine control units) in a vehicle after it leaves the factory. As such, it can be handy to find UDS compliant ECUs to see what you can do with them.



I found that the Buick has two UDS compliant ECUs, one that responds on 0x7E0 and one that responds on 0x7E2. UDS supports a variety of standard message types. One is called "Tester Present" and is used just to tell the ECU that we're still there. Some ECUs require you to send this message type every so often. Apparently Buick is not one of them as it responds with a "not supported" message. Another common message type is "diagnostic session control" this is used to go into different session types. You can't do all operations in all session types so some commands require certain session types. This isn't entirely standard but it's nice to see that the Buick did respond that it supported session type 2 which is "Programming session." Quite often, a programming session (where you can update the car's firmware) would also require a security check. This is the "SECURITY_ACCESS" message seen above. The Buick returned a security key of 0x19BC which is 16 bits. This is more manageable to crack than longer keys. It also doesn't appear that the Buick bothers to try making random keys each time.



After scanning UDS a bit I tried my hand at figuring out some other messages in the car. I thought it might be easiest to try finding where it sends RPM on the CAN bus. My program has a special screen to search for signals that look interesting. Below is a shot where I found the RPM signal by scrolling through candidates until I found something that looks like what I did with RPM. I pushed the pedal down three times after starting the car and you can see that in the data.



Above I graphed the signal after scaling it to 1/4. This causes the data to exactly match what I saw for RPMs on the dash as I was pushing the pedal down to change RPMs - it idled around 1000 RPM and I revved it up to 3000 or so twice then held it around 2000 the third time. This confirms that I found the RPM signal.


Summary - All around I think the Microchip capture device is worth the price and a useful and powerful tool. I had a couple of issues with it but nothing that couldn't be easily overcome.