Regarding the I2C (TWI) clock in nRF5340.

RE: Regarding the I2C (TWI) clock in nRF5340.

sst_S.Sakamoto — Thu, 27 Mar 2025 00:42:02 GMT

Hello Simon,

Sorry for the late reply, and thank you for all your suggestions.
After careful consideration, we have decided not to use I2C communication for writing data to the slave in this particular setup. Instead, we will write the data from a dedicated software application, thereby avoiding potential clock-stretching issues. If we need to rely on I2C in future scenarios, we will certainly keep in mind your advice about adding sufficient wait times. Thank you again for your support.

Best regards,

RE: Regarding the I2C (TWI) clock in nRF5340.

Simonr — Thu, 21 Nov 2024 08:25:58 GMT

Correct, if you set a wait time after sending data so that the slave can respond, the master will never have to stretch the clock, and then this errata won't come into the picture here.

Best regards,

Simon

RE: Regarding the I2C (TWI) clock in nRF5340.

sst_S.Sakamoto — Wed, 20 Nov 2024 08:02:54 GMT

Hello Simon,

Thank you for providing the sample.

I think the problem is that after the slave receives data via I2C and performs clock stretching (66 μs), the first clock pulse from the master becomes longer or shorter, which can cause an error when the slave responds.

This is also described in the errata document at the URL below.

https://docs.nordicsemi.com/bundle/errata_nRF5340_EngA/page/ERR/nRF5340/EngineeringA/latest/anomaly_340_37.html#anomaly_340_37

Therefore, by setting a wait time between when the master sends data and when the slave responds, I hope that a normal clock pulse will be generated from the master when the slave responds.

Is the above thinking correct?

Best regards,

RE: Regarding the I2C (TWI) clock in nRF5340.

Simonr — Tue, 19 Nov 2024 14:09:33 GMT

I think the i2c_write() from the Zephyr API is the way to go here. Adding a wait function should be fine AFAIK, what exactly are you having trouble with? We have some TWIM/TWIS samples available here that should be usable: https://github.com/zephyrproject-rtos/hal_nordic/tree/master/nrfx/samples/src/nrfx_twim_twis

Best regards,

Simon

RE: Regarding the I2C (TWI) clock in nRF5340.

sst_S.Sakamoto — Tue, 19 Nov 2024 06:57:21 GMT

Hello Simon,

As you noted, the nRF5340 is the master device between the two.

Currently, I am using the i2c_write() function of Zephyr API to send several bytes of data to the slave device, but is it possible to add a wait function that waits for a response from the slave side after each byte is sent?

If you have any example programs, I would appreciate it if you could show me.

Best regards,

RE: Regarding the I2C (TWI) clock in nRF5340.

Simonr — Mon, 18 Nov 2024 07:37:45 GMT

I assume here that the nRF5340 is the master device between the two, and if so I'd say you should add the wait function here. The wait function should be added after sending a TWI event where you wait for a "transmit complete" call or similar before you send a new message/event.

Best regards,

Simon

RE: Regarding the I2C (TWI) clock in nRF5340.

sst_S.Sakamoto — Fri, 15 Nov 2024 10:24:14 GMT

Hello Simon,

Thank you for your reply.

The following devices are connected using I2C:
BQ27Z561-R2 (Made by Texas Instruments Inc.)

If I2C communication fails, a NAK will be returned during data transfer.

I would like to confirm, which one should I add the wait function to, nRF5340 or BQ27Z561-R2?
If I need to add a wait function to the nRF5340, could you please tell me how to do it?

Best regards,

RE: Regarding the I2C (TWI) clock in nRF5340.

Simonr — Wed, 13 Nov 2024 13:37:18 GMT

1. What is the connected device that requires this wait period of 66µs here? Can you share some details on what exactly happens when the I2C communication fails here. Do you see jumbled data, no data at all, or what? My initial thought is that you should add a wait function here so you're sure the device is ready to receive more data and not interrupt the 66µs periods. The failures is a good indication that it's not okay to shorten these.

2. It should not be a problem using lower frequencies AFAIK. It's mainly that the Zephyr API isn't made for other frequencies.

Best regards,

Simon