I2C clock frequency problem

RE: I2C clock frequency problem

dbouchie — Tue, 06 Sep 2022 21:50:24 GMT

I think I have the answer see my reply here: TWI speed not correct

"I've had a similar issue. I think I found the source of the issue: the chip's TWIM clock stretching. I'm unfamilar of how the internal chip circuitry works, but I noticed when I added a longer wire to my circuit, all of a sudden the clock rate went from 250kHZ to 125kHz (with the master frequency set to 250kHz). Just by adding a wire! The additional capacitance must have some effect on the clock stretching circuit.

Just speculating, but the theory would be the slow rise times fool the TWIM into thinking a peripheral is clock stretching, so the TWI skips a clock cycle until the clock line rises back again.

For workarounds, try using a larger pull-up resistor."

RE: I2C clock frequency problem

awneil — Tue, 02 Jul 2019 09:06:43 GMT

But we didn't know that, and we can't see the results - can we?

RE: I2C clock frequency problem

Manjunath K S — Tue, 02 Jul 2019 08:49:26 GMT

hi awneil certainly , i have tested in oscilloscope before too , which also showed the same result as logic analyzer, in that i didn't check the parameters such as rise time and etc., and it was done on pin 27 & 26 as a reference , i will redo it and will check again.

Thank You

RE: I2C clock frequency problem

awneil — Tue, 02 Jul 2019 07:22:58 GMT

As always - there's no point try to suggest cures before we know what the actual problem is!

Scoping the signal is certainly not something that is "not required" - it should have been one of the very first things you did!

RE: I2C clock frequency problem

Manjunath K S — Tue, 02 Jul 2019 07:16:57 GMT

Thanks awneil i know that i only have to do that , just asking your suggestion regarding that before i do anything which is not required.

RE: I2C clock frequency problem

awneil — Tue, 02 Jul 2019 07:13:44 GMT

[quote userid="78194" url="~/f/nordic-q-a/48910/i2c-clock-frequency-problem/195797"]will pulling up the line help[/quote]

Who knows?

It's your hardware - you need to do the debugging!

Again, you need to use an oscilloscope to see what's actually happening in your hardware.

Nobody else can do that for you.

Your oscilloscope will show you if the rise time is too slow - ie, your pullups are not strong enough.

RE: I2C clock frequency problem

Manjunath K S — Tue, 02 Jul 2019 06:35:00 GMT

thanks haakonsh and awneil , i will check with them and let you know their response,

tell me one more thing will pulling up the line help.

RE: I2C clock frequency problem

awneil — Mon, 01 Jul 2019 15:04:49 GMT

[quote userid="13562" url="~/f/nordic-q-a/48910/i2c-clock-frequency-problem/195727"]some form of loading on the I2C lines[/quote]

Which reminds me of the question asked several times early on in this thread - but I don't recall it ever being answered:

[quote userid="13562" url="~/f/nordic-q-a/48910/i2c-clock-frequency-problem/194311"]Why have you enabled pulldowns on your IO pins[/quote]

Pulling-down the line is exactly what a Slave would do to stretch the clock ...

RE: I2C clock frequency problem

haakonsh — Mon, 01 Jul 2019 14:56:58 GMT

[quote user="awneil"]The LIS3DSH is an ST Product - so you probably need to go back to ST to ask them what might cause their product to behave like this.[/quote]

We sit on one-half of the resources needed to solve this issue, ST sits on the other. You need to ask them for inputs as well, as their I2C slave seems to be stretching the clock.

It could still be the nRF52832 that causes the issue as it is currently set to use clk of 410kHz. Try setting the FREQUENCY register to 0x06400000 prior to starting the I2C bus.

[quote user="awneil"]Have you looked at the clock with an oscilloscope - to see if there are any weird analogue effects going on?[/quote]

What appears to be clock stretching might be some "weird analogue effects", some form of loading on the I2C lines.

You can also try enabling high drive strength on the GPIOs.

RE: I2C clock frequency problem

awneil — Mon, 01 Jul 2019 14:31:11 GMT

So far, I think you've only shown logic analyser (ie, digital) traces ?

Have you looked at the clock with an oscilloscope - to see if there are any weird analogue effects going on?

eg, if you have extremely long rise times ... ?

RE: I2C clock frequency problem

awneil — Mon, 01 Jul 2019 13:55:03 GMT

Indeed - and you can refer them to this thread.

RE: I2C clock frequency problem

Manjunath K S — Mon, 01 Jul 2019 13:53:00 GMT

if it is working in other 3 boards and not in Nordic , they will surely ask me to check with you people , to ask whether there is any problem with code or not.

RE: I2C clock frequency problem

awneil — Mon, 01 Jul 2019 12:43:27 GMT

The LIS3DSH is an ST Product - so you probably need to go back to ST to ask them what might cause their product to behave like this.

RE: I2C clock frequency problem

Manjunath K S — Mon, 01 Jul 2019 12:09:39 GMT

Thanks haakonsh , but same slave i am using withother development kit /microcontroller eg: Renesas S5D9 and stm32eval board , also raspberry pi , while it is working in all those environment for same code and configuration giving expected clock frequency in the logic analyzer , that's the reason i came to you people.

RE: I2C clock frequency problem

haakonsh — Mon, 01 Jul 2019 11:17:04 GMT

The GPIO expander is connected to P0.13 - P0.20: I/O expander for buttons and LEDs. And I believe they should work at 400kHzthrough the IO expander.

[quote user="awneil"]Does your peripheral default to 200kHz, and need to be configured to change to 400 ... ?[/quote]

I've not found anything in the LIS3DSH's specs that hints to a configurable I2C clock.

Paraphrased from its spec, "The LIS3DSH supports fast I2C mode with clock speeds up to 400kHz", but, it does not say anywhere in its specification that its I2C slave runs at 400kHz, rather it supports 'fast mode I2C'.

What you're seeing on SCL is the I2C slave clock stretching down to 200kHz.

This is most likely the expected behavior of this device.

RE: I2C clock frequency problem

Manjunath K S — Mon, 01 Jul 2019 10:30:23 GMT

By default lis3dsh peripheral will support 400K fast mode, it was working in other development kit(also clock in other dk was also reflected) like renesas and stm eval board.

that's y i didn't get to know the actual problem and asking for your help.

RE: I2C clock frequency problem

awneil — Mon, 01 Jul 2019 08:59:08 GMT

But your test demonstrates that the issue is not to do with your software configuration, or an SDK bug, in the nRF chip?

Does your peripheral default to 200kHz, and need to be configured to change to 400 ... ?

RE: I2C clock frequency problem

Manjunath K S — Mon, 01 Jul 2019 08:51:20 GMT

tqs awneil but peripheral supports 400K clock

RE: I2C clock frequency problem

awneil — Mon, 01 Jul 2019 07:56:37 GMT

It is a standard feature of the I2C bus that it operates at the speed of the slowest attached peripheral

RE: I2C clock frequency problem

Manjunath K S — Mon, 01 Jul 2019 06:49:46 GMT

without slave device about 400 k clock i am able to see, when i connect a slave device its dropping to 200 k

RE: I2C clock frequency problem

Manjunath K S — Mon, 01 Jul 2019 05:47:21 GMT

awneil yes it is from nrf52832 (pca10040)

Offline haakonsh : presently 26 & 27 are used which is by default u have said in the documents, is there any problem with those pins, any way i will change and check and will let you know the results.

RE: I2C clock frequency problem

haakonsh — Fri, 28 Jun 2019 14:22:26 GMT

Yeah, that's true. Try pin 11 for the clock signal and 12 for the data line.

RE: I2C clock frequency problem

awneil — Fri, 28 Jun 2019 10:43:18 GMT

Manjunath K S - and that's on the Nordic nRF52832 DK (pca10040) ?

haakonsh - the nRF52832 DK has an I2C IO expander, doesn't it ... ?

RE: I2C clock frequency problem

Manjunath K S — Fri, 28 Jun 2019 10:41:08 GMT

sorry i couldn't take the frequency info while taking snapshot , clock was still 200, if u want i can retake and send

RE: I2C clock frequency problem

Manjunath K S — Fri, 28 Jun 2019 10:33:20 GMT

/**
 * Copyright (c) 2016 - 2018, Nordic Semiconductor ASA
 * 
 * All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 * 
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 * 
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 * 
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 * 
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 * 
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 * 
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 * 
 */
/** @file
 * @defgroup tw_scanner main.c
 * @{
 * @ingroup nrf_twi_example
 * @brief TWI Sensor Example main file.
 *
 * This file contains the source code for a sample application using TWI.
 *
 */

#include <stdio.h>
#include "boards.h"
#include "app_util_platform.h"
#include "app_error.h"
#include "nrf_drv_twi.h"



#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

/* TWI instance ID. */
#if TWI0_ENABLED
#define TWI_INSTANCE_ID     0
#elif TWI1_ENABLED
#define TWI_INSTANCE_ID     1
#endif

 /* Number of possible TWI addresses. */
 #define TWI_ADDRESSES      127

/* TWI instance. */
static const nrf_drv_twi_t m_twi = NRF_DRV_TWI_INSTANCE(TWI_INSTANCE_ID);


/**
 * @brief TWI initialization.
 */
void twi_init (void)
{
    ret_code_t err_code;

    const nrf_drv_twi_config_t twi_config = {
       .scl                = ARDUINO_SCL_PIN,
       .sda                = ARDUINO_SDA_PIN,
       .frequency          = NRF_DRV_TWI_FREQ_400K,
       .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
       .clear_bus_init     = false
    };

    err_code = nrf_drv_twi_init(&m_twi, &twi_config, NULL, NULL);
    APP_ERROR_CHECK(err_code);

    nrf_drv_twi_enable(&m_twi);
}


/**
 * @brief Function for main application entry.
 */
int main(void)

{
    ret_code_t err_code;
    uint8_t address;
    uint8_t sample_data;
    bool detected_device = false;

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    NRF_LOG_INFO("TWI scanner started.");
    NRF_LOG_FLUSH();
    twi_init();
    while(1)
    {

    for (address = 1; address <= TWI_ADDRESSES; address++)
    {
        err_code = nrf_drv_twi_rx(&m_twi, address, &sample_data, sizeof(sample_data));
        
        if (err_code == NRF_SUCCESS)
        {
            detected_device = true;
            NRF_LOG_INFO("TWI device detected at address 0x%x.", address);
        }
        NRF_LOG_FLUSH();
    }
}
    if (!detected_device)
    {
        NRF_LOG_INFO("No device was found.");
        NRF_LOG_FLUSH();
    }

    while (true)
    {
        /* Empty loop. */
    }
}

/** @} */

Thank You awneil and On haakonsh

attached is the code snippet and logic analyzer scope as u have requested, by not connecting to any devices to development kit.

As u can see still the clock is 200K.

Thank you