Introduction

For many years, debugging serial communications issues in embedded systems generally boiled down to debugging the vagaries of the RS-232 protocol. Surprisingly, this is still true today because RS-232C is the most basic and fundamental of the serial communications protocols and is generally rather bulletproof. Debugging typically involved getting the baud rates to properly match or messing around with transmitted data out and transmitted data in on pins 2 and 3 of the connector. Debugging the serial communications link was the first piece of I/O that the engineer needed to get working properly because communications with the target system depended upon this link working properly.

Today, serial communications protocols have greatly evolved and are being used both for peripheral communications as well as communications between elements of networks. These systems are high-speed and complex. They require highly specialized measurement tools to analyze and correct errors in the data streams. Any discussion we might have about debugging these systems would quickly focus on what company’s analyzer one should purchase.

Therefore, let’s narrow our scope to the types of communications systems that we would most likely have to deal with in designing real-time control systems without the necessity of resorting to specialized tools. Furthermore, we can also eliminate USB and Ethernet protocols from our discussion. You might argue that these protocols are pretty fundamental. In fact, I have a laser printer in my office that came with USB and Ethernet already installed. Shouldn’t we discuss these as well?

Fair point. However, we would typically have a standard IC of some flavor that would handle the translation of the physical layer communications protocol to something that the rest of the system can then deal with. This physical layer IC circuitry is pretty standard and if you follow the design rules and circuit examples in the applications notes, your circuitry has a high probability of working correctly. However, once it leaves the translator circuit, we have to deal with it as another element of our overall system and the discussions of the previous chapters then come into play.

Here’s a simple example. The early versions of the Arduino single-board computers contained a USB to UART converter IC, manufactured by Future Technology Device International (FTDI). The Atmel microcontrollers that were the core of the Arduino family of boards all had UART interfaces that could just as easily connect the chip to an RS-232 bus. The FTDI chip converts the USB protocol to UART.

Later versions of the chip, such as the ATMEGA16U2-MU, updated the communications port to directly interface to USB 2.0, eliminating the need for the FTDI interface chip. All that is now required are two 220 Ω series resistors between the USB socket and the microcontroller.

So, what serial protocols should we discuss? Based upon my experiences with my student’s issues with designing their microprocessor-based designs, almost all the peripheral devices they connect to their controller are either an SPI or I²C interface. Therefore, just based upon the level of pain, let’s discuss these protocols.

Because RS-232 is still around and still being used for many systems, we’ll cover the basics of that protocol and the issues around getting it to work.

Lastly, and mostly because it enjoys widespread acceptance in many industries as a communications protocol, we’ll consider the CAN bus. The CAN bus originally evolved as a communications standard for automotive systems, but over the years has achieved much wider acceptance in other industries as well.

Finally, the other reason that I think these four protocols make sense to discuss in a debug context is that it is possible for mere mortals to find and fix bugs using only a standard oscilloscope or logic analyzer.

RS-232

Perhaps you are familiar with the RS-232C designator. This was the version EIA^a RS-232 standard that was in force just in the golden age of the desktop PC. The biggest change that RS-232C brought was the reduction of the logic levels from ± 25 V down to a more manageable ± 5 V. This made it easily compatible with PCs because + 5 and + 12 V were the primary power supply voltages in the original PCs, along with − 5 and − 12 V, though at lower current levels. Later versions of the power supply standard dropped the − 5 and − 12 V voltages and added + 3.3 V.

Without the − 5 V voltage available, IC manufacturers stepped in and created interface circuits that contained their own built-in DC-DC converters. The circuit contained an internal oscillator that, when combined with external capacitors, converted + 5 VDC to − 5 VDC. A good example of this is the MAX232X Dual EIA-232 Driver/Receiver family from Texas Instruments.

If you were around computers and embedded systems before the introduction of USB, then you are familiar with RS-232. This is the classic COM port of the PC age. If you were around for the early days of the PC, such as the PC-XT and the PC-AT, then you remember grappling with the jumpers on the I/O boards in order to set the correct communications protocols. There were four basic sources of potential errors:

• • Wrong COM port assignment.
• • Improper cable pinout.
• • Wrong baud rate (clock frequency).
• • Improper flow control.

Wrong COM port assignment

If RS-232 is the communications protocol between your application running on your PC or workstation and your communications port on your target system, then the first order of business is to get the link working. This was crucial because this link had to be established for the host-resident debugger to be able to do its job.

So, you hook everything up, power up your target, and wait for a prompt to come back, telling you that the debug kernel in your target is talking to the debugger on the host. Nothing, nada. What’s the problem? Most likely, the wrong COM port is being used. Even today, the popular Arduino IDE requires the user to select the correct COM port.

The simplest way to solve this problem is to locate any one of the free terminal emulation programs that are around. Even if you find a commercial terminal emulator, you can generally get a free trial version. With the terminal emulator installed, unplug the RS-232 cable from the target and connect pins 2 and 3 together. Type a few characters and see if they are echoed back to the screen. If so, the COM port is correct.

Now connect it back to the target and try again. If it works, great. If not, we move on.

Improper cable pinout

If you want a quick trip down the rabbit hole, this is the place to do it. The reason is that the correct cable depends upon the vagaries of the engineer who designed the mating COM port on the target system. It turns out that there are three flavors of cable connections^b:

1. 1. Direct DTE (computer side) to DCE (computer modem side): Here, the cable wires go straight through. Pin 1 connects to Pin 1 and down the line to Pin 9 connected to Pin 9.
2. 2. Null-modem cable DCE to DCE (modem to modem).
3. 3. Null-modem cable DTE to DTE (computer to computer).

Depending upon how the target system connector is wired, or which cable you happened to grab from the assortment of cables laying around, it may or may not be the right cable type. To make matters worse, there is the sex of the connectors at either end of the cable to consider.

In the ideal case, the cable should have a female connector at one end and a male connector at the other. The female end plugs into your PC and the male end should plug into the female connector on your target system. If this is the case, then there is a reasonable probability that the connection is correct. But….

That doesn’t eliminate the possibility that you still have the wrong cable pinout configuration. The simplest solution is to first use an ohmmeter and determine the pinout and connectivity of the cable. If everything is connected properly as a straight-through cable, then find a null-modem adapter that does the pinout reversals that you need.

If none of these work, then it is time to bring out the oscilloscope, set it for single-shot mode, and, using the terminal program, trace the signal from the connector back to the I/O pins of your microcontroller or discrete I/O chip.^c You should observe the serial bit stream from the character you are sending going to the received data I/O pin of the IC.

The key is that you now need to verify the integrity and correct operation of the I/O data transmission path. Time to employ the investigative techniques we discussed in the earlier chapters.

Wrong baud rate (clock frequency)

The tell-tale sign that the baud rate is incorrect is that the transmission is garbled.

When you press the letter A on the keyboard, you see some other character or symbol being echoed. This is a pretty straightforward problem to solve, but it is also an interesting problem to discuss.

If you look into the particulars of RS-232, you will discover that it is asynchronous (no clock). That’s correct, there is no clock signal transmitted with the data. Today, the clock signals and data are encoded together and circuits at the receiving end recover the clock in order to synchronize the transmission.

With RS-232, the receiver and the transmitter each have their own clock. The clocks should be running at the same frequency, but they are not synchronized to each other. In other words, the phase relationship between the two clocks is entirely random. So, this issue becomes how to accurately transmit and receive the data if each system’s clock is not synchronized with the other? This is the clever solution.

First, without getting lost in the arcana of communications protocols, we can simply say that the baud rate (9600 baud, for example) is the bit rate for data transmission. If every data transmission contains 1 start bit, 8 data bits, and 1 stop bit, then transmitting something requires that we send 10 bits of data, or 9600 divided be 10 characters per second. Therefore, 9600 baud would translate to about 960 characters per second. At 9600 bits per second, we need to clock the data in every 104 μs, which requires a clock frequency of 9.6 kHz.

Here’s where it gets interesting. We still need to solve the problem of the unsynchronized clocks. This occurs at the receiving end. The 9.6 kHz data clock is actually divided down by a factor of 16 × from the master clock. When the receiver sees the negative edge of the start bit, it counts 8 cycles of the master clock and then begins to clock in the data every 16 clock cycles of the master clock.

By counting eight cycles, it starts to clock the data roughly in the middle of each bit being transmitted. The uncertainty in the phase relationships becomes negligible because the phase difference is in the master clock, not the data clock. As far as the data is concerned, the correct clock edge to bring in the data occurs more or less in the middle of the data bit.

This is also the reason why the maximum baud rates for RS-232 top out at around 56 K baud. As the data rate goes up, the phase uncertainty becomes more significant. Also, RS-232 cables are not impedance-controlled transmission lines and the longer the cable and the higher the data rate, the more distorted the transmitted data become. With lower margins of error, bit errors are more likely.

From my perspective as a teacher, the operation of a UART is a great exercise to give students learning about finite state machines and simple UARTs can be constructed in their FPGA lab experiments. Anyway, that’s how the baud rate system works and the necessity to synchronize the baud rates comes about because the transmitter and receiver clocks are not phase locked to each other.

Improper flow control

If everything else is working, the last possible data transmission error source is flow control. There are three possibilities here:

1. 1. No flow control.
2. 2. Hardware flow control.
3. 3. Software flow control.

If both systems are set up for no flow control, then it is assumed that the receiver is fast enough to accept as much data as the transmitter can send without worrying about any input buffers being overflowed. Once a transmission starts, no matter how much data is being sent, the receiver can deal with it.

I think you can see what might happen with this type of communications channel and an RTOS on the target system. If the priority level of the communications channel is too low, and there is no flow control in place, then data can be lost.

With hardware flow control, the two signals, clear to send (CTS) and request to send (RTS), provide the handshake mechanism between the receiver and transmitter. The transmitter asserts RTS in order to initiate a transmission and the receiver responds with a CTS handshake. This informs both devices that data can now be sent. If the receiver cannot keep up with the transmitter, it deasserts CTS and the transmission stops until both devices are ready again. For this to work, these pins must be activated in the cables, the connectors, and in the UART driver code.

It was fairly common to save space and simplify the connection by using a simple telephone jack for the connector. In this case, only ground, send, and receive were used. With this situation, flow control (if used at all) became a software issue. Two ASCII control codes were used for flow control, XON (hexadecimal 11) and XOFF (hexadecimal 13).

The data transmission handshake now depended upon sending and receiving these control characters to properly pace the data flow. Of course, the software drivers at both ends had to agree on the type of protocol being used for this system to work.

I2C and SMBus protocols

Peripheral chips, such as A/D and D/A converters, timers, and UARTs, used to all be parallel interfaces with the processor. You connected them to the address and data buses, used some sort of address decoder scheme to assign them a memory or I/O address, and that was it. Assuming your timing margins of your design met the specifications of the peripheral device, the device should work as advertised.

As microcontrollers became more integrated, external buses disappeared and a different method was needed to interface peripheral chips to the controller. Enter the onboard serial buses, I2C and SPI. Today, peripheral chips with parallel interfaces are becoming endangered species. Out of curiosity, I went to the Analog Devices website^d and looked at the product selector guide for one type of A/D converter. There were 338 total parts listed for single-channel A/D converters and less than one-fourth of them contained parallel interfaces. Most of those were combination parallel and SPI devices. Less than 20 were pure parallel interfaces.

I2C was developed by Philips and its key feature is its simplicity. It is interchangeably described as either I²C or I2C. The actual name is “interintegrated circuit” bus. Surprisingly, it is also the basis of the CAN bus that we’ll discuss later in this chapter.

The SMBus (system management bus) was developed by Intel and Duracell in the mid-1990s as a simple two-wire bus for use in smart batteries and on PC motherboards.^e It is hardware compatible with I2C with some differences [1, 2]. The major difference is that the SMBus is a low-speed bus, limited to a maximum clock frequency of 100 kHz. There are other differences having to do with logic voltage levels and time-outs, but for our purposes they may be considered to be compatible because I2C devices may be used in SMBus applications with the caveat that differences exist. However, because I2C dominates in the embedded realm, we’ll continue to focus our attention there.

As previously mentioned, the I2C bus is a two-wire bus, and because it is an open collector (open drain) topology, it requires pull-up resistors at the end of the run. However, with open-collector (or open-drain) outputs, multiple drivers and receivers can be attached to the same wires.

Because the outputs are not actively driven, the low-to-high transitions are controlled by the RC time constant comprised of the pull-up resistors and the total capacitance of the wires and I/O devices connected to those wires. Thus, I2C bus speeds are restricted to data rates below 3.4 Mbps (megabits per second).

I2C uses the concept of a master/slave relationship between the devices. All data transfers are initiated by the master and the master provides the clock signal, serial clock (SCL). Data transfers are bidirectional over the serial data line (SDA). Fig. 11.1 shows this schematically. Note that only one master device is shown but the standard allows for multiple masters as well as multiple slaves (as shown).

The most common source of error that I’ve observed with my students is the omission of the pull-up resistors. Without the pull-ups, we’re looking at one end of a transistor flapping in the breeze.

Fig. 11.2 shows the I2C data transfer protocol. As previously mentioned, a data transfer must be initiated by a master device by bringing SDA low while SCL is low. Data on SDA may change while SCL is low but must be stable while SCL is high.

As shown in Fig. 11.2, data is transmitted MSB first in 8-bit long data packets, although as many packets as necessary can be exchanged between devices. After each packet is sent, the receiving device will send an acknowledge signal back so that the next packet may then be transmitted.

Addresses are assigned for each device by the I2C bus committee. So, you might ask how you can put several identical slave devices on the bus without conflicts? Even though each device has a unique 7-bit preassigned address, it is possible to partition this address into a smaller fixed part and a programmable part that depends upon a nonvolatile memory entry or programmable pins on the device. Thus, the 7-bit address can consist of 4 fixed bits and the state of 3 I/O pins tied to ground or power (Vcc). Some devices with nonvolatile storage, either EEPROM or FLASH registers, can have their I/O address reassigned by the customer under program control.

One source of possible error is addressing slave devices. When sending out an address, the master sends out the 7-bit slave address, which is left-justified toward the MSB, and the eighth bit (LSB) indicates whether the master is going to write to the device (LSB = 0) or read from the device (LSB = 1). From the point of view of programming the address, the byte value containing the address must be shifted left one bit while making sure that the instruction pads the LSB with a zero bit. Next, a byte containing all zeros plus the read or write information in the LSB position is OR’ed. with the address to complete the addressing code. Thus, if the device address is 04H, and the master is writing to the slave, the byte value sent out would be 08H.

The I2C specification also allows for 10-bit addresses [3]. A special 7-bit address consisting of the sequence 1 1 1 1 0 X X alerts slave units with 10-bit addresses. The X X bits of the last part of the address are not “don’t care bits.” They are the first 2 bits of the 10-bit address. The next 8 bits of the following data packet complete the 10-bit address.

I was first introduced to the potential issues surrounding I2C addressing modes when one of my students was involved in a Capstone project with a company located in our area. I’m not going to mention the company nor the nature of the project, other to say that this Capstone team of four students was developing a new microcontroller board for the company. The company’s engineering mentor to our team gave us the board they wanted to modify and all the software, which, we were told, “worked fine.”

One of the students was working on communications with the peripheral devices, which used a I2C bus. Everything seemed to be working except he could not talk to one I/O device on the board. Everything he tried failed. In desperation, after a week or so, he asked for my help. The first thing I suggested is to put a scope on the SCL and SDA lines and look at the signals going out to the device.

We did that and everything looked fine as far as the software was concerned. The 7-bit address matched the “C” code. Next, we grabbed the data sheet for the part and started to read. Under the addressing section, we noted that this device had a 10-bit address. Either we had the wrong software, or it never worked in the first place. After fixing the code, it worked fine.

Reference [3] gives a really nice overview of the protocol and all the minutia that would cause our eyes to glaze over, but if you have a bug that you are trying to track down, this is a very readable document

From the point of view of debugging, I2C is a relatively easy protocol to debug. Because it has only two wires, it is easy to clip the probes from a two-channel oscilloscope onto the SDA and SCL lines and watch as the traffic goes by.^f If you happen to have a logic analyzer handy, many of them also support I2C bus protocol analysis through postprocessing of the data. The LogicPort logic analyzer (previously discussed) is one such device. Clip two LA channels onto your SDA and SCL lines, set the interface, and you have a I2C (or SPI) data analyzer.

There are also reasonably priced, dedicated I2C tools available from a number of companies. Of particular note is the BusPro-I bus analyzer, monitor, debugger, and programmer from Corelis.^g I’m mentioning Corelis here because I’m quite familiar with the company from my days working on development tools at Advanced Micro Devices (AMD) working with third-party vendors to provide design and debug tools for the Am29000 family of embedded microprocessors and microcontrollers.

Corelis worked closely with AMD to provide JTAG support for the on-chip debug capability and boundary scan. Finally, I have no financial relationship with the company and can’t comment on their products versus the competition. Simply, they’ve been around for a long time and make tools that do the job. From our perspective, the BusPro-I offers two very significant debugging capabilities:

1. 1. Monitoring, recording, message filtering, symbolic translation, and conformance to protocol.
2. 2. Interactive debugging with the ability to drive data to the I2C bus to provide stimulation and response to devices on the bus.

Fig. 11.3 is a screenshot of the BusPro-I monitor window. Another attractive and useful feature of this tool is the flexibility of the user interface. The software is also available as a C/C ++ library of functions that may be integrated with other debugging tools.

The BusPro-I is more costly than the other I2C tools that are available, but it is a professional-grade tool from a company that’s been in business for quite a while. If you are looking for a tool, I might suggest that you use this tool as your reference and measure the others against it.

On the other hand, it is a specialized tool, capable of debugging significant problems in I2C systems. Is it worth the incremental cost of using an oscilloscope or a logic analyzer? You’ll have to judge that for yourself. A for-profit company understands the time value of money. Saving several hours of debugging by having the right tool for the job could easily justify the cost of the tool. For the student, a lab scope or logic analyzer works just fine and is free.

SPI protocol

The serial peripheral interface (SPI) was invented by Motorola in the mid-1980s and along with I2C, it has become a de facto standard for short-range, high-speed, interdevice communications. However, it has not been codified by any standards organization or industry-based standards group. If you read some of the embedded systems forums where embedded engineers share their opinions, SPI is an easier interface to code and debug.

Unlike I2C, SPI is a point-to-point protocol. There is no bus in the same sense as I2C, but SPI devices can be configured in much the same way that we build memory systems. That is, each slave device has its own active-low, chip select input. The master device must uniquely activate the slave it wants to communicate with. On first glance, this might apparently complicate the hardware, but given that microcontrollers typically have a rich set of parallel I/O bits to use, this is less of an issue. The advantage is that it is not necessary to deal with transmitting address information to the peripheral devices.

The SPI interface is full duplex, meaning that the slave is sending data to the master at the same time that the master is sending data to the slave. The implementation is rather clever. The data path is a loop from the master along the MOSI (master out, slave in) line into the slave and the return line is the MISO (master in, slave out) line. The master and slave each contain a shift register that clocks the data out and in at the same time.

Sending data out to a slave involves setting the correct chip select bit low and clocking the data until the desired number of data bits has been sent. Thus, there is no restriction that all data packets are byte-wise, as is required by I2C. Also, there is no need for the slave to send an acknowledge signal at the end of the data transfer.

As defined, the SPI interface is a three-wire or four-wire “almost” synchronous point-to-point system. The interface is not fully synchronous because the chip select signal may be asserted at any time, rather than synchronized with the clock. The normal arrangement is four-wire full-duplex, but in certain situations, such as a D/A converter, only MOSI mode is appropriate, so three wires are all that is necessary. Because the master and slaves (no multiple masters are allowed) are typically resident on the same PC board, there is no need to have a power or ground signal between them. When used in three-wire mode (half-duplex), the protocol becomes more like I2C because only one device can be sending at a time.

The clock is controlled by the master and both phases are used. There are four modes of setting up the clock phase and data transmission relationship, not surprisingly named Mode 1 through Mode 4. The most appropriate operational mode for a given situation is left as an exercise for the designer, but according to the Analog Devices application note [4], the master should be able to support all four modes, although this is not a requirement for the slave devices.

Two phases of the clock are necessary because the same clock is being used to transmit and receive the data. Thus, if the data are sent on the rising edge of the clock, they can’t be read on the same rising edge. Therefore, if we send the data on the rising edge, we read them on the falling edge, giving the receiver sufficient time for the data to be stable before clocking it into the receiver’s shift register. If multiple slaves each are designed to use a different mode, the master will have to reconfigure its configuration register to make it compatible with the slave.

One of the most common areas for trouble centers around the four modes of clocking and data transmission. According to Williams [5], potential problems with phase and polarity are the first places to look if you need to troubleshoot your SPI protocol. Here’s how Williams explains it,

Williams goes on to discuss each potential problem area. Rather than do a paste and copy of his original article, I’ll just touch on the high points. Other potential areas for problems can be summarized below:

• • Speed: Because the master sets the clock speed for both devices, a simple approach is to slow down the clock. If the slave device can’t keep up with the master, then problems may arise. The master may have a hefty MOSI driver on the output while the slave does not. A two-channel scope with a separate trigger input from the clock can give you some insight into the error margins of the circuit. If the master clock is 10 MHz, slow it down to 1 MHz, or as Williams suggests, 100 kHz.
  Once you have it running reliably, gradually raise the clock frequency until you begin to see errors. However, keep in mind that the problem may not be simply clock speed, but rather issues related to the set-up and hold times [4] due to the mode you’re using.
• • Insufficient clocks: If you are expecting to read a slave and the data never come, it may be due to the fact that the master has stopped issuing clock pulses. Recall that the master must continue to supply clock pulses until the slave has finished sending all the data, and data packets are variable length. Therefore, if this is your issue, start looking at your driver code and make sure there is a clear handshake as to how much data will be transferred, or if you have a termination string at the end of the packet.
• • Bus problems: When a system goes beyond one master and one slave, then problems traceable to bus contention issues can crop up. This can be as simple as neglecting to make sure that only one chip select output from the master is low at a given time.
• • Open collectors: Some slave devices use open collector outputs to drive the MISO line. They may have a weak pull-up resistor or none at all. Unless you catch this in the data sheet, you may have neglected to add a pull-up resistor to the MISO line. Williams suggests that a good way to test for MISO problems is to bias the line at the midpoint of the logic swing using two large resistors, 100 kΩ, for example. Set the resistors as a voltage divider between power and ground with the MISO line biased at the midpoint. With all chips turned off (Chip Select = 1), see if the line is pulled up to Vcc or pulled down to ground. If either one of these situations is true, one of the slaves is not turning off.
  Next, run the system and observe the bus. If you see what looks like valid data, but the logic swing is from the midpoint to ground instead of power to ground, you have an open collector issue.
• • Best practice: During initialization of the microcontroller, the SPI devices can be subject to various inputs, floating chip select lines, and random noise. Placing weak pull-up resistors on the chip select lines guarantees the slave units will remain in the off state until the microcontroller is fully awake and in control.

Tools

Fortunately, SPI is such a popular protocol that there is a wealth of information available on how to debug SPI devices and the tools available to effectively troubleshoot any problems. Corelis offers the BusPro-S, which is a full-featured SPI host, debugger, and programmer with capabilities similar to those of their previously mentioned I2C unit. In a sales-biased application note,^h Keysight [6] discusses troubleshooting today’s most common serial buses; I2C, SPI, USB, and PCI-Express Generation 1.

Keysight’s Infiniium oscilloscopes contain protocol analyzers as well as the traditional oscilloscope functionality. Because these instruments are for the most part software-based, I’d be reasonably confident that as new communications protocols emerge, software upgrades would be available.

In a white paper on the subject, Leens [7] nicely summarizes the various protocols and different techniques of testing and debugging them. In particular, he makes the point (which never occurred to me, so I found it really interesting) that chips such as FPGAs and CPLDs can be debugged using the SPI interface to talk to their JTAG port. Why? Because JTAG and SPI are both clocked loops. You can read all the internal JTAG registers using the SPI interface. The downside is that JTAG loops can be very, very long, making for rather low speed communications.

Controller area network (CAN-bus)

If you drive an automobile built from the 1990s on, then there is a high probability that the car you’re driving is using a CAN bus for interprocessor communications because the CAN bus was originally designed to be an automotive-based bus. The CAN bus was originally developed in 1983 by the German company Robert Bosch GMBH, and officially released in 1986. The first controller chips, manufactured by Intel and Philips, were released in 1987.

Since its introduction as an automotive standard, the applications of the CAN bus have expanded to industrial applications, medical, and military as well as other applications that face harsh physical environments [8].

For signs of how widely CAN bus applications have grown, you can find CAN bus cards (Arduino Shields) for most of the mainstream single-board computers. The ISO11898-2 and ISO11898-5 specifications provide details for the high-speed CAN physical layer or transceiver as described by Monroe [9]. According to the author, finding common problems with CAN bus operation is relatively straightforward and may be accomplished with the most basic debugging tools. Of course, like any other widely accepted standard, there are specialized tools available at various price points with all levels of capabilities.

The LogicPort logic analyzer that I’ve discussed in this and previous chapters also includes a CAN bus interpreter as part of its suite of standard bus protocol interpreters. Probably the most telling example of the wide acceptance of the CAN bus is an advertisement for a CAN bus analyzer for $150 from Microchip being sold through Walmart. Microchip also has a YouTube videoⁱ on the use of the 63r7680 Microchip APGDT002 can bus analyzer tool.

Returning to the Monroe article, the author states that with an ordinary digital multimeter, a power supply, and an oscilloscope, most of the most common CAN bus problems can be identified and repaired.

At this point, I am going to close this chapter of the book. Honestly, I’m not trying to shortchange you, gentle reader. The two articles that I’ve cited here, the EEHERALD article and the Monroe article, are excellent sources for understanding the protocol of the CAN bus (EEHERALD) and how to debug the most common CAN bus problems (Monroe).

Closing remarks

I enjoyed writing this chapter because I learned a lot doing the research of the material for it. I have lots of experience debugging RS-232C and its higher-speed variants; many of my students debug problems with I2C and SPI peripheral devices on their project boards. Also, because my background is designing and debugging microprocessor systems, I’m a lot more comfortable plugging a logic analyzer onto address, data, and status buses and observing 100 + logic signals in parallel than I am trying to make headway swimming against a serial bit stream.

If I were to take the time and condense the Monroe and EEHERALD articles, I think we would both get tired constantly seeing my citations because I don’t plagiarize and I’m merciless with students who do. So, if you are having CAN bus problems, you won’t go wrong taking an hour and reading these two articles.

Additional resources

1. 1. Editorial Staff, Ease the Debugging of Serial Peripheral Interfaces, Electronic Design, https://www.electronicdesign.com/technologies/boards/article/21767094/ease-the-debugging-of-serial-peripheral-interfaces, September, 2001.