-
How Can I See What i2C with the MPU-6050??
Posted by
SuzyC
on 26 Feb, 2016 23:12
-
The MPU-6050 accelerometer chip has many registers, but one of them 0x75 is called the "Who_Am_I" register that hold the I2C address of itself and it is read-only and always reads back 0x68.
But how can anyone attempt to access this register without already addressing this same device address to query this register?
In other words, the i2C address question is already answered..so what's up with this?
-
#1 Reply
Posted by
andyturk
on 26 Feb, 2016 23:19
-
The MPU-6050 accelerometer chip has many registers, but one of them 0x75 is called the "Who_Am_I" register that hold the I2C address of itself and it is read-only and always reads back 0x68.
But how can anyone attempt to access this register without already addressing this same device address to query this register?
In other words, the i2C address question is already answered..so what's up with this?
You'll should already know the I2C address because you set the AD0/SDO pin of the 6050 at boot.
-
#2 Reply
Posted by
SuzyC
on 26 Feb, 2016 23:23
-
That's what I mean, I already know the address, and the AD0 pin makes no difference. So if I haven't used the 0x68 or 0x69(if AD0=1) correct I2C address already so I could access the chip to examine register 0x75 then I wouldn't be able to examine register 0x75 to see this correct address that I must already know!
-
#3 Reply
Posted by
ataradov
on 26 Feb, 2016 23:28
-
It can be useful in combination with a General Call address.
I've never used it though, so I'm not sure if it can be used for reading things out of the device.
-
#4 Reply
Posted by
SuzyC
on 26 Feb, 2016 23:38
-
In any case I seem to have zapped this chip.
The chip fails to issue an *ACK when it is correctly addressed, upon power up after I toggle power and:
SEN=1; //enables transmit mode
WaitMSSP(); //waits for a limited time for SSPIF flag to be set and then resets the flag.
SSPBUF=0x68;
WaitMSSP(); //waits for a limited time to allow SSPIF to be set again by SSPBUF being filled and resets SSPIF
But I can see on my digital scope probing both I2C clock and data lines that the chip has been sent the correct I2C data/clck sequence, but it doesn't respond at all with an *ACK, The 9th clock shows SDAT remains fixed at Vdd when slave must bring it low.
//----------------------------------My Routines--------------------------------
void i2cinit()
{
TRISC3=1; // CLOCK SCL i2c pins starts out with setting cbit3(SSPI clck),cbit4(SDAT) as inputs
TRISC4=1; // DATA SDA for MSSP TRIS'd as input
SSPEN=0; // Reset I2C on 16F886 by Disable->Enable sequence of MSSP port
SSPADD=0x0B; // Master Mode uses SSPADD to set baud: 400KHz clock speed = 2.5uSec/Cycle observed by scope
// SPPADD=((FXtal/400kHz)/4)-1 =11.5
SSPCON=0x28; // Set I2C MasterMode bits SSPCON0:3 SSPEN bit5=1 enables |2C, bit3=1 SSPI mode sets I2C Master Mode
SSPSTAT=0x0; // SlewRate Control enabled
//-----------------------------
void WaitMSSP()
{ k1=0; //unsigned 16-bit int
SSt=0; //Returns the success/failure by value = 0 means success
cbit1=0; //Flag diagnostic pin used to watch on scope to show SSPIF flag action
W4IF:
if(!SSPIF) // while SSPIF=0 stay here else exit the loop only on timeout watchdog barking that its taking too long
{ if(k1<65535) // software timing loop that gives more than enough time for SSPIF to be set before giving up and reporting an error.
{ k1++;
cbit1=1; // SSPIF time to be set is scoped by watching this pin state
goto W4IF;
}
else
{ SSt=i2cerr;
}
}
SSPIF=0; // SSPIF set by SEN/RCEN, PEN fill SSPBUFF operations completed, must clear the flag in any case
}
-
#5 Reply
Posted by
SuzyC
on 26 Feb, 2016 23:47
-
Interesting, ataradov,
But if there were more than one I2C devices, even if there were two MPU-6050's, one at 0x68 and one set to 0x69, then wouldn't both of them try to respond at the same time to this I2C General Call??
-
#6 Reply
Posted by
ataradov
on 26 Feb, 2016 23:54
-
But if there were more than one I2C devices, even if there were two MPU-6050's, one at 0x68 and one set to 0x69, then wouldn't both of them try to respond at the same time to this I2C General Call??
I believe there is some logic to what devices respond. For example it can be only the device that is generating an interrupt at the moment. And my thinking was that they all can share the interrupt line as well, so by reading this register, you will know what device is generating that interrupt. I'm just guessing here. There is no strict definition when and how General Call should be used, so I'm not sure how it may work here.
I never had to use it in my life and never seen a device that would use it.
-
#7 Reply
Posted by
andyturk
on 27 Feb, 2016 00:09
-
[...] And my thinking was that they all can share the interrupt line as well, so by reading this register, you will know what device is generating that interrupt.
Putting two 6050s on the same interrupt line probably won't work that well. At least, Invensense doesn't show a pull-up resistor on the INT signal, which makes it look like push-pull drive (as opposed to open-drain). Even if you did gang them together, you'd still have to poll both over I2C/SPI to figure out what happened. It'd be much easier to just have a separate INT line for each chip.
BTW, I've used Invensense parts in a couple of projects and can't remember blowing one up--they seem reasonably hardy from an electrical standpoint. However, if you're running their code inside the chip (i.e., to get quaternions) don't let the internal FIFO overflow because that *will* lock up the chip.
-
#8 Reply
Posted by
SuzyC
on 27 Feb, 2016 00:20
-
Andyturk, thanks for the tip. I am not using the INT line at all(which is an output) at this point, and it is unconnected.
The AD0 line is tied to ground.
I can see that each I2C clock 0-->1 and 1-->0 width is approx 1.3 uS, so that's pretty close to 400KHz baud that I want.
The MPU-6050 and 16F886 are only separated by 1-in of wiring of Clk Dat line each.
But as I said, right after resetting the chip after power-on, there is no *ack response when the first operation with the device after resetting/initialization, is setting SEN=1 and then issuing the correct MPU6050 device address on the I2C bus.
In any case there is only one device connected to a 16F886 I2C pins and thats the MPU-6050 acclerometer module.
Could it be that I added 10K pullups to +5V. 16F886 Vdd=5V and (oops!) the MPU6050 and its I2C Clk and Dat lines are at 3.3V?
If there was a bus collision with the SDAT line then the 16F886 could try to dump >25mA into the MPU6050 Dat pin at +4 to +5V.
I read on some blogsites that even if the chip VDD is rated at 6V max that this kind of mixed 3.3V / 5V works without a problem..could be bad info!
Izzat the Zap Fact? Things are looking suspicious, the SDAT line is steady +4V, so looks like I've zapped the SDAT pin on the MPU6060 because the Clk pin remains at 3.3V peak when at its high level??
-
#9 Reply
Posted by
andyturk
on 27 Feb, 2016 00:47
-
Could it be that I added 10K pullups to +5V. 16F886 Vdd=5V and (oops!) the MPU6050 and its I2C Clk and Dat lines are at 3.3V?
I read on some blogsites that even if the chip VDD is rated at 6V max that this kind of mixed 3.3V / 5V works without a problem..could be bad info!
Izzat the Zap Fact? Things are looking suspicious, the SDAT line is steady +4V, so looks like I've zapped the SDAT pin on the MPU6060 because the Clk pin remains at 3.3V peak when at its high level??
I've only got the MPU-9250 datasheet handy, but I think it's the same: absolute max on VDD and VDDIO is 4.0V. You might have fried it with 5V.
-
#10 Reply
Posted by
SuzyC
on 27 Feb, 2016 00:51
-
One thing the datasheet shows is that the I2C lines must be <=Vdd+.5 for the MPU6050 which is set by the modules dedicated regulator chip at Vdd=3.3V.
OMG! Things are accelerating from bad to worser and I can't even begin to measure it.
Seems a little confusing though, if you read the specsheet..see attached.
-
#11 Reply
Posted by
SuzyC
on 27 Feb, 2016 01:13
-
Another thing that is confusing is that the MPU6050 specsheet clearly states:
Upon Power-up Reset, the device is in the Sleep state:
4 Register Descriptions
This section describes the function and contents of each register within the MPU-60X0.
Note: The device will come up in sleep mode upon power-up.
That so..howya gonna wake it up to initialize it, when it and the module it rode in on, doesn't have a reset pin!
-
#12 Reply
Posted by
SuzyC
on 27 Feb, 2016 01:38
-
The VoutHi v. IoutMax plot sickens:
Suppose some Arduino freak hooks up his MPU6050 to his 5V super low power AVR chip or similar. The max. IoutHi for a GPIO might be around 5mA instead of the possible 20+ mA for the 16F886, so the Arduino guy, says, "No Problem!, this I2C thing runs fine with +5V Vdd.
You've got to be PICCy, never listen to any Arduino AVR addict's amateur advice!
-
#13 Reply
Posted by
dannyf
on 27 Feb, 2016 01:49
-
'how can anyone attempt to access this register without already addressing this same device address to query this register?'
I2c general call.
-
#14 Reply
Posted by
SuzyC
on 27 Feb, 2016 01:54
-
dannyf, that makes sense..but only if there is only one slave I2C device, otherwise every MPU6050 would bus collide?
-
#15 Reply
Posted by
andyturk
on 27 Feb, 2016 01:55
-
Note: The device will come up in sleep mode upon power-up.
so..howya gonna wake it up to initialize it, when it and the module it rode in on, doesn't have a reset pin!
Sleep means that the MEMS stuff isn't awake, but the I/O logic will still respond and you should be able to read/write registers.
/* Reset device. */
data[0] = BIT_RESET;
if (i2c_write(st.hw->addr, st.reg->pwr_mgmt_1, 1, data))
return -1;
delay_ms(100);
/* Wake up chip. */
data[0] = 0x00;
if (i2c_write(st.hw->addr, st.reg->pwr_mgmt_1, 1, data))
return -1;
-
#16 Reply
Posted by
SuzyC
on 27 Feb, 2016 03:37
-
Thanks andyturk and everyone else, for the help and helping better understand I2C.
Now I can clearly see I have a flatliner chip, my MPU6050 doesn't ACK any address.
-
#17 Reply
Posted by
SuzyC
on 27 Feb, 2016 09:44
-
Thanks dannyf, I get it! This register is a way to check if the chip/interface code is operational at all..and unfortunately it is time for me to accelerate myself down to Frys and get another chip.
-
#18 Reply
Posted by
andyturk
on 27 Feb, 2016 15:42
-
Thanks dannyf, I get it! This register is a way to check if the chip/interface code is operational at all..and unfortunately it is time for me to accelerate myself down to Frys and get another chip.
You can buy accelerometer chips at Frys?
-
#19 Reply
Posted by
SuzyC
on 28 Feb, 2016 03:20
-
The MPU6050 doesn't ACK or respond to an I2C General Call.
The MPU6050 isn't bad, my code was.
You guys didn't catch that I was sending the MPU6050 I2C address wrong.
The I2C address needed to be shifted left 1 bit.
Correct Code to address the MPU6050:
--------------------
i2cinit();
SEN=1;
WaitMSSP();
SSPBUF=(0x68<<1);
WaitMSSP(); //Then I see that the MPU6050 has pulled the SDA line low on the 9th clock bit.
Problem now is that the MPU6050 locks the SDA data line low at power up. The MP6050 BOB doesn't have a hardware reset.
To fix this, I have to physically remove the VDD power to the module to reset it.
How do I reset this locked-up I2C device, like when the SDA line if it is stuck low while the MCU is already running?
void i2cinit()
{
TRISC3=1; // CLOCK SCL i2c pins starts out with setting cbit3(SSPI clck),cbit4(SDAT) as inputs
TRISC4=1; // DATA SDA for MSSP TRIS'd as input
SSPEN=0; // Reset I2C on 16F886 by Disable->Enable sequence of MSSP port
SSPADD=0x0B; // Master Mode uses SSPADD to set baud: 400KHz clock speed = 2.5uSec/Cycle observed by scope
// SPPADD=((FXtal/400kHz)/4)-1 =11.5
SSPCON=0x28; // Set I2C MasterMode bits SSPCON0:3 SSPEN bit5=1 enables |2C, bit3=1 SSPI mode sets I2C Master Mode
SSPSTAT=0x80; // SlewRate Control Disabled
}
-
#20 Reply
Posted by
dannyf
on 28 Feb, 2016 12:15
-
I usually use the already shifted address - it can be easily picked up from the data sheet.
The typical way to reset a stuck i2c bus is to turn the pins to gpio and re-initialize the i2c moduke until it is unstuck.
-
#21 Reply
Posted by
SuzyC
on 28 Feb, 2016 13:25
-
Thanks dannyf, I quickly figured out I could clock any misbehaving slave out of any I2C lockup, just as you've suggested.
About the I2C Address:
the MPU6050 datasheet is very clear about this:9.2 I2C Interface
I2C is a two-wire interface comprised of the signals serial data (SDA) and serial clock (SCL). In general, the lines are open-drain and bi-directional. In a generalized I2C interface implementation, attached devices can be a master or a slave. The master device puts the slave address on the bus, and the slave device with the matching address acknowledges the master.
The MPU-60X0 always operates as a slave device when communicating to the system processor, which thus acts as the master. SDA and SCL lines typically need pull-up resistors to VDD. The maximum bus speed is 400 kHz.
The slave address of the MPU-60X0 is b110100X which is 7 bits long. The LSB bit of the 7 bit address is determined by the logic level on pin AD0. This allows two MPU-60X0s to be connected to the same I2C bus. When used in this configuration,
the address of the one of the devices should be b1101000 (pin AD0 is logic low) and the address of the other should be b1101001 (pin AD0 is logic high)...or is it???
See what the Register Map Doc sez in the attached below:
-
#22 Reply
Posted by
SuzyC
on 28 Feb, 2016 14:08
-
Thanks again, dannyf.
Clearing up an I2C lockup:
void i2cinit()
{
SSPCON=0; Turn off the Master's I2C
TRISC3=1; //Clk pin for I2C
TRISC4=1; //SDA pin
if((cbit3==0)||(cbit4==0)) //Slave has locked up, so clear lockup by clocking in 0's
{ int sj,zj;
cbit3=0;
cbit4=0;
for(zj=0;zj<16;zj++)
{ for(sj=0;sj<16;sj++)
{
cbit3=0;
cbit4=0;
TRISC3=0; //Clk
TRISC4=0; //SDA
}
for(sj=0;sj<16;sj++)
{
TRISC3=1;
TRISC4=1;
}
if((cbit3==1)&&(cbit4==1))
{ break;
}
}
}
TRISC3=1;
TRISC4=1;
SSPADD=0x0B; // Master Mode: SSPADD 400KHz clock speed 2.5uSec/Cycle
// SPPADD=((FXtal/400kHz)/4)-1 =11.5
SSPCON=0x28; // Set I2C MasterMode bits0:3 =0x8 SSPEN bit5=1 enables |2C
// SSPCON:5=SSPEN=1 sets cbit3,4 as i2c inputs i2c=On
SSPSTAT=0x80; // SlewRate Control Disabled
SMP=0;
CKE=0;
WCOL=0;
SSPIF=0;
}
The problem is that I am interfacing a 3.3V device's I2C pins with my 5V MCU. I cannot ever set the Clk, SDA pins high to 5V GPIO state to clock out the I2C jam, I can only safely force a locked high clock or SDA pin low.
-
#23 Reply
Posted by
SuzyC
on 28 Feb, 2016 19:03
-
I can see both sent commands have been acknowledged by the 9th bit, then after a wait of around 150mSec, the Clk clocks in all 1's and SSPBUF= 0xFF
Upon Exit the SDA line is high and Clk is Lo and the SSPBUF is filled with ones and no ACK bit.
Am I missing something??
void WhoAmI(void)
{
//WhoAmi 0x75 always returns 0x68, AD0=1 sets address to 0x69 for 2 accels
if((SSPCONbits.SSPEN==0)||(cbit3==0)||(cbit4==0))
{ i2cinit(); //Resets MSSP then turns on MSSP module again
//MPU6050 will not answer a General Call I2C address= 0
//I2C addresses are concatenated R/*W bit0 in the TX SSPIBUF
}
SEN=1;
WaitMSSP();
SSPBUF=0xD0;//Address=0x68<<1 should put MPU6050 in receive mode
WaitMSSP(); //Wait for ACK from MPU
SSPBUF=0x75; //Who_Am_I request reg in MPU-6050
WaitMSSP();
//Transmission of Who_Am_I request command is complete, MPU must reply
RCEN=1;
if(!SSPSTATbits.BF)WaitMSSP();
ACKDT=1; // Acknowledge data 1: NACK, 0: ACK
ACKEN=1; // Enable ACK to send
PEN=1; // Stop condition
WaitMSSP();
}
-
#24 Reply
Posted by
andyturk
on 28 Feb, 2016 19:31
-
"Am I missing something??"
Posting obscure code samples and hoping others will find your bugs isn't a great way to get help on the internet. Also, it's not clear at this point whether you're dealing with a hardware problem (e.g., 3V3 into 5V logic), an I2C implementation issue, or something that's specific to the MPU-6050.