Hello, NXP community! : )
I have a custom board featuring an MMA8652 accel, hooked up to an RPi4. The issue is that when I try to read *any* register, the value will always be maxed-out, i.e 0xFF. My test procedure is to set CTRL_REG1 to 0b1 in order to start the device, and then ask for WHO_AM_I (or basically, any register). It doesn't matter if I allow some time after setting CTRL_REG1, whether it is 1us, 1ms, or... 100ms.
The thing that is puzzling me the most, is that this only happens with C++! I tried the same procedure in Python and I get back normal values, i.e 0b1001010 for WHO_AM_I.
I have though that my I2C wrapper may be causing the issue, but the thing is that it works fine for other I2C devices on the same bus.
I have also tried using a 2nd board, but the issue persists, so it probably isn't a bad or damaged copy of the IC, but rather something wrong in they way I operate it.
Edit: I also attached a scope image, but I only see 2 operations! Shouldn't there be a 3rd (reply from the IC)?
Solved! Go to Solution.
Hello @SpyrosRallis,
First off, I do apologize for this slightly delayed response.
Looking at your scope image, there is the Stop condition between the second and third byte which is incorrect.
You need to change the source code in C++ so that SDA transitiones to high before the SCL goes high in order to eliminate this Stop condition.
The following picture illustrates the read of the WHO_AM_I register (0x0D). As you can notice, there is no Stop condition between the second (0x0D) and third (0x3B) byte.
Best regards,
Tomas
Hello @SpyrosRallis,
First off, I do apologize for this slightly delayed response.
Looking at your scope image, there is the Stop condition between the second and third byte which is incorrect.
You need to change the source code in C++ so that SDA transitiones to high before the SCL goes high in order to eliminate this Stop condition.
The following picture illustrates the read of the WHO_AM_I register (0x0D). As you can notice, there is no Stop condition between the second (0x0D) and third (0x3B) byte.
Best regards,
Tomas
Nice catch, @TomasVaverka! Thank you!
Indeed the issue was with the way I was handling the I2C bus. I fixed my wrapper, and, ta-da, now I can communicate with the MM8652 without issues!