Hi all,
I've recently returned to an existing project which uses the ICM-20948, and I'm finding that my previous code is no longer working as it once was. I'm using the provided eMD-SmartMotion-ICM20948-1.1.0 library as the basis for my ICM-20948 application, and have largely mimicked the included SAM G55 project.
Per the G55 sequence, after configuring the I2C interface and setting all the necessary configuration, I'm able to successfully read from the WHO_AM_I register. I'm also able to flash the DMP with the DMP firmware; I've verified the sequence externally with an oscilloscope/logic analyser. However, as part of the inv_icm20948_firmware_load() function, there is a 'Verify DMP memory' section which reads back the DMP memory immediately after writing the DMP firmware. The comparison between the source DMP firmware data (and therefore what's just been written to the DMP registers) and a read of the DMP registers is performed via a memcmp() call with a comparison size of 16 bytes.
I'm finding that while the data response (to the read request from my MCU) from the ICM-20948 is correct (again, verified with an oscilloscope), the value held in the 'data_cmp' field is incorrect. It appears that there's some sort of 1 byte offset, where the first byte (of the 16 byte sequence) of DMP data is held in data_cmp[1] instead of data_cmp[0], with data_cmp[0] appearing to be from a previous iteration of the comparison. I've stepped through the entire process line by line with the debugger, and have seen the process occasionally succeed when doing so, but when allowing the application to run without stepping, the memcmp() comparison fails (i.e. returns -1 from the inv_icm20948_firmware_load() function) after either the first or second 16-byte comparison.
If I comment out the 'return -1' and let the application continue, it appears that the application works as expected, as the INT1 line is routinely asserted, indicating that FIFO data is available. I haven't confirmed whether the received FIFO data is correct, I figured I should address this issue first as it may cause similar issues for multi-byte reads from the ICM-20948.
Has anyone else come across a similar issue? I haven't included any code, because my application is so closely aligned to the example provided by TDK. I've included below a capture of the first 16 byte read of the DMP firmware after flashing the DMP. As you can see, the data output by the ICM-20948 is correct (the first 16 bytes of the DMP firmware are 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00), but the memcmp() fails (which is why the SDA and SCL lines return to their idle state rather than reading the second 16 bytes) because the data in data_cmp[] actually looks like 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00.
Any thoughts or guidance would be greatly appreciated!