Protect your tools when the hardware bites back

I recently had an exciting experience where I was working with a client who was having I2C issues with a new board they had developed. To speed up the debugging process, I connected my I2C/SPI bus tool to their development board and custom-built hardware. Being able to view the I2C traffic would allow a quick resolution to why the board was not communicating as expected.

After they made a few minor adjustments to their hardware, we applied power to the setup only to discover that nothing was functioning. As it turned out, a solder bridge had formed during the “quick” board modification, causing a short on I2C that applied 28 volts to the bus. The short managed to not only take out the custom hardware and a $300 development board, it also took out my $400 I2C/SPI tool. To help prevent readers from experiencing the same angst, today we will examine how developers can protect their tools and equipment that are connected over I2C, SPI and UART.

Protecting I2C Tools

Protecting an I2C bus analyzer or host on the I2C bus is straightforward. There are basically two main components that are needed:

  • A bi-directional I2C isolator that can support up to 1 Mbps data rates
  • A break-out board

A search at the readers favorite part supplier should reveal a dozen or more choices for potential isolates. Be careful when reading the datasheets! There are general purpose isolators that are unidirectional! In these cases, you might be able to monitor the bus but not write to it or vice-versa!

One isolator that I’ve to be quite interesting and that I’m currently using to protect my I2C tool is the Texas Instruments ISO1540. The ISO1540 is an 8-pin SOIC that provides 2500 Vrms isolation between the two sides of the I2C bus. To protect the I2C bus tool, this or a similar chip would be soldered to a SOIC break-out board.  As can be seen in Figure 1, one side would be powered and connected to the electronics under development while the other side would be powered and connected to the I2C tool.


Figure 1 – The Texas Instruments ISO1540 provides 2500 Vrms isolation on the I2C bus and can be used with datarates up to 1 Mbps. (Source: TI)

Protecting SPI Tools

The process for protecting the SPI bus is very similar to protecting the I2C bus. All one needs is a SPI isolator that can protect the MOSI, MISO and clock lines. In some circumstances, it may also be helpful to have an isolator that can isolate the slave select lines as well. There are basically two options to isolate the SPI tool. First, an isolator could be soldered onto a break-out board just as before or a developer could look for an isolator that has a ready-made development board. In this case, the development board acts as a break-out and there is no extra fuss for the developer.

There are quite a few options out there for SPI isolators. A 3.75 kV isolator that I’ve started to use in the lab is an Analog Devices ADuM315x. The isolator supports clock rates up to 17 MHz and includes three lower data rate channels that can be used to address or protect multiple slave selects all within a single package. No matter which isolator is selected, it will remove the concern that a solder bridge or hardware failure will damage an expensive development tool.

Protecting UART Tools

Several years ago, although it feels like just a few shorts months, I wrote an article for EDN.com entitled “Isolated USB-to-UART converter builds in 20 minutes for $20” and published a short video on how to build it that can be found here. It turns out that this is still a valid method that can be used to protect a computer and USB port from any unwanted electrical coupling that could cause damage. If you are interested in protecting your UART, I recommend that you check out those resources.

Conclusions

I always advocate that developers isolate their test tools from the hardware that they are developing on. The reason is simple; working with untested, virgin hardware is a recipe for sparks to fly! You just don’t know what could go wrong and if it does, no developer wants their hard-earned development tools to go up in smoke. Protecting development tools is as simple as adding an isolator to the setup, which for all buses can be done in 20 minutes for less than $20 per bus.

Take a few moments today to identify what critical path tools you have that should be isolated and develop a plan to protect them. Just a few minutes today can save you a huge headache later at a time when its least convenient.


Jacob Beningo is an embedded software consultant, advisor and educator who currently works with clients in more than a dozen countries to dramatically transform their software, systems and processes. Feel free to contact him at jacob@beningo.com, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.

1 thought on “Protect your tools when the hardware bites back

  1. “JacobnnIn the good old days Intel's philosophy was that design tools like emulators were not cost-sensitive. The early emulators cost many thousands of dollars to go with the expensive development systems.nnIn order to allow the developers access to t

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.