Regarding the I2C (TWI) clock in nRF5340.

[sst_S.Sakamoto]

Hello,

I am using the following device and development kit:

• Device: NORA-B106-00B (nRF5340)
• nRF Connect SDK: 2.0.2

Currently, to ensure that the connected device receives the correct result of the command in an I2C operation, it requires a 66μs wait time between issuing the command and reading the result.

If you set the I2C (TWI) clock frequency to the standard 100kHz (10μs), the clock (SCL) when reading the results from the device may have a spike shape as shown in the figure below.

This may cause I2C communication to fail.

If you set the clock frequency to 10kHz (100μs), as shown in the figure below, the clock (SCL) does not change significantly when reading the results from the device, and I2C communication seems to be occurring normally.

(The method for setting the clock frequency to 10kHz is based on How can I set a non-standard speed for the I2C bus using the Zephyr? - Nordic Q&A - Nordic DevZone)

There are some points that I would like to confirm based on the above points.

1. Is it acceptable for the clock (SCL) to be shortened due to the influence of the device?
2. In the nRF5340 specifications, there are only 4 patterns for the TWI clock frequency (100kHz, 250kHz, 400kHz, 1MHz), but is there any problem with using 10kHz?

Best regards,

[Simonr]

Hi

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

[sst_S.Sakamoto]

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,

[Simonr]

Hi

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

[sst_S.Sakamoto]

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,

[Simonr]

Hi

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