How to transfer large amounts of data over I2C

RE: How to transfer large amounts of data over I2C

tekochip — Tue, 19 Jul 2022 21:49:32 GMT

I had gotten a confirmation from ST and got mine running with smaller blocks yesterday. With smaller blocks you will not need to alter Zephyr's I2C timeout, but the stack usage is still a real issue when running the demos. It's probably best to make the device and results variables static.

RE: How to transfer large amounts of data over I2C

jspiller — Tue, 19 Jul 2022 17:50:43 GMT

Yes I struggled with this as well mostly because it was poorly documented in the datasheet for the sensor. You can break it up you just need to increment the register address accordingly to every transfer. I have it working with zephyr so let me know if need any help.

-Jacob

RE: How to transfer large amounts of data over I2C

tekochip — Mon, 18 Jul 2022 22:12:25 GMT

I stand corrected, you CAN break the transfer into smaller blocks and the firmware WILL load properly.

RE: How to transfer large amounts of data over I2C

tekochip — Sat, 16 Jul 2022 13:45:18 GMT

Oh, one last thing. The Zephyr I2C driver has a timeout that you'll need to extend. I set mine for 1000ms. Without the change the driver will kill the transfer after 500ms.

#define I2C_TRANSFER_TIMEOUT_MSEC K_MSEC(1000)

RE: How to transfer large amounts of data over I2C

tekochip — Fri, 15 Jul 2022 20:28:53 GMT

Don't be tempted to break the transfer into smaller blocks, because the ST sensor will not run properly if you do. The main trick is that the DMA cannot handle transfers from FLASH, you must first copy the transfer to RAM. The next trick is that this will result in a stack size that is far too large, so you need to make the buffer static:

uint8_t WrMulti(
VL53L5CX_Platform *p_platform,
uint16_t RegisterAdress,
uint8_t *p_values,
uint32_t size)
{

uint8_t status=VL53L5CX_STATUS_OK;
static uint8_t localBuf[0x8002];

localBuf[0] = RegisterAdress/256;
localBuf[1] = RegisterAdress;
memcpy(&localBuf[2], p_values, size);

/* Need to be implemented by customer. This function returns 0 if OK */
status |= i2c_write(p_platform->i2c, localBuf, size+2, p_platform->address);

return status;
}

Lastly, the examples from ST often require too much stack space. This will frustrate you because the error will not occur when the offending function is started, it will fail when you attempt to use a variable inside the function, or called from that function. You need to make their local variables static, so in example1(), make these static:

static VL53L5CX_Configuration Dev ; /* Sensor configuration */

static VL53L5CX_ResultsData Results; /* Results data from VL53L5CX */

I also have this running with Nordic's SDK. That requires some coding outside of Nordic's API because the function only has an 8-bit size, but the driver can handle 16 bits.

uint8_t WrMulti(
VL53L5CX_Platform *p_platform,
uint16_t RegisterAdress,
uint8_t *p_values,
uint32_t size)
{
int32_t status_int;
uint8_t status = VL53L5CX_STATUS_OK;
uint8_t localBuf[size + 2];

/* Need to be implemented by customer. This function returns 0 if OK */

/*Copy from FLASH into RAM, as required by EasyDMA, and create address in first two bytes*/
memcpy(&localBuf[2], p_values, size);
localBuf[0] = RegisterAdress / 256;
localBuf[1] = RegisterAdress;

/*Wait for any current operations*/
while (nrf_drv_twi_is_busy(p_platform->i2c));

/*Create TWIM descriptor to get larger than 8 bit size, must be constant*/
nrfx_twim_xfer_desc_t const twim_xfer_desc =
{
.type = (nrfx_twim_xfer_type_t)NRF_DRV_TWI_XFER_TX,
.address = p_platform->address,
.primary_length = size + 2,
.p_primary_buf = localBuf,
};
status = nrfx_twim_xfer(&p_platform->i2c->u.twim, &twim_xfer_desc, 0);

while (nrf_drv_twi_is_busy(p_platform->i2c));

return status;
}

I was frustrated for days by this, so I hope I've been able to help somebody else in trouble.

RE: How to transfer large amounts of data over I2C

Kenneth — Wed, 25 May 2022 13:02:04 GMT

I suggest to get a logic analyzer trace and see the data transferred on the twi bus, then you can also see the start, and re-start bits, and the device address and if the register address are incremented as expected. Alternatively you need to write it on byte level using direct address access, something like this:

https://devzone.nordicsemi.com/f/nordic-q-a/28367/i2c-driver-from-scratch-using-direct-register-access

Kenneth