1         Introduction

Many of the issues we get for support at ez.analog.com for the MEMS sensors relate around basic communications problems.  In these days of “plug and play” software and interfaces some of the basic I2C and SPI communications can be troublesome to get past the “hello world” stage.  This document is intended to be a consolidation of the most common issues and basic tips we use to help customers get up and running.  It is divided into a few sections so use the sections that are appropriate to your device.

2         Start with the basics

2.1       Check the Wiring

Check the wiring to all the needed pins.  In no particular order...

• Check the ground. Some parts have multiple ground pins.
• Check to power to all the power pins.  Some parts have multiple power pins such as Vs and Vddio.
• Check any “reserved” pins that need to be tied to power or ground.
• Check any “address” lines that may set the I2C address.
• Check the connections on all the active communication lines.

You may wish to use one of our sample break-out-boards that bring the needed signals out to pins that are easier to solder to or plug into a proto board.

With the power on check with a meter, oscilloscope, or logic analyzer all the address and data lines:

• Are signals that should be low actually low and not floating?
• Are signals that should be high actually high and not floating?
• Are signals that should be floating actually floating?
• See more suggestions in the logic analyzer section.

If everything works with our sample board, but not with your board, go back and re-check all the wiring.  If you read through ez.analog.com you will find a case where someone had problems with their soldering of the parts to their board.

2.2       Use Proven Software

In some cases there may be drivers and or header files for the part and processor you are using.  There are examples using the ADuC702x parts and PICs in engineering zone and there are linux drivers from some parts as well.  Forums for various processors may also have sample code.

2.3       Use Simple Software

Start simple.  Most people just try to read the device ID or some other constant registers to know the part is connected.  There is an engineering zone article with sample code that tries multiple addresses to find a part.  (Look later in this paper for links to the articles)

Keep it simple.  Try using simple code perhaps bit-banging through GPIO.  Often times the setup of a hardware peripheral on a processor is a bit more confusing than it seems from the data sheet, there may be additional power control or clock control register that need setting to properly enable a hardware peripheral.

Keep it simple.  Put the code in “main” and use simple functions to break it down, if trying to use interrupt driven software there may be a few tricks you missed with your setup.  Try not using interrupts until you have verified the basic hardware and software.

2.4       Use a Logic Analyzer

Many inexpensive USB based logic analyzers now exist and many of them can decode I2C and SPI communications.  There are also many newer oscilloscopes that can also interpret I2C and SPI.  Just thinking you know what is happening on the serial lines can be quite different from actually seeing what is happening on the serial lines.

Check the idle state of all communication lines.  I2C and different SPI protocols have different idle states for clock, data and chip select.  Check any address lines, check all input and output signals. See more suggestions below in the I2C and SPI specific sections.  

2.5       Debug Basic Communications Reading Constant Data

All devices have some identifying information that can be read out of registers such as device or product ID and/or revision ID.  Set the software to continuously read some of this information in a loop.  Consult the data sheet for the device you are using to select an appropriate register.

• For a SPI device you can trigger an oscilloscope on the high to low transition of the chip select and observe all the other signals.
• For an I2C device this is typically a longer transaction where the register address is written then the read is started, you should be able to trigger on the falling edge of SCL to find the start of the transactions.

Once proper I2C or SPI protocol is observed for the device proceed to trying to write and read-back values.

2.6       Burst (or multi byte) Transfers

While more advanced than getting the basic communication working, burst transfers is an important topic.  Some parts support or even prefer or require multi-byte transfers.  Both I2C and SPI protocols can support burst transfers.  Burst transfers can improve bus efficiency and also allow the microprocessor to spend less time communicating and therefore potentially lower power since the micro can sleep more.

Some parts such as ADXL345, ADXL346, ADXL350 ADXL312, ADXL313 , ADXL362 and many others prefer or require multi-byte transfers.  Since the above listed parts are multi-axes accelerometers which output multiple bytes per axis, you most likely desire to have the high and low bits for an axis go together and you probably want the X, Y and Z readings to be correlated.  These parts know when a read access starts and internally hold the data to be correlated.  If you read the axes individually, they may not be correlated, so a burst access assures correlated data.

3         I2C Specific Tips

3.1       Basics

• Do you have pull-ups on both the SCL and SDA lines?
• Are both lines idling high?
• Do you know what I2C slave device ID you should be trying to address?
• Did you verify the lines on the part that affect the address?
• Did you see a valid start followed by the correct slave address on the logic analyzer?
• Can you see the ACK (or NACK) coming back on the logic analyzer?
• If you are not seeing the correct data, when you disconnect the device do you now see a nack?  What do you get as data?
• Are you operating at a data rate and addressing mode that are supported by the device?
  • Most parts support STD and Fast mode
    • STD mode speed is 100 kHz.
    • Fast mode is 400 kHz.
  • Some parts may support FM+ mode at 1.2Mhz.
  • Some parts may support HS mode.
  • Are you using 7 bit addressing, most parts support 7 bit addressing.

3.2       Common symptoms:

• If you are getting back all 0xff values, perhaps you are not addressing the device and you got a nack on the address?
• If you are getting zeros, perhaps the master is holding the data line low or not properly observing the data line.

3.2.1       Dealing with ACK’s, NACK’s, (S) Starts and Stops (P)

Another common area of protocol violation is with ACK’s, NACK’s, (S) Starts and Stops (P).

1)   The ACK or NACK should always come from the receiver which can be the master or the slave.  It’s the one who was not sending the data bits in the byte.

1. If the master is transmitting as in the case of a write or the slave address+read byte, this means the master must go into “input mode” on the SDA line. (and not be driving the line low).
2. If the master is reading (receiving data bits in the byte) it means that the master must drive SDA low for the bytes is read, except the last one!
3. If the master is reading (receiving data bits in the byte) and this is the last byte the master wants to read the master must NACK the byte which could also mean leaving SDA in the INPUT mode.  This does two things:
   1. It lets the slave transmitter know the last byte has been sent.
   2. It has the SDA line in the correct state for a start or restart.

If the slave is ACKing a write and you want to produce a stop, you need to have the bus in the proper state:

1. The Slave will hold SDA low as long as the master is holding SCL high during the ACK.
2. The Master must drive SCL low so the slave can release SDA.
3. With SCL and SDA low, the bus is in the proper state to create a stop condition.
4. The master can release the clock HIGH but hold SDA low.
5. The master can finally release SDA HIGH to complete the stop condition.

In order to produce a proper Start condition, the bus must be in the proper state

1. Both SCL and SDA should be high, indicating that no masters or slaves are either stretching the clock or trying to ack or send data.
2. The master trying to produce a start can then lower SDA with SCL high to produce the start.

3.3       Level shifters

The mosfet level shifters shown in the version 2.1 January 2000 version of the I2C spec work well.

There are also level shifters from sparkfun: http://www.sparkfun.com/products/8745 We have changed the 10k resistors to 1k for faster signals.

3.4       Signal integrity

I2C signals per the I2C spec should have some slew control and should generally be immune to short glitches, but if you have long lines you should look at the signals with an oscilloscope to assure good looking signals.

4         SPI Specific Tips

When working with SPI the standards are a bit more shaky. 

4.1       Clocking modes

There are four different “spi modes” these may be referred to as mode0 – mode3 or as long hand you can select the clock polarity as 0 or 1 and you may select the clock phase as 0 or 1.  In the Original Motorola docs these are generally referred to as CPOL0 or CPOL1 and CPHA0 and CPHA1.  The most common mode is 0 or CPHA0 and CPOL0.  CPOL1 and CPHA1 or mode 3 is also common.  Somewhat less common are the other modes.

Analog devices parts use different spi configurations so consult the data sheet for the part you are using to determine the clock polarity and phase and properly configure your hardware and or software.  Each of these configurations implies the idle state for the clock, be sure your clock idles at the proper level.

A brief summary of the clock polarity and phase details is:

4.2       Clock Rate

The spi specification does not specify a clock rate, but 1 MHz is a typical rate. 

• Be sure to read the data sheet for the part you are using to see what spi speed it supports.
• Be sure to check your SPI master configuration to see that you are running at a supported speed.

4.3       Number of bits

SPI also does not specify a number of bits in a transfer, most ADI parts use 8 bits or multiples of 8 bits.  Check the data sheet for the part you are using to know how many bits to transfer at a time.

4.4       Chip select

The chip select line sometimes called CS, CSN, CS_N, CSB, SSN, and other variants is usually active low.  It typically idles high and should be brought low just before the clocking of data and brought high again just after done clocking data.  Double check the idle state for the part you are using in the data sheet.  Some parts may allow for chip select to be continuously asserted, but most chips require it to change and “frame” the transaction.

Double check that you are only sending out one chip select at a time so only one slave device is active on the SPI bus at a time.

4.5       Level shifters

Since SPI signals are typically unidirectional rather than the bidirectional signals in I2C, simple level shifters like the 74AVC4T245 may be used. Bidirectional level shifters like the I2C level shifters listed above may work or may be too slow.

4.6       Signal integrity

The SPI specification does not specify any drivers, voltage levels, slew rates or deglitching. This can make for a difficult system debug. 

Some low power parts may have limited strength drivers which limit the capacitance on the line they can drive which will limit your SPI speed.

Some parts have high power drivers which may put ringing on the bus and may get seen as multiple clocks to other parts on the bus.

Look at the spi signals with a scope to assure good signal integrity.

5         Resources:

5.1       Industry Standards

5.1.1       I2C

The I2C specification is maintained by NXP, some people refer to the version 2.1 of the spec from 2000, the version 3 in 2007 added the FM+ mode, but deleted the level shifter example.  Version 4 came out in February 13 2012. Since this is an evolving specification, be sure all the devices on your I2C bus are compatible.  Typically fast mode (400 kHz) works for all devices.

5.1.2       SPI

While there is no definitive standard to the SPI protocol it originated with microcontrollers like the 68hc11 and that data sheet has a chapter on SPI.

5.2       Related Tips from Analog

http://ez.analog.com/thread/2419: basics of hooking up an accelerometer to a micro.

http://ez.analog.com/thread/8383 : example code ADXL345, ADXL346 and ADXL350, more I2C debug suggestions.

http://ez.analog.com/thread/2420 : While called “accelerometer applications” it has good sample code showing ADUC7024 and PIC16F84.  Includes I2C bit banging routines.

http://ez.analog.com/thread/8717 : ADXL345 3 and 4 wire SPI code.

http://ez.analog.com/thread/7902 : ADIS16135 SPI interface configuration

http://ez.analog.com/thread/2563 : ADXL345 and ADXL345 header and utility routines.

http://ez.analog.com/thread/11934 : ADIS16407 SPI debugging and general good spi hints.

http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf : I2C reset

5.3       Inexpensive Logic Analyzers

Some suggestions are:

These logic analyzers are inexpensive and come with software that interprets I2C and SPI communications.

http://www.pctestinstruments.com/

http://www.saleae.com/logic