i2cdevlib icon indicating copy to clipboard operation
i2cdevlib copied to clipboard

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

Open williamesp2015 opened this issue 4 years ago • 2 comments

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

williamesp2015 avatar Sep 14 '21 13:09 williamesp2015

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

ZHomeSlice avatar Sep 27 '21 04:09 ZHomeSlice