I want to make a CAN bus sniffer for 250 kbit/s using my computer. After some research I've found that MCP2551 is some kind of voltage level regulator for CAN's physical layer. Keeping that in mind, I'm wondering if this setup could work. I just want to record the exchanged messages for automated test purposes, not be a part of communication:

PC <-> USB-UART (perhaps CP2102, bacause I already have one) <-> MCP2551 <-> CAN bus

If not, what kind of signals have to enter MCP2551 in order to make me be a part of the bus?


You can do that, but what you'll get on your CAN bus will be UART using CAN voltage levels. You have to supply the MCP2551 with CAN protocol messages if you want to communicate with CAN devices on your bus. Same for listening: CAN messages are so different from the UART format that the UART won't know what to do with them. You'll have at least frame errors all the time, and you won't get at the message's content.
This image shows the structure of a CAN message:

enter image description here

There's plenty microcontrollers around that have a CAN interface, sans the transceiver. It's for these that the MCP2551 was designed. In the past we've used the NXP LPC2294, which has 4 CAN interfaces. Each of them needs an MCP2551 to connect to a CAN bus. More recent controllers from NXP include the LPC1800 family, of which all members support CAN.

  • \$\begingroup\$ I totally forgot about UART start/stop bits and probably some CAN "start/top bits" situations. I'll probably try to find a solution using a CAN stack on the PC using FTDI as a gpio that will end up transmitting to MCP2551 \$\endgroup\$ – rnunes May 19 '12 at 17:05
  • 3
    \$\begingroup\$ @rnunes - It's not just the start/stop bits. Without those a UART transmission is just an 8-bit byte. A CAN message is much more complex, with addressing, priority and error checking. You can't compare the two. \$\endgroup\$ – stevenvh May 19 '12 at 17:10
  • \$\begingroup\$ But using the FTDI i'll be working bit by bit (basically, it's a really fast USB <-> GPIO), not byte by byte as with UART. I'm already looking for those CAN MCU, but I would prefer to spend any money for now (it's a student hobby project) and I already have the FTDI. If I conclude with my researches that the FTDI won't be able to do this I'll try using a CAN MCU. \$\endgroup\$ – rnunes May 19 '12 at 17:19
  • \$\begingroup\$ The stack will be responsible for handling everything (e.g bit stuffing) and transmit it bit by bit to MCP2551. The only problem that I'm having right now it's the FTDI latency, because I need it to be fast and regular, but I'll measure it later. \$\endgroup\$ – rnunes May 19 '12 at 17:22
  • 1
    \$\begingroup\$ @rnunes - But what comes out of the CP2102 (SiLabs, not FTDI) are bytes, not bits. You can't stop it after one bit. You'll need both the CP2102 to interface your microcontroller with USB, and a microcontroller which supports CAN + the MCP2551. Or a microcontroller which also can act as a USB device. Then you don't need the CP2102. \$\endgroup\$ – stevenvh May 19 '12 at 17:25

I have made a USB/CAN interface using FT2232H in MPSSE mode (forget UART), MCP2515 and MCP2551. MCP2515 is the key piece you're missing here. Study well what it does. It's the actual CAN controller that does framing, ACKs, checksum generation and verification, message filtering and other less obvious things that a CAN node is required to do by the standard. If you want a sniffer, MCP2515 has a listen only mode which guarantees no transmissions on the bus. MCP2551 is simply a dumb physical layer adapter, similar to a MAX232 for RS-232 or ADM485 for RS-485.

Now this architecture is far from perfect as FTDI MPSSE technology has essentially no support for interrupts (I believe it only uses bulk USB transfers behind the scenes), so I have to poll the controller frequently for new messages. This places a lot of load on the USB host controller but still doesn't guarantee that no messages are lost (MCP2515 can store up to 2 received messages internally if you enable "overflow mode", only one if you don't). A far better solution would be a proper microcontroller with builtin CAN and USB peripherals such as STM32F105 (103 can't use USB and CAN at the same time). See this project for a working implementation of exactly this idea. LPC18xx as suggested by stevenh will work too, but LPC17xx are probably cheaper and easier to find.

  • \$\begingroup\$ In this case, pooling it's not a problem but yes, the ideal solution would be using a MCU with CAN controller that works as a CAN message buffer. From now I'll try using the first setup that you wrote. Thanks \$\endgroup\$ – rnunes May 19 '12 at 18:13
  • \$\begingroup\$ +1 Using the FTDI chip to talk directly to a CAN controller without a uC is neat. Aparently FTDI came out FT221X, which is a dedicated USB to SPI bridge. (There is a different model for USB to I2C too.) \$\endgroup\$ – Nick Alexeev May 20 '12 at 4:23

Since you want to listen in on a existing CAN bus as I understand the question, you really can't use a UART at all. CAN and UART siganlling are totally different.

You could in theory look at the CAN receive line coming out of the MCP2551 and decode the CAN traffic. That won't be easy, but it is theoretically possible. Without specialized CAN hardware, you'll have to sample a few times faster than the CAN bit rate and decode that bit stream in software later. You'll probably need to record at about 1 Mbit/s to decode 250 kbit/s CAN.

Using a microcontroller will be far easier. The PIC 18F2580 and other similar processors have a CAN peripheral built in. The hardware does all the bit level decoding and receives whole CAN frames. The processor can then send on received CAN frames via its UART to your PC.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.