This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650 Sensor Controller - I2C Frequency Slower Than Expected

Other Parts Discussed in Thread: ADS1115, CC2650

I am currently using the Sensor Controller with the CC2650 to get readings from 4 ADS1115 ADCs through 400kHz I2C communication. However, when I look at the signals using a logic analyzer, the SCL clock period is around 3.6us, rather than than the expected 2.5us. Is there any way to lower the SCL clock period, or is this the fastest it can operate?

The SCL stretch timeout is set to the lowest value of 1us. Is this causing the issue, and is there a way to remove the stretch timeout? The data sheet for the ADC mentions that the device does not perform clock-stretching.

  • Hi Jason. I'm looping in some people who may be able to provide an answer.
  • Hi Jason,

    It may be helpful to ensure the I2C clock setting is as expected. Please check the I2C resister MTPR. It determines the clock rate.
  • Hi rfocus,

    My question was referring to the Sensor Controller which, from my understanding, implements the I2C communications through bit-banging using a separate processor from the CM3 CPU. I don't believe the Sensor Controller uses the MTPR register since it should not be using the I2C hardware peripheral? The hardware supported I2C communication runs correctly around 400 kHz when I use the TI-RTOS I2CCC26XX.h library. My plan is to have one I2C line controlled through the Sensor Controller, while another separate I2C line is controlled using the CM3. If the two are sharing the I2C peripheral, then that would be a problem.

    After some additional testing, I have also found that the clock cycle can stretch from 3.6us up to 4.6us, instead of the expected 2.5us - 3.5us. It would be helpful if the stretch timeout could be removed, but Sensor Controller Studio does not seem to allow a value under 1us.

    Cheers,
    Jason
  • Hi Jason, I think you are right, for AUX to control bit-banged GPIO, there should be nothing to do with the I2C peripheral register.
  • Hi Tim,

    Were you able to find someone who might know about this issue?

    Cheers,
    Jason
  • Hello Jason,
    I am checking with the developer team. I will get back to you shortly. If not feel free to ping on the thread.
  • Hello Jason,

    We are not able to reach true 400 kHz. With a I2C-implementation in hardware you usually have a over-sampled clock by a factor of 40x, 60x or more. For the Sensor Controller we have 2.5 x 12 = 30 instructions per bit on 400 kHz. This makes it hard if not impossible to achieve an optimal solution.

    we tried to tune the slowest subroutine. Try to copy it into C:\Users\<xyz>\Documents\Texas Instruments\Sensor Controller Studio\proc_defs, and see if that can give sufficient performance.

    /cfs-file/__key/communityserver-discussions-components-files/538/i2c_5F00_wait_5F00_scl_5F00_stretch.asm

  • Hello,

    I had the same problem (I needed faster I2C speed in the sensor controller. I used the asm routine you attached and the clock speed was increased (from 250k to 315k) which is good enough for me.

    Just one question regarding that change: Is it safe to use compared to the original routine? I mean, why isn't that asm routine included by default in the sensor controller studio? I downloaded today the latests version of SCE and I had to manually replace the i2c asm with the one you attached to have the speed boost.

  • This will be added in the next release 1.4.0 which is coming out within weeks.