Can't write more than 16 bytes using i2c_transfer() on nRF5340 DK

[tozz88]

I am developing a device that reads/writes data blocks to a proprietary sensor over i2c. There is a 2 byte hdr to the data block message so I was using i2c_transfer() to create a 2 msg transaction to write the header, then write the data block with no start/stop in between. This works great for data blocks that are les than or equal to 14 bytes. But anything larger than that I get an error -28 (ENOSPC). Is there a way to increase this limitation? Is this a kernel compile option somewhere? Or is there a format trick I don't know of. 

Here is my code:

  struct i2c_msg msgs[2];

  msgs[0].flags = I2C_MSG_WRITE;

  msgs[0].buf = addr_phase;

  msgs[0].len = 2U;

  msgs[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  msgs[1].buf = p_out_val;

  msgs[1].len = (unsigned) len;

  int error = i2c_transfer(i2c_dev, msgs, 2, This._i2c_addr);

  if (error != 0) {

    ERR_PRINTF("Send failed error=%d\n", error);

    goto err;

  }

I'm using version 2.4.2 of the SDK

I don't have any problem reading data blocks greater than 16 bytes, just writing them. For now, I'm using i2c_write() and copy the header and data block to a single buffer and i2c_write seems to be able to write any size I give it. But I'd love to get rid of the copy and extra buffer I have to allocate.

Thanks,

[Kenneth]

Hello,

It looks to be a few things that can cause this:
if statement: https://github.com/zephyrproject-rtos/zephyr/blob/zephyr-v3.5.0/drivers/i2c/i2c_nrfx_twim.c#L92 
error code: https://github.com/zephyrproject-rtos/zephyr/blob/zephyr-v3.5.0/drivers/i2c/i2c_nrfx_twim.c#L103 

Not entirely sure which is kicking in here. Hopefully you can set a breakpoint here to find exactly what is causing that error code.

Kenneth

[tozz88]

Great. Thanks for your help. I already have an overlay file so adding the following to my &i2c1 entry did the trick:

    zephyr,concat-buf-size = <514>;

The code from my original post works for arbitrary sizes up to 512 bytes.

However, I wanted to look into this more as I may be simply delaying the copy step to the driver's code if the buffer I supply isn't accessible to DMA.  How do I allocate my buffers to ensure they are accessible to the DMA engine?

thanks.

[Kenneth]

Glad to hear the problem is solved.

Regarding the "DMA" it simply means that the buffer need to be in RAM, not code flash.

Kenneth

[tozz88]

Great. this answers all my questions. So this ticket is closed in my mind. I'm new to this page so let me know if there is something I'm supposed to do to close this out.

thanks for your help 

BobT