This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

I2C clock frequency problem

Hi,

I am using NRF52832 development board , to which i have interfaced LIS3DSH accelerometer sensor(3.3V i2c)

when i  configure it for 1600 sampling rate and all the axis enabled , i am not able to get any data .

could anyone help with this problem.

also the I2c clock frequency, as shown in below image, while i am capturing data when i observe in oscilloscope or logic analyzer , clock frequency is showing 200 all the setting is for 400KHz.

what could be the problem for this or is there any other way i need to follow to set the clock to 400KHz.

help me ASAP...

Thank you

Parents
  • "also the I2c clock frequency, as shown in below image, while i am capturing data when i observe in oscilloscope or logic analyzer , clock frequency is showing 200 all the setting is for 400KHz."
    That's unlikely, I think you're measuring the clock frequency incorrectly.


    Why have you enabled pulldowns on your IO pins?

  • actually that's not the part of code , sorry excluding that is the actual code

  • Thanks  , 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.

  • 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.

  • 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.

  • Indeed - and you can refer them to this thread.

  • 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 ... ?

Reply
  • 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 ... ?

Children
  • awneil said:
    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.

    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.

     

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

     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. 

  • some form of loading on the I2C lines

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

    Why have you enabled pulldowns on your IO pins

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

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

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

  • will pulling up the line help

    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.

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