This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

i2c_burst_read and i2c_burst_write not working on NRF5340

Greetings!


we are using nrf5340dk to communicate with a Nucleo shield that has LIS2DW12 accelerometer on it (shield is X-nucleo-IKS01A3). We have a problem communicating with the accelerometer as we are not getting correct sensor values.

Our setup:

Function sensor_channel_get is always returning only zero values and we can confirm this is true by the logic analyzer scans.

After some search on the Internet we found a similar issue on the DevZone here: https://devzone.nordicsemi.com/f/nordic-q-a/54451/nrf5340-support-in-nrf-connect-sdk-and-zephyr

We managed to fix the problem by going into i2c driver files for LIS2DW12 (ncs/zephyr/drivers/sensor/lis2dw12/lis2dw12_i2c.c) and replacing i2c burst functions with normal i2c functions.

Below you can see the part of the file that we changed:

static int lis2dw12_i2c_read(struct lis2dw12_data *data, uint8_t reg_addr,
				 uint8_t *value, uint16_t len)
{
	//return i2c_burst_read(data->bus, lis2dw12_i2c_slave_addr,
			      //reg_addr, value, len);

    return i2c_write_read(data->bus, lis2dw12_i2c_slave_addr, &reg_addr, 1, value, len);
}

static int lis2dw12_i2c_write(struct lis2dw12_data *data, uint8_t reg_addr,
				  uint8_t *value, uint16_t len)
{
	//return i2c_burst_write(data->bus, lis2dw12_i2c_slave_addr,
			       //reg_addr, value, len);

    uint8_t temp_buf[1000] = {0};
    temp_buf[0] = reg_addr;
    memcpy(&temp_buf[1], data, len);

    return i2c_write(data->bus, temp_buf, len+1, lis2dw12_i2c_slave_addr);
}


With above change we can communicate with the sensor. What can be done to fix the i2c burst functions, as we obviously can not use this workaround in production?

Best regards,
Marko

Parents
  • Hi, Marko!

    Thanks for reaching out. Can you confirm that there is no activity at all when checking with the logic analyzer? Some sensors are not compatible with the _burst_write() from the nRF5340 as the TWI implementation generates repeated-starts between payloads. Though this should not affect _burst_read.

    I will check with the developers on this!

    Best regards,
    Carl Richard

  • Hi Carl!

    We can see activity on the logic analyzer. I should mention that LIS2DW12 is detected successfully in the init function, even with the burst i2c functions. We know that because device_get_binding function succeeds.

    Problems appear later when MCU is fetching raw accelerometer data during the sampling sequence (while sensor_channel_get is executing). We can see valid i2c packets, but they all contain 0x00.

    I am guessing that accelerometer does not get configured correctly in the init function due to burst i2c function, or maybe at the start of the sampling sequence.

    This sounds like the problem you mention, maybe the sensor is not compatible with i2c burst functions.

    Best Regards,
    Marko

Reply
  • Hi Carl!

    We can see activity on the logic analyzer. I should mention that LIS2DW12 is detected successfully in the init function, even with the burst i2c functions. We know that because device_get_binding function succeeds.

    Problems appear later when MCU is fetching raw accelerometer data during the sampling sequence (while sensor_channel_get is executing). We can see valid i2c packets, but they all contain 0x00.

    I am guessing that accelerometer does not get configured correctly in the init function due to burst i2c function, or maybe at the start of the sampling sequence.

    This sounds like the problem you mention, maybe the sensor is not compatible with i2c burst functions.

    Best Regards,
    Marko

Children
No Data
Related