TWI inconsistent read of slave device address location in nRF5 SDK 15.2

RE: TWI inconsistent read of slave device address location in nRF5 SDK 15.2

BendaEng — Wed, 28 Aug 2019 11:17:49 GMT

Hi Nikhilesh,

Apologies on the late reply, I didn't see this response. I used the following TWI (I2C) driver base code set when I began figuring out how to use the ICM 20948 with the nRF52832.

https://github.com/jrowberg/i2cdevlib/blob/master/nRF51/I2CDev/I2Cdev.cpp

On a separate note, I found the ICM very difficult to integrate with and only ended up using the absolute orientation output (never tap detection).

I also got a similar error when writing the DMP firmware. See the following for some potential fixes.

https://www.invensense.com/developers/forums/topic/icm-20948-driver-firmware-upload-fails/

https://www.invensense.com/developers/forums/topic/icm-20948-dmp/

Hope this helps!

RE: TWI inconsistent read of slave device address location in nRF5 SDK 15.2

asmita_patil — Thu, 22 Aug 2019 06:29:51 GMT

have you solved your problem

RE: TWI inconsistent read of slave device address location in nRF5 SDK 15.2

nikhilesh — Wed, 24 Apr 2019 09:02:15 GMT

Hey BendaEng,

I am using nrf52840 with SDK 15.3. I see a lot of twi drivers and its confusing which one to use. I want to read the ICM 20948 sensor data in burst mode for my application. In the second step I want to use the tap detection in DMP, so i have to write the DMP firmware into the ICM. But my twi drivers seem to constantly return with err_code 0x11 or 0x03 errors. Please let me know which is the best twi drivers for ICM. Thanks and regards.

RE: TWI inconsistent read of slave device address location in nRF5 SDK 15.2

BendaEng — Thu, 10 Jan 2019 22:11:54 GMT

Hi,

Thanks for the reply. Unfortunately that didn't end up working, but I did figure the issue out. I'm not sure if this is consistent across all I2C slave devices, but in order to read back the address over and over the pointer address needed to be set prior to reading again. The device (ICM-20948) may not keep that register information after a read request due to volatile memory or something.

This was the modifications that I made which worked.

void ICM20948_set_mode(void)
{
    ret_code_t err_code;

    /* Writing to pointer byte. */
    uint8_t reg_addr = 0x00; //WHO_AM_I address same as define on top.
    m_xfer_done = false;
    err_code = nrf_drv_twi_tx(&m_twi, ICM20948_ADDR, &reg_addr, 1, false);
    APP_ERROR_CHECK(err_code);
    while (m_xfer_done == false);
}

static void read_sensor_data()
{
    ret_code_t err_code;
    m_xfer_done = false;
    uint8_t reg_addr = WHO_AM_I; //WHO_AM_I address same as define on top.
    //uint8_t reg_addr = ACCEL_XOUT_L; //Gyro x axis lowest 8 bits of data

    /* Writing to pointer byte. */
      err_code = nrf_drv_twi_tx(&m_twi, ICM20948_ADDR, &reg_addr, sizeof(reg_addr), false);
    APP_ERROR_CHECK(err_code);

    /* Read 1 byte from the specified address */
    while(m_xfer_done == false);
      err_code = nrf_drv_twi_rx(&m_twi, ICM20948_ADDR, &m_sample, sizeof(m_sample));
    APP_ERROR_CHECK(err_code);
}

RE: TWI inconsistent read of slave device address location in nRF5 SDK 15.2

Simon — Thu, 10 Jan 2019 10:27:00 GMT

Typically for I2C devices, in order to read from a specific register, you would need to write the register address to the device first. However, I would recommend you to read the datasheet for the I2C device you have, as the approach may vary. Down below I have attached the code to run if your device works in the typical manner.

First you must write the register address (0x00) to the device.

uint8_t reg_addr = 0x00;

m_xfer_done = false;
err_code = nrf_drv_twi_tx(&m_twi, LM75B_ADDR, &reg_addr, 1, false);
APP_ERROR_CHECK(err_code);
while (m_xfer_done == false);

I can not see that you have done this.

Next up, you can read the register as followed:

static uint8_t m_sample;

.
.
.

m_xfer_done = false;
// Read 1 byte from the specified address
ret_code_t err_code = nrf_drv_twi_rx(&m_twi, LM75B_ADDR, &m_sample, sizeof(m_sample));
APP_ERROR_CHECK(err_code);

Best regards,

Simon