MPU6050: Incorrect "WHO_AM_I" register value

[nickthiru]

Development platform:
Processor: AMD Ryzen Threadripper 3960X 24-Core Processor 3.79 GHz
System type: 64-bit operating system, x64-based processor
OS: Windows 11

MCU: ESP32 NodeMCU

Sensor: MPU6050

Wiring:
ESP32 <----> MPU6050
3V3 <----------> VCC
GND <---------> GND
GPIO22 <------> SCL
GPIO21 <------> SDA

Hardware driver: $(MODULES)/drivers/mpu6050/mpu6050.js

Steps to reproduce:
1: Given the hardware host has been installed on the MCU and the MPU6050 is powered up
2: In a new mod file, using the mpu6050 driver, create an instance of the Gyro_Accelerometer class
3: Install mod

Expected result: WHO_AM_I register value = 0x68 = 0b01101000 = 104

Actual result: WHO_AM_I register value = 0x72 = 0b01110010 = 114

Description:
As can be seen from screenshot 1 below, in the checkIdentification method on line 60, the value of the WHO_AM_I register is read and stored in gxlID, and this value is 114 (0x72) and not 104 (0x68). On line 62, I have added, for additional clarification, a trace function to display the value of the gxlID in binary, which is output as the first line in the console.

According to the register map document (see reference 3, below), the Power-On-Reset value of Bit6:Bit1 is 110100 for the WHO_AM_I register. By this, I am assuming every time I disconnect and reconnect the power to the MCU, the value is being reset to 0x68. Secondly, the address property of the GyroAccelerometer object is being explicitly set as 0x68 when the parent constructor is called, as seen on line 50. Hence, I am not sure why the actual value of the register is not the expected value.

Initially, before I checked the binary value of gxlID, and using the book (reference 1, below) to guide me, specifically the TMP102 sensor example from Chapter 6. Hardware > Getting the Temperature > TMP102, I thought that I may have to do some bit manipulation operations, given that not all the 8 bits of the register are being used, in order to get the bits in the correct format, like it was done in the TMP102 book example. But later, I realized that the bit operations in TMP102 book example didn't apply to this particular case because here only a single byte is used as the register value whereas the temperature register in the TMP102 used two bytes to store the value.

Screenshots:
1: The error is being thrown on line 63.

2: View of main.js. The new instance of the driver is being created on line 3.

3. Schematic of the MCU that was provided by the seller.
   

References:
1: Hoddie, Peter; Prader, Lizzie. IoT Development for ESP32 and ESP8266 with JavaScript. Apress. Kindle Edition.
2: MPU6050 Datasheet (https://invensense.tdk.com/wp-content/uploads/2015/02/MPU-6000-Datasheet1.pdf)
3: MPU6050 Register Map (https://invensense.tdk.com/wp-content/uploads/2015/02/MPU-6000-Register-Map1.pdf)

[andycarle]

Hi @nickthiru,

Your analysis of the situation seems right to me. It sounds like you have everything connected correctly and the MPU6050 is simply returning an unexpected value when you read the WHO_AM_I register.

I've found some reports online of people purchasing counterfeit/knock-off MPU6050s that identify themselves as 0x72 instead of 0x68. For example, https://www.eevblog.com/forum/projects/counterfeit-mpu6050-chips-from-china/ and https://forum.pjrc.com/threads/67594-not-initialize-mpu6050-Failed-to-find-MPU6050-chip. I'm going to guess this is what's happening to you.

I'd suggest just changing the value of EXPECTED_WHO_AM_I to 0x72 and seeing if everything then works as expected. If not, it may be that the sensor module that you purchased is just not working correctly and does not properly implement the MPU6050 specification.

[Sineos]

FWIW, I have seen (mislabeled) breakout boards that claim to be MPU6050 in fact use any of these:

0x74: mpu-9515
0x73: mpu-9255
0x71: mpu-9250
0x70: mpu-6500
0x68: mpu-6050

From the mpu6050 register perspective they are compatible AFAIK

[nickthiru]

@andycarle @Sineos Thank you for you responses.

As @andycarle suggested, when I changed the EXPECTED_WHO_AM_I value to 0x72, on line 44 of the GyroAccelerometer class (screenshot 1), it worked. I do have some additional questions on the implications of this non-standard behavior and subsequent workaround, but I will have to save it for later. Thanks again for your help!

[phoddie]

@andycarle –  if these are a big family of compatible parts (just different in details), maybe the solution is to have a single driver for all of them. The 6050 driver already seems to do something like that, as it masks the WHO_AM_I value:

gxlID = io.readUint8(REGISTERS.WHO_AM_I) & 0b01111110

That approach would simply things for developers dealing with mislabeled parts.

[andycarle]

Yeah, I'm okay with that. A robust solution that would be in line with Ecma-419's Provenance Sensor Class Pattern would be to:

• attempt to identify the member of this quasi-family of sensors that is actually present
• identify that sensor via the sensor instance's identification property

That would allow apps that care about the specifics to determine what part they're actually talking to while still providing broad compatibility for clones and similar parts.

[phoddie]

That makes good sense to me. The provenance data is a nice refinement.