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.
Check the wiring to all the needed pins. In no particular order...
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:
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.
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.
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.
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.
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.
Once proper I2C or SPI protocol is observed for the device proceed to trying to write and read-back values.
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.
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.
If the slave is ACKing a write and you want to produce a stop, you need to have the bus in the proper state:
In order to produce a proper Start condition, the bus must be in the proper state
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.
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.
When working with SPI the standards are a bit more shaky.
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:
CPOL
CPHA
Shift (output) Edge
Capture (input) Edge
Clock Idle state
0
Fall
rise (first edge)
Low
1
Rise
Fall (second edge)
Fall (first edge)
High
Rise (second edge)
The spi specification does not specify a clock rate, but 1 MHz is a typical rate.
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.
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.
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.
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.
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.
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.
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
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