How Can I See What i2C with the MPU-6050?? - Page 1
Forum section: electronics / general

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 26, 2016, 11:12:28 pm
content: 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?

author: andyturk
author_rank: Frequent Contributor
timestamp: February 26, 2016, 11:19:48 pm
content: Quote from: SuzyC on February 26, 2016, 11:12:28 pmYou'll should already know the I2C address because you set the AD0/SDO pin of the 6050 at boot.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 26, 2016, 11:23:46 pm
content: 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!

author: ataradov
author_rank: Super Contributor
timestamp: February 26, 2016, 11:28:31 pm
content: 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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 26, 2016, 11:38:15 pm
content: 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 modeWaitMSSP(); //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 SSPIFBut 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 inputsTRISC4=1; // DATA SDA for MSSP TRIS'd as inputSSPEN=0; // Reset I2C on 16F886 by Disable->Enable sequence of MSSP portSSPADD=0x0B; // Master Mode uses SSPADD to set baud: 400KHz clock speed = 2.5uSec/Cycle observed by scope// SPPADD=((FXtal/400kHz)/4)-1 =11.5SSPCON=0x28; // Set I2C MasterMode bits SSPCON0:3 SSPEN bit5=1 enables |2C, bit3=1 SSPI mode sets I2C Master ModeSSPSTAT=0x0; // SlewRate Control enabled//-----------------------------void WaitMSSP(){ k1=0; //unsigned 16-bit intSSt=0; //Returns the success/failure by value = 0 means successcbit1=0; //Flag diagnostic pin used to watch on scope to show SSPIF flag actionW4IF: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 stategoto W4IF;}else{ SSt=i2cerr;}}SSPIF=0; // SSPIF set by SEN/RCEN, PEN fill SSPBUFF operations completed, must clear the flag in any case}

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 26, 2016, 11:47:58 pm
content: 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??

author: ataradov
author_rank: Super Contributor
timestamp: February 26, 2016, 11:54:16 pm
content: Quote from: SuzyC on February 26, 2016, 11:47:58 pmI 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: February 27, 2016, 12:09:00 am
content: Quote from: ataradov on February 26, 2016, 11:54:16 pmPutting 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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 12:20:21 am
content: 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??

author: andyturk
author_rank: Frequent Contributor
timestamp: February 27, 2016, 12:47:06 am
content: Quote from: SuzyC on February 27, 2016, 12:20:21 amI'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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 12:51:16 am
content: 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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 01:13:19 am
content: 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 DescriptionsThis 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!

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 01:38:19 am
content: 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!

author: dannyf
author_rank: Super Contributor
timestamp: February 27, 2016, 01:49:27 am
content: 'how can anyone attempt to access this register without already addressing this same device address to query this register?'I2c general call.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 01:54:06 am
content: dannyf, that makes sense..but only if there is only one slave I2C device, otherwise every MPU6050 would bus collide?

author: andyturk
author_rank: Frequent Contributor
timestamp: February 27, 2016, 01:55:09 am
content: Quote from: SuzyC on February 27, 2016, 01:13:19 amSleep 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.Code:/* Reset device. */data = BIT_RESET;if (i2c_write(st.hw->addr, st.reg->pwr_mgmt_1, 1, data))return -1;delay_ms(100);/* Wake up chip. */data = 0x00;if (i2c_write(st.hw->addr, st.reg->pwr_mgmt_1, 1, data))return -1;

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 03:37:18 am
content: 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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 27, 2016, 09:44:33 am
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: February 27, 2016, 03:42:37 pm
content: Quote from: SuzyC on February 27, 2016, 09:44:33 amYou can buy accelerometer chips at Frys?

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 28, 2016, 03:20:41 am
content: 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 inputsTRISC4=1; // DATA SDA for MSSP TRIS'd as inputSSPEN=0; // Reset I2C on 16F886 by Disable->Enable sequence of MSSP portSSPADD=0x0B; // Master Mode uses SSPADD to set baud: 400KHz clock speed = 2.5uSec/Cycle observed by scope// SPPADD=((FXtal/400kHz)/4)-1 =11.5SSPCON=0x28; // Set I2C MasterMode bits SSPCON0:3 SSPEN bit5=1 enables |2C, bit3=1 SSPI mode sets I2C Master ModeSSPSTAT=0x80; // SlewRate Control Disabled}

author: dannyf
author_rank: Super Contributor
timestamp: February 28, 2016, 12:15:41 pm
content: 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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 28, 2016, 01:25:13 pm
content: 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 InterfaceI2C 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:

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 28, 2016, 02:08:41 pm
content: Thanks again, dannyf.Clearing up an I2C lockup:void i2cinit(){SSPCON=0; Turn off the Master's I2CTRISC3=1; //Clk pin for I2CTRISC4=1; //SDA pinif((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; //ClkTRISC4=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.5SSPCON=0x28; // Set I2C MasterMode bits0:3 =0x8 SSPEN bit5=1 enables |2C// SSPCON:5=SSPEN=1 sets cbit3,4 as i2c inputs i2c=OnSSPSTAT=0x80; // SlewRate Control DisabledSMP=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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 28, 2016, 07:03:39 pm
content: 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= 0xFFUpon 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 accelsif((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 modeWaitMSSP(); //Wait for ACK from MPUSSPBUF=0x75; //Who_Am_I request reg in MPU-6050WaitMSSP();//Transmission of Who_Am_I request command is complete, MPU must replyRCEN=1;if(!SSPSTATbits.BF)WaitMSSP();ACKDT=1; // Acknowledge data 1: NACK, 0: ACKACKEN=1; // Enable ACK to sendPEN=1; // Stop conditionWaitMSSP();}

author: andyturk
author_rank: Frequent Contributor
timestamp: February 28, 2016, 07:31:19 pm
content: "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.

author: SuzyC
author_rank: Frequent Contributor
timestamp: February 28, 2016, 07:35:57 pm
content: AndyTurk, sorry if I've upset you.The code is not obscure, nor is it lengthy nor uncommented..it deals with I2C.I've explained in detail in posting all my code and how it seems to work and stated the problem.I don't know to get help if I don't show my code before I ask for advice, it is a software coding problem with I2C.The problem is not a hardware problem, because the the MPU responds correctly to the first sent commands.