MPU6050_DMP6_using_DMP_V6.12 With CHIPID=0xC after enable DMP never change Interrupt pin status

[williamesp2015]

I'm using MPU6050_DMP6_using_DMP_V6.12 example with ESP32. With a module with CHIPDI=0x34, the interrupt pin gets low for49 uec at 200Hz but with a another chip with CHIPID=0xC, AD0=LOW never change Interrupt pin and always is High. This chip never exit from mpu.CalibrateAccel(6) and if I don't do calibration still DMP gets enabled but interrupt pin always high. I changed getDeviceID() to return true with 0x34 and 0xC. uint8_t MPU6050::getDeviceID() { I2Cdev::readBits(devAddr, MPU6050_RA_WHO_AM_I, MPU6050_WHO_AM_I_BIT, MPU6050_WHO_AM_I_LENGTH, buffer); Serial.print("Real CHIP ID:0x"); Serial.println(buffer[0],HEX);//52=0x34 12=0xC` if ((buffer[0] == 0x34) || (buffer[0]==0xC)) //MPU5060 Ic Scan 0x68 buffer[0]=0x34; return buffer[0]; } I tested MPU6050_6Axis_MotionApps20.h and I found stop in the Calibration process so I ignored calibration and then Interrupt pin started working at 500Hz!!!!!. I'm sure there are problem with calibration process and some boards can not work with V6.12

[ZHomeSlice]

The calibration process pulls raw rate data from the mpu and uses that to zero out the gyro and accelerometer readings so the DMP process hasn't started at that time.

The cause of the calibration failure is likely caused by: We have had mention that the Who am I value is reading high when used with the mpu6050 It has been mentioned that the mpu6050 reads 0x68 when it should read 0x34 this would cause the calibration routine to try to write the calibration offsets for the accelerometer to a bad memory address failing the calibration. I'm hoping to find the cause of this.

"500Hz!!!!!" The interrupt pin double pings and I have not discovered a solution to this. one interrupt is good for the FIFO buffer Packet ready and the alternate one is for something else the mpu thinks we need to know about. No clue how to stop this....

When the buffer is empty when the alternate interrupt triggers mpu.dmpGetCurrentFIFOPacket(fifoBuffer) returns false as quickly as possible allowing the processor to do other things.

Z

[gentunian]

@ZHomeSlice I just wanted to clarify 1 thing:

It has been mentioned that the mpu6050 reads 0x68 when it should read 0x34

MPU6050 WHO_AM_I (0x75) register reads 0x68 by default when you read the full byte. When using this lib, that register is read appropriately as datasheet says, from bit6 to bit 1. Bit 0 and bit 7 are reserved and should be 0.

For some reason I have a chip where the registerWHO_AM_I byte is set to 0x98 (that is, 0xC if you read bit6-bit1). I found the same solution by myself and worked the first time but now for some reason it's stuck on that method too.

EDIT: one thing I'm worried about this chip is that based on the documentation those bits should be hard-coded as 0, but the value 0xC is the byte 0x98 =b10011000 (bit 7 is set to 1)