i2c_burst_write difference nrf52 and nrf91 series

[Maaike]

Dear All,

I'm using Zephyr to configure a nrf9160 as I2C master and the OPT3002 light sensor as I2C slave.
The OPT3002 has a 16bit configuration register, which I need to write to.
For this I use i2c_burst_write(), which works fine on the nrf52 series (nrf52840 & nrf52833), with I2C_0. I can write to the register and read correct light intensity values.
However, on the nrf9160, with I2C_2, I can read the registers fine, but not write to them properly. This means I cannot get the sensor out of power down mode and therefore not read any sensor values.

Now I have seen this issue with burst_write and I should probably use another i2c write function.
However, I would like to know what the difference is between the nrf52 and nrf9160, that causes this issue to only happen on the nrf9160.

Do you have any idea what causes this difference?

Kind regards,
Maaike

[Simon]

Could you try to attach a logic analyzer to the I2C pins and see if the output differs between the nRF52 and the nRF91 when you use the i2c_burst_write function. That would be interesting to see. I'll soon take christmas vacation for some days, so I don't have time to do it myself before then.

Best regards,

Simon

[Maaike]

I was able to check it with the logic analyser and there is a difference between the nrf52 and nrf91 in writing to the configuration register. In the reading of the ID register there is no difference.

Some addresses and values:
I2C address read =  0x44
I2C address write = 0xC4
MANUFACTURER_ID register address =  0x7E
CONFIGURATION register address = 0x01
MANUFACTURER_ID = 0x5449
Configuration value to write = 0b1100011xxxx01000, where x are read only fields.
Expected configuration value to read = 0xC688  (0b1100011010001000)


Below the read ID register and the write and read to the configuration register of both the nrf91 and nrf52 are posted.

nrf91 read ID register


nrf52 read ID register


nrf91 write read configuration register


nrf52 write read configuration register

[Simon]

Sorry for the delay on this. I'm back at work and will look into this case.

Best regards,

Simon

[Simon]

Have you gotten any progress on this? Pull request 25867 may be helpful, it adds an option to concat smaller payloads.

Best regards,

Simon

[Maaike]

As expected using i2c_write instead of i2c_burst_write solved my problem.
I do still wonder why i2c_burst_write does not work on the nRF91 and it does work on the nRF52.

Kind regards,
Maaike

[Simon]

I looked into this, and got a better overview of what's going on.

When writing to a register, the following should appear on the SDA line:

• Send start command
• Send 7 bit start address + write bit
• Send register address
• Send data to be written to the register

You are trying to write 0xC688 to the configuration register with address 0x01 of an I2C slave with address 0x88.

What the nRF52840 does, based on the trace

• Send start command
• Send 7 bit start address (0x88) + write bit
• Send register address (0x01)
• Send data to be written to the register (0xC6 + 0x08)

What the nRF9160 does, based on the trace

• Send start command
• Send 7 bit start address (0x88) + write bit
• Send register address (0x01)
• Send 7 bit start address (0x88) + write bit
  • This is where it differs from the nrf52, it splits the message up in two pieces
• Send register address (0xC6)
• Send data to be written to the register (0xC6 + 0x08)
  • This is why it fails, because this is not register 0x01
• Send data (0x08)

I suspect the issue is that for the nRF9160, the function i2c_nrfx_twim_transfer() does not concatenate the messages for some reason, and calls nrfx_twim_xfer() two times. I'm not sure why if this is the case.

Could you try to do some debugging in the function  i2c_nrfx_twim_transfer(), both when the nRF52840 is used, as well as the nRF9160. Check if nrfx_twim_xfer() is called one or two times.

By the way if  "nordic,nrf-twim" is set in the dts/overlay file, i2c_nrfx_twim.c will be used, and if  "nordic,nrf-twi" is set, i2c_nrfx_twi.c will be used

Best regards,

Simon