Problem with I2C - using LM4F120 launchpad board

If the master is always stuck in busy state, there may be an electronic problem.

Do you have the proper pull-ups on the I2C lines?  If either line is stuck low, then the master will stay stuck in a busy or an error state.

Also, have you properly initialized all the peripherals and pins?

It's hard to tell exactly where you are stuck when it's not clear exactly what you've done.

As Slandrum states - w/out reasonable code listing - your "helpers" are bit stuck.

Unless..... you have copied M3 code for I2C - as M3 code does not provide the M4 "required"    GPIOPinTypeI2CSCL

Here's a known good set-up for 64 pin M4F (not launchpad MCU)  Pinouts may not be the same as on your MCU...

void     
i2c_setup(void)
{
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C1);
   
        GPIOPinTypeI2CSCL(GPIO_PORTA_BASE, GPIO_PIN_6);   //   I2CSCL    *** note - this function has not yet made it into MCU ROM!
        ROM_GPIOPinTypeI2C(GPIO_PORTA_BASE, GPIO_PIN_7);   
   
        ROM_GPIOPinConfigure(GPIO_PA6_I2C1SCL);   
        ROM_GPIOPinConfigure(GPIO_PA7_I2C1SDA);
}

This GPIOPinType() issue - unique to LX4F - has caught many...

Should this not prove the "fix" - you should post the Slave's Address (from Slave Datasheet - not your interpretation) and show us your code which emits this address...

Unstated is how you've cabled/wired between your Slave and TI board.  Are connections proper - and robust?  Do you provide proper voltage to the Slave?  Have you insured that neither the MCU board nor Slave are "uniquely" powered?  (i.e. only one powered - however briefly)

Doubt that board includes normal/customary I2C pull-ups - thus these must reside upon your Slave board.  You've got to get many things "right" for this to work...  Oversight in design - bit lacking as no: "I2C header" provided (carrying pull-ups, power etc.) - thus board falls some HP short of a true, "launch!" 

First of all thank you very much for your quick responses.

I am sorry that I didn't mentioned my code and other details in my question.

Well I am interfacing Accelerometer - MMA8451Q with LM4F120H5QR using I2C interfacing.

I have connect pull up resistors of 4.7k with SCL & SDA line.

the sensor is following communication as shown in picture :

The program is as follow

#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "inc/hw_i2c.h"
#include "inc/hw_ints.h"
#include "driverlib/interrupt.h"
#include "driverlib/i2c.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "utils/uartstdio.c"

#define SLAVE_ADDRESS 0x1C                           // Address of sensor
unsigned int rx,tx;
unsigned long t,i;

void uart_enable()
{
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    UARTStdioInit(0);
    UARTprintf("\n\n\rMMA8451Q _ Accelerometer Reading");
    UARTprintf("\n Module = I2C0");
    UARTprintf("\n Rate = 100kbps\n\n");
}

void main()
{
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);                     // 80MHz clock
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);            // Port B - Enable
    GPIOPinConfigure(GPIO_PB2_I2C0SCL);                        // Demux_PB_2 & PB_3
    GPIOPinConfigure(GPIO_PB3_I2C0SDA);
    GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3);  // Set the I2C function for PB_2 & PB_3 pins

    uart_enable();
    tx=0x00;
   

    I2CMasterInitExpClk(I2C0_MASTER_BASE, SysCtlClockGet(), false);
    I2CMasterSlaveAddrSet(I2C0_MASTER_BASE, SLAVE_ADDRESS, false);
 

while(1)
     {
         tx++;                                                                       // tx = register address which I want to read.... tx = 1 to 6
         UARTprintf("  Sending Reg. Addr.: %d", tx);

         I2CMasterControl(I2C0_MASTER_BASE, I2C_MASTER_CMD_BURST_SEND_START);
         I2CMasterSlaveAddrSet(I2C0_MASTER_BASE, SLAVE_ADDRESS, false);            // give slave address to get comm. & R/!W bit on end

         I2CMasterDataPut(I2C0_MASTER_BASE, tx);
         I2CMasterControl(I2C0_MASTER_BASE, I2C_MASTER_CMD_SINGLE_SEND);

         t=I2CMasterLineStateGet(I2C0_MASTER_BASE);
         UARTprintf(" \n\r line state : %d \n\n\r", t);
         while(I2CMasterBusy(I2C0_MASTER_BASE));                                 //wait while transferring

         I2CMasterSlaveAddrSet(I2C0_MASTER_BASE, SLAVE_ADDRESS, true);
         I2CMasterControl(I2C0_MASTER_BASE, I2C_MASTER_CMD_SINGLE_RECEIVE);

         rx = I2CMasterDataGet(I2C0_MASTER_BASE);
         t=I2CMasterErr(I2C0_MASTER_BASE);
         UARTprintf(" \n\r\n\n\r Received data : %d \n\n\r", rx);
         UARTprintf(" \n\r error : %d \n\n\r", t);

         for(i=0; i<100000; i++){}
         if(tx==0x06)
         {
             for(i=0; i<100000; i++){}
             tx=0x00;
         }
     }
}.

PROBLEM :  The communication is not working.

When I tried to go step wise execution I got that the processor is not implementing this function properly :

"  I2CMasterInitExpClk(I2C0_MASTER_BASE, SysCtlClockGet(), false); "

at this function processor is going in infinite loop (FaultIISR() { while(1){} } )

I am not able to know the reason :(

Please help.

Thanks for your time.

You are not enabling the I2C Peripheral itself.  The first time you call a function that attempts to access its registers, your program will fault.

You also aren't explicitly enabling the UART, but the UARTStdioInit() function will do that for you.

cb1_mobile said:

void     
i2c_setup(void)
{
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);

As Slandrum repeats here - enabling I2C Peripheral was 1st item modeled for you - in my answering post...

However - that is not all ........ missed by you and others was the crucial (for Stellaris M4 users):

"GPIOPinTypeI2CSCL(GPIO_PORTA_BASE, GPIO_PIN_6);   //   I2CSCL    *** note - this function has not yet made it into MCU ROM!

Rejection of "known good code" is not always the fastest - nor wisest - path to solution...

Thanks a lot...

I get those mistakes.

But now I've one more problem...

The program is now stuck at  this function : " while(I2CMasterBusy(I2C0_MASTER_BASE));   "

could you please tell me why this had happened and what should I do to solve it...

Thank you so much sir.

Unknown now - the extent & impact of any of your code "modifications" to that past suggested.  (you must put yourself in the position of your remote "assistants.)

We find it safest to exactly implement "known good code" - test/verify - and only then add our "modifications."

Doing too much at once - often obscures problem creation...

http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/235926.aspx

.. Searching the Forum sometimes reveals Lost treasures...

aBUGSworstnightmare

aBUGSworstnightmare said:

Searching the Forum sometimes reveals Lost treasures...

Well said!   However - operative only if user does not "improperly change the mix" - yielding "fools" rather than "real" gold...

Thanks for that link sir.

It helps me to understand the procedure/step for I2C.

I've used it.... But the problem is occurring at the same place... the execution stops at " while(ROM_I2CMasterBusy(ulI2CBase))    {    }; "

I think the problem may be in salve !?

I am using MMA8451Q Accelerometer... I've gone through all the notes/datasheets/forums... no body has a problem like this.

And I am unable to evaluate that whether the problem is from master side or slave side :(

Here is my code which I've updated last (using your files):

void main()
{
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_5 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);                     // 80MHz clock
    tx = 37;
    I2CSetup(I2C1_MASTER_BASE, true);
    InitConsole();
    while(1)
    {
        tx++;
        rx = I2CRegRead(I2C1_MASTER_BASE, 0xD0, tx);
        UARTprintf("\n\r received reg. : '%c'", tx);
        UARTprintf("\n\r received value : %d",rx);
        for(i=0; i<100000; i++){}
        if(tx==45)
        {
         for(i=0; i<100000; i++){}
         tx=37;
        }
    }

}

Do I need to send start condition, repeat start & stop condition ???

Isn't it involved in the API Functions which I've used ???

& if I need to send those signal then can you guide me for the same please ?

Hi,

I'am not expert in I2C but what I can see is you are not decided about the system clock - your actual settings gives the clock 3.2 MHz, which contradicts the intent (comment:  80MHz) -in the first post you played with 6.4MHz - can you revert to real 80MHz? (just for testing).These actual settings lead to I2C clock 80KHz.

 Another problem: the slave device asks  for "I2C Fast Mode" - while the frequency can vary from 0 to 400KHz, some maximum acceptable delays are explicitly set for 400 KHz. (SDA valid time for instance - page 8 in the data sheet). Your opinion about that?

Petrei

Jigar Patel3 said:

 ROM_SysCtlClockSet(SYSCTL_SYSDIV_5 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);   // 80MHz clock

Feel your pain - however attention to detail remains suspect.  Error above "leaps from page" - cut/paste w/out proper review - not likely to lead to treasure...  (you failed to engage the PLL)

@ aBUGSworstnightmare,

I've tried the same code on my another sensor which follows the same I2C interfacing protocol.

It works!

Thanks a lot for that program sir.

so I've conclude that the problem was in my sensor which keeps the master busy all time!

To solve that I've scan the bus using your code to check the correct address of it. the strange thing which I've got : 127 Devices found!!!

master has got the acknowledgment from device address 0x00 to 0x7e !!! (127 device found!) how it is possible sir?

I've check the same code with my new sensor then it is indicating only one device with 0x68 address.

So I would like to ask you that is there any way to get my bad sensor again on a proper track - I am using MMA8451Q - Accelerometer.

Thank you so much for all your help & time.

@cb1_mobile, Actually I am using LM4F120 eval board which have this feature to set the clock using osc. That's why I've not mentioned PLL.

Thanks for your help sir.

Jigar Patel3 said:

I've tried the same code on my another sensor which follows the same I2C interfacing protocol.

Hi Jigar,

which 'other sensor' are you using? Pls provide more details on this since I doubt that it uses 'the same' addressing scheme as the MMA8451Q!

Have a look at page 18 of the MMA8451 data sheet (MMA8451Q.pdf). When examining the I2C protocol of this device you'll see that it needs repeated start conditions and a second transfer of the slave address. This is not covered by my API --> you need to expand it for dealing with the MMA8451Q.

The 'I2CBusScan'-routine instead should also work with the device since it only places an address on the I2C bus and than checks it there's an Acknowledge (Freescale calls it AK in the data sheet) or not (NAK -> no acknowledge). It then proceeds with the next address.

Jigar Patel3 said:

To solve that I've scan the bus using your code to check the correct address of it. the strange thing which I've got : 127 Devices found!!!

master has got the acknowledgment from device address 0x00 to 0x7e !!! (127 device found!) how it is possible sir?

I've check the same code with my new sensor then it is indicating only one device with 0x68 address.

When using the 'I2CBusScan'-function from my API the the MMA8451Q should acknowledge at slave address 0b0011100 = 0x1C --> this also indicates that your 'new' and 'old' sensor are different devices.

Getting AK for all addresses leads me to the assumption that either your ACC sensor is damaged, bus capacity is too high (long connection leads) and pull-up resistors have the wrong values.

Can you provide details of your sensor hardware (schematics)?

Rgds
aBUGSworstnightmare 

aBUGSworstnightmare said:

which 'other sensor' are you using? Pls provide more details on this since I doubt that it uses 'the same' addressing scheme as the MMA8451Q!

I've tried that using L3G4200D 3 Axis Digital Gyroscope... and it works.

the I2C protocol for gyro sensor is something like this:

here SUB is reg. address

Repeat start is also required in gyro ("SR bit") but I have used your code without any modification. And its working fine with it.

The Schematic for both Gyro and Accelerometer sensor board are displayed here :

Accelerometer : http://www.nex-robotics.com/products/sensors/mma8451-3-axis-digital-accelerometer-with-voltage-regulator.html

Gyro : http://www.nex-robotics.com/products/sensors/gyroscopes/l3g4200d-3-axis-digital-gyroscope-with-voltage-regulator.html

(I am just connecting the controller board with these sensor board appropriately.)

Gyro has 10k Pull up resistor

& Accl has 4.7k pull up resistor, I think values are okay. Do I need to change them in case of accl. ?

One more thing I would like to mention is, datasheet has given fault addresses of slave!

Gyro has 0x68 address (in datasheet 0xD0 has indicated) and for accl. I am not able to have proper address of it. & so controller is going in busy state however if I reset it then for the first time it works and scan the bus and have shown me that 127 devices found and when I scan it again it goes in busy state, and if again I reset it then for the first time again it hows 127 devices and so on.....  (this case is of accl.)

Gyro is working perfect and I am heartily thank full to all of you experts.

Could you please guide me to evaluate the problem of accl. please ?

and one last que. how I could add SR (repeat start condition) in my programming and command or API function ?

I guess I2C_MASTER_CMD_BURST_SEND_CONT or I2C_MASTER_CMD_BURST_RECEIVE_CONT ???

Thanks to all.

Hi,

1.) what is your SA0 connection for the ACC (GND pr 3.3V)?
''The MMA8451Q's standard slave address is a choice between the two sequential addresses 0011100 and 0011101.'

Jigar Patel3 said:

One more thing I would like to mention is, datasheet has given fault addresses of slave!

Gyro has 0x68 address (in datasheet 0xD0 has indicated) and for accl. I am not able to have proper address

ONE THING TO NOTICE: The addresses above are 8-bit addresses (7-bit device address + R/W-bit)

So, the 7-bit address - which you need when using my API - is i.e. 0b1101000 (with SD0 connected to GND) = 0x68!

aBUGSworstnightmare

@Bug - far above/beyond - very nice job! - hereby memorialized...

Suspect that poster should provide "exact" I2C "Set-up/Config" code - so that the "7/8 bit I2C Slave address" really is understood/correct.  (nightmare in the making - even w/out esteemed "Bug" presence) 

Phillips I2C group have not made too many "friends" w/this I2C address scheme "shortcut!"  (i.e. constant, unresolved torment...they saved a byte but plunged thousands - "over the cliff")  Individual makers interpretation often differs - adding to this quagmire...

@ aBUGSworstnightmare, Thnks for indicating that. I got the logic behind that.

But my problem with accelerometer is still there.

what should I do to check whether my accelerometer is proper or not!

Any trick through which I can do that?

I've spent so many time to find that.

it always keep the master busy! and also the master is getting the acknowledge at all the addresses from 00 to 7E !

what problem should I get without the pull up resistors? the resistors are on board in my case (as I've posted the link of the circuit of accelerometer).

It works perfectly with gyro and it is not working with accelerometer. Any solution ?

The biggest problem I am facing is I am new to I2C, LM4F & MMA8451Q .. I don't think that the sensor could get damage at 3V or by any fault attempt to communication.

Feel your pain - would it not make sense to (temporarily) obtain the most basic I2C EEprom (low capacity) - and attempt to transact w/that?  (be sure to include pull-up resistors - they are mandatory)

My belief is that you need to establish some "proof" of your code, board, power distribution and external Slave device capability.  Any "break" in that linkage will condemn your efforts to failure.  Power should be supplied to both your MCU board and Slave (board?) from the same source - so that "one-board only" power is prevented!

"Learning" I2C with a fairly complex Slave device predictably results in such frustration.  (both for you - and others)

Thanks for the response cb1_mobile.

I think I am very near to get the solution.

I've refer the datasheet one more time.

Here is the what specs. for SCL the datasheet is indicating :

My mistake was -  I was trying it with 100kHz and 400kHz with 4.7k pull up.

In my accelerometer board schematic (shown below) it has shown that Cb (Bypass capacitor) is not there! (AM I WRONG while saying this?)

Pin 2 : has a Bypass capacitor of 0.1uF but is it my Cb ???

Cb is a Total capacitance of one bus line in pF which could be 20pF, 40pF or 400pF.

So now I need some experienced suggestion that what capacitor I should connect where & which SCL frequency I should use?

& if the SCL frequency is other than 100kHz or 400kHz then how I can initialize the softI2C ?

For datasheet of MMA8451Q, you can have it from here : http://www.nex-robotics.com/images/downloads/MMA8451Q.pdf

PLEASE help me out with this.

Thanks for your time.

Hi Jigar,

Cb is the total I2C bus capacity resulting from the device itself, PCB traces, wires, ...

The maximum allowable bus capacity in the I2C specification is 400pF.

For this device, the maximum allowable bus capacity for 100kHz bus operation is 40pF(!).

So:

- be shure you configure your I2C peripheral for 100kHz operation (and not 400kHz)

- keep your connection wires as short as possible

- don't use to many 'interconnect points' to keep the capacity low. That means: solder the wires (if possible) and don't use jump wires; i.e. solder the wires to your breakoutboard and only use a connector on the Launchpad

- be shure to connect SA0 to GND (prefered) or VDD (3.3V), dependent on your desired slave address

- check your breakout-board with a know-good I2C master (most of the time I'm using my Buspirate (http://dangerousprototypes.com/docs/Bus_Pirate) for the first 'ambush' on a new I2C device. 

aBUGSworstnightmare

Should I try using SCL = 2.25 MHz ?

I've already tried using 100 khz & also have used 400kHz by mistake ! :(

currently I am using jump wires on both the side... I'll solder it on one side.

The length of the wire is about 20 cm. I'll  decrease it.

SA0 is ground.

I am not able to use any I2C Master because it is too costly! Buspirate will costme about 30 $. That's too much for me.

Do you relly think that only because of the length of wire I am getting this problem at 100 kHz.. Though I am going to apply all your suggestion I've a doubt that how we can conclude that how much bus capacitance I am applying by using wires? And also some more details about it.

Thanks for all your suggestions :)

One more question : What problem should I get if this capacitance in above range or below range??

Here the bus is not busy while I am checking it without puttinhg anything on it.. but when I put something to write then it goes in busy state forever!

Is it a common error!

And when I scan the bus then why it is giving acknowledge at all addresses!

I know these questions are too bad, but this is what I want to evaluate from last 1 week !!!

Hi Jigar,

have you ever managed to get your Acceleration sensor working? Maybe the problem is related to a defective sensor.

I can't give any further recommendations how to hunt the problem down. The only possible solution to verify that your sensor is responding is to use a I2C master (other than your Stellaris Launchpad), i.e. an Arduino device which you (or somebody you know) has at hands and check the sensor with this - known good - I2C master.

aBUGSworstnightmare

I think I've got the problem...

@aBUGSwortnightmare & cb1_mobile, I've apply all your suggestions... But unfortunately I am still facing the problem :(

But still I've got something to ask your help for.

After making all possible tries I've start finding some experience person with this sensor (because problem was from sensor side).

Luckily in some blogs I've got them,

The most likely problem with this sensor is" Repeat start" bit... here is the most likely problem described by an experience person :

" I2C hardware (master) sends a Start Bit, then sends the data and finally sends a Stop Bit. 

After the Stop Bit is sent it then, sends another Start bit, reads the data back and finally sends a final Stop Bit. 

99 times out of 100 this isn't a problem since most devices will work just fine using this setup. " BUT MMA8451Q don't !

It needs repeat start bit as shown here :

I am using "I2CMasterSlaveAddrSet()" at both place : "Device address + W" & "Device address + R"

But I don't know that whether this function(I2CMasterSlaveAddrSet()) is sending ST/SR before device address or not???

If no? then how I could add it?

You are getting help from better sources than me. I will only add a little bit to this.

If I understand your concern correctly, the LM4F120 is hanging on I2C bus busy while attempting to read your sensor.

I have seen similar problems on the BOSCH BMA180 (accel.). If you try to wait on the "BusBusy ???" instruction the system will hang. I am using the Launchpad to test.

The only work around I found was to use a timer instead of waiting for the I2C bus to become "unBusy". I then margined the timer length until I got it to where it would only fail every week or two. This is not a bus capacitance issue of the LM4X120 is waiting to become "unBusy". Bus capacitance may be a contributing factor -- but that is all.

I use the exact same sensor (I can move it) on AVR MEGA 2560 and ATMEL ARM7DTMI with no issues at all -- including the wait on busy bus commands. So there is something funny here.

I could post code -- but I have used the examples posted here by cb1 and others at TI to derive my code. I still have to use the timer to wait after a Repeated Read command.

Hope that helps for confirmation anyway.

Note: I went back and checked your code to confirm. Same issue.

Jigar Patel3 said:

I think I've got the problem...

Hmmm - sounds much like "echo" of past "got it!" 

Throwing time, money, effort @ "reluctant device" seems misguided - especially @ this early stage.

You/we/interested others all NEED to Know that your Stellaris can correctly - and consistently - transact w/ a "normal" I2C Slave.  And that all "necessary" interconnects, power connections/sequences and I2C dictates have been met.

I've tried to sound the alarm that any "break" in the I2C chain will doom your efforts.  Yet only "silence" returns in response to multiple, past, direct requests for necessary interconnect, power distribution, and "far simpler" device transactions. 

The direction I've provided aims at insuring that you have the proper I2C "foundation" - so that you have the best chance to succeed with your more complex - end goal. 

During one post - you stated, "It works perfectly with gyro."  But facts to support this are slim (none, really) and the duration and depth of such "test" are with-held - rendering this assertion "almost" out of place - and far from compelling...  Should this past success be so minimized - so short of mention?  Instead - should not the pertinent, "Gyro" data-sheet be overlayed against your "reluctant" Accel - so that the always valuable "A-B" comparison may be enabled?  (Pardon - but as this issue drags on and on - such over-sight disturbs...)

Desire alone may not be an adequate "driver" for this flight - even skilled, long-term pilots employ, "pre-flight checklist" (which identifies/insures the "basics") - and does much to raise the odds that trusty craft will - once more - safely top, "next mountain."