State of I2C in MSP430 based devices. (MSP430F5529)

[altineller 4]

Hello,

 

What is the state in i2c port when using energia?

 

There is wire library, which appears not to work (MSP430F5529)

 

There is also jrowbergs i2cdev lib library, which also would not compile (missing i2c.h) - what does this library do?

 

I have uploaded the sample code below and attempted to measure i2c outputs on both F5529 and stellaris launchpad.

I have not been able to measure anything unfortunately. (Maybe the pins need to be pulled up?)

 

#include <Energia.h>

#include <Wire.h>

 

boolean state = false;

 

void setup() {

  Wire.begin(); 

  pinMode(P2_3, OUTPUT);

}

 

void loop() {

  

  Wire.beginTransmission(4); 

  Wire.write(0xff);     

  Wire.write(0xff);           

  Wire.endTransmission();   

  

  if(state) {

    state = false;

    digitalWrite(P2_3, HIGH);

  } else {

    state = true;

    digitalWrite(P2_3, LOW);

  }

  

  delay(1);

 

}

[dubnet 238]

I don't believe the launchpads have the necessary pullup resistors (somebody please correct if I am wrong).  I have used wire successfully on the MSP430G series launchpads but haven't tried it on either the Stellaris or 5529 launchpads (the device I communicated with had the pullups).  Just curious, how are you measuring output on the I2C lines?

[bobnova 59]

I've had to use external pullups on the TI MCUs I've used i2c on. That's the G2553, LM4, and TM4C129.

Doing a pinMode(INPUT_PULLUP) didn't work for me on any of them.

External pullups worked great.

 

 

Right up until something hangs with SDA or SCL LOW or misses a count, at which point it's reset button time.

I've been meaning to see if I could fix that. It seemed like it was mostly an issue with the TM4C129 though, so you may not have it. And of course I may have been doing it wrong.

[abecedarian 330]

@bobnova- INPUT_PULLUP settings will get discarded since SCL (in master mode) is an output and SDA is bi-directional.

 

I've nothing to back this up, but what are the pull-up resistor values? Too high a value will cause the signal slew rate to increase causing things to miss timing requirements. Also have to be careful interfacing a 3v MCU with a 5v I2C device for the same reason: high-value resistors to limit current can adversely affect the slew rate, and this will be more apparent on a faster device. TI (and others) have level-shifters for this purpose- such as http://www.ti.com/product/TXS0102.

[oPossum 1,083]

2.2k is a reasonable value for 3.3V IIC. Both SDA and SCL require resistors because they are both open drain (pulled low only). The SCL line is open drain to allow a slave to do clock stretching - a rarely used feature.

[altineller 4]

2.2k is a reasonable value for 3.3V IIC. Both SDA and SCL require resistors because they are both open drain (pulled low only). The SCL line is open drain to allow a slave to do clock stretching - a rarely used feature.

 

I put 2.2k resistors as you suggested, and then I was able to drive the 0.96" oled screen, (not the boosterpack but the one i got from tindie)

 

But still I am having some problems with i2c, especially with sensors. For example the mpu9150 or the mpu6050.

 

I have ported https://github.com/richards-tech/MPU9150Lib into energia, and it works and compiles and runs, but sometimes crashes or gets errors in reading compass.

 

There is this page: https://code.google.com/p/launchpad-stellaris-energia/wiki/Mpu6050Usage which says they have done some changes in 

 

"Energia Stellaris wire library not work correctly on 400Khz speed, fix included."

 

What are the parameters we can set the wire library? In spi, there is a clock divider setting for example. In i2c also, we set which bus we want to use.

 

Best regards,

C.A.

[bobnova 59]

twi.h has a speed setting early in it.

It looks like you might be able to define "TWI_FREQ" in your code before you include Wire.h (which includes twi.h, which checks to see if TWI_FREQ is defined and if not, defines it) and set the speed that way.

twi.h kicks off with figuring out what sort of serial interface the MCU has, then hits the speed section:

#ifndef TWI_FREQ
#define TWI_FREQ 100000L
#endif

My guess is that it's in Hz, 100kHz seems like a reasonable default speed.

Will it work faster? I have no idea.

[altineller 4]

twi.h has a speed setting early in it.

It looks like you might be able to define "TWI_FREQ" in your code before you include Wire.h (which includes twi.h, which checks to see if TWI_FREQ is defined and if not, defines it) and set the speed that way.

twi.h kicks off with figuring out what sort of serial interface the MCU has, then hits the speed section:

#ifndef TWI_FREQ
#define TWI_FREQ 100000L
#endif

My guess is that it's in Hz, 100kHz seems like a reasonable default speed.

Will it work faster? I have no idea.

 

I have tried 100,200,400 for TWI_FREQ and still same problems. I will rewire the hardware and hookup a logic analyzer in an attempt to actually see the i2c data, and check if frequency of it is actually equals to defined TWI_FREQ.

[Lgbeno 189]

I'm having issues with I2C as well.  I have pull ups installed as well.  I have a guess as to what is wrong...

 

For Electric Imp, I successfully talked to a Si7005 via I2C and this is a good transaction looks like:

 

 

Now if I use the following Energia Code:

 Wire.beginTransmission( 0x40 );
  Wire.write(0x00);
  Wire.endTransmission( );
  Wire.requestFrom(0x40, 1);
  while(Wire.available())    // slave may send less than requested
  { 
    char c = Wire.read(); // receive a byte as character
    Serial.print(c);         // print the character
  }

I get:

 

I don't think that my sensor likes that stop bit in the middle of the packet.  From what I read, this can be avoided as follows:

  Wire.beginTransmission( 0x40 );
  Wire.write(0x00);
  Wire.endTransmission(false);
  Wire.requestFrom(0x40, 1);
  while(Wire.available())    // slave may send less than requested
  { 
    char c = Wire.read(); // receive a byte as character
    Serial.print(c);         // print the character
  }

Notice the False in "endTransmission" however when I scope this out, this is what I get:

 

Why would this add a write frame in?  Is it a bug or intended to do that?

 

BTW I'm using MSP430G2553

 

Also I posted some stuff on this thread about a similar issue with the software based Wire lib:

http://forum.43oh.com/topic/3617-energia-library-software-i2c-master-for-msp430g2553/

[L.R.A 78]

That is odd, it seems somehow the address sent is called again.

i'm looking at the source code, let's see if i remember msp430 programing.