gtozzi
Posts: 5
Joined: Fri May 01, 2015 5:36 pm

Re: I2C clock stretching

Wed May 06, 2015 6:15 pm

@ Gert
*Yes, I meant binary 0b0100 0000, it was late when I posted last night XD.
*I hadn't heard any mention of the clock timeout register from any of the discussions, but figured that mentioning in my post may help someone.
*Thanks for clarifying that Pi 2 is exactly the same as Pi 1 in terms of peripherals.

@ktb
*Yes, that is the exact change I made.
*I would recommend putting in some printks in the various sections of bsc_setup so you can get more insight as to what might be happening. I was printing out while_loops variable as well as different BSC register values to see what was going on. You can also check what values are loaded into the different registers before a transaction is started.

Just based on the small amount of poking I did in the driver source file, I would say there is a decent chance that a lot of issues people are having may not actually be based on hardware bugs, but rather the driver that is controlling the hardware. Which is not surprising considering the general lack of hardware level detail in the BCM2835 peripheral guide. It's really about as abstract as you can get when describing a peripheral device. But it does still do a decent job, and I think the kernel driver does not use all the tools (aka BSC registers) available to it to cover all I2C scenarios. I'd be interested to hear any comments on this sentiment.

solanum
Posts: 13
Joined: Thu Nov 03, 2011 9:54 pm

Re: I2C clock stretching

Tue Jun 02, 2015 3:50 pm

@Gert, since you are the hardware guy. How do we get more detailed specs? Is there a process? Is this the standard ARM implementation of i2c? If so, which version?

There is a possibility this isn't a hardware bug, or if it is a hardware bug, potentially it can be worked around in software.


But just reading:
http://blog.retep.org/2014/02/15/connec ... using-i2c/
He mentions having to use single threading. I think he also mentions using checksums and the like to make sure his data is not corrupted on the send/receive.

It wouldn't surprise me if there were bugs in the i2c kernel module especially for corner cases as has been mentioned.
It also wouldn't surprise me if there was a threading issue and i2c is a lot more frail, then people are used to.

But what is the process to get more detailed information?

I haven't gotten i2c to even work, part of the issue right now is the "arduino and arduino-core" packages are so out of date, they don't support my arduino board. I tried to upgrade to jessie, but I think it was after I hard rebooting it failed to boot. (it may have been unplugged without powering down.) It was working after soft reboots, but logins via ssh were noticeably slow, namely the session info. there was also shutdown bug where it couldn't find a service to shutdown or something.)

User avatar
Gert van Loo
Posts: 2474
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: I2C clock stretching

Wed Jun 03, 2015 6:07 am

or if it is a hardware bug, potentially it can be worked around in software.
I tried and I could it only working at very low rates, and even then I never got my error rate to zero.
But then I was running in Linux which it not the ideal environment for real-time processing.
Unfortunately I can't help beyond the articles I wrote.
I know what the hardware looks like and I know what it does, actually: what it does wrong.
I was hoping somebody with a more knowledge about real-time SW and drivers
would be able to find a solution given that I have explained the problem.

User avatar
joan
Posts: 13460
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: I2C clock stretching

Wed Jun 03, 2015 7:34 am

pigpio has in-built bit banging of I2C. It supports clock stretch and repeated starts.

See bbI2COpen, bbI2CZip, and bbI2CClose.

DeFy
Posts: 3
Joined: Sun Dec 27, 2015 2:48 am

Re: I2C clock stretching

Sun Dec 27, 2015 10:29 pm

I can confirm what gtozzi said earlier about the timeout not being long enough but for me it was the clock stretch timeout. I made a script which watches the GPIOs for the SDA and SCL using pigpio and outputs a plot. I am using the Si7021 temp/humidity sensor (same as HTU21D, SHT21) and RPi 1 model B (bcm2708) and when using a temperature read in hold mode it was fine but doing a hold humidity read ran into a timeout since the humidity conversion takes longer.
Image
It is obvious from the plot and looking at the BCM2835 peripherals datasheet that it supports clock stretching.
I dug around in the i2c-bcm2708 kernel module and modified a few things:
- changed the clock stretch timeout BSC_CLKT from the default 64 clock cycles to 32ms (calculated based on baudrate) as per the SMBus specs.
- the modprobe 'baudrate' parameter was there but was overridden by the clock-frequency in platform_device object passed to it which I guess has something to do with the device tree. The user set baudrate should probably have priority over the defaults.
I cross compiled following this guide and copied to /lib/modules/4.1.15+/kernel/drivers/i2c/busses/i2c-bcm2708.ko, loaded it and worked fine.
Now using modprobe i2c-bcm2708 baudrate=10000 or setting "options i2c_bcm2708 baudrate=10000" in /etc/modprobe.d/i2c.conf works and reading humidity in hold mode works.
I did a pull request for these changes on github.

WiFi
Posts: 3
Joined: Sat Oct 19, 2013 6:01 pm

Re: I2C clock stretching

Fri Mar 11, 2016 5:15 am

Hi guys,

eventually someone can advise whether the clock stretching bug is eliminated in the 2837 architecture (Raspberry Pi3) ??

Regards

mattmiller
Posts: 1904
Joined: Thu Feb 05, 2015 11:25 pm

Re: I2C clock stretching

Fri Mar 11, 2016 8:21 am

I've seen a post by an engineer that says no as I2C is implemented in part of the Pi that hasn't changed

User avatar
joan
Posts: 13460
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: I2C clock stretching

Fri Mar 11, 2016 9:23 am

mattmiller wrote:I've seen a post by an engineer that says no as I2C is implemented in part of the Pi that hasn't changed
That may have been a mistake. I know someone has put in a kernel update request for the I2C driver as some settings which could have been used were not being used. The settings apparently allow clock stretching to work. I don't know the progress of the request. I have referred to it within the last month or so.

mattmiller
Posts: 1904
Joined: Thu Feb 05, 2015 11:25 pm

Re: I2C clock stretching

Fri Mar 11, 2016 9:53 am

ooh - that would be good news when its implemented :)

larsth
Posts: 48
Joined: Sat Aug 27, 2011 9:51 pm
Contact: Website

Re: I2C clock stretching

Sat Mar 12, 2016 8:26 pm

It would be really good news to be able to do I²C reliable in hardware.

Alternatively I guess it would be possible to abuse a CPU core in RPi 2/3 to do I²C bit banging with the i2c-gpio kernel space driver - especially if you use a low I²C bus frequency, and don't have a lot to do.

In my case it will be controlling and/or reading from: /Lars
Last edited by larsth on Sat Mar 12, 2016 8:41 pm, edited 1 time in total.

User avatar
joan
Posts: 13460
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: I2C clock stretching

Sat Mar 12, 2016 8:38 pm

@larsth

I've used a PCA9685 and a HMC5883L. No clock stretching was required.

larsth
Posts: 48
Joined: Sat Aug 27, 2011 9:51 pm
Contact: Website

Re: I2C clock stretching

Sat Mar 12, 2016 8:43 pm

joan wrote:@larsth

I've used a PCA9685 and a HMC5883L. No clock stretching was required.
Great!
Thanks for the reply.

/Lars

User avatar
joan
Posts: 13460
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: I2C clock stretching

Sat Mar 12, 2016 8:49 pm

larsth wrote:
joan wrote:@larsth

I've used a PCA9685 and a HMC5883L. No clock stretching was required.
Great!
Thanks for the reply.

/Lars
Both these examples use my library but the changes to use the Python smbus module should be trivial.

http://abyz.co.uk/rpi/pigpio/code/PCA9685_py.zip

HMC5883L

Code: Select all

#!/usr/bin/env python

# i2c_HMC5883L.py
# 2015-04-01
# Public Domain

import time
import struct
import sys

import pigpio

if sys.version > '3':
   buffer = memoryview

BUS=1

HMC5883L_I2C_ADDR=0x1E

RUNTIME=60.0

pi=pigpio.pi() # open local Pi

h = pi.i2c_open(BUS, HMC5883L_I2C_ADDR)

if h >= 0: # Connected OK?

   # Initialise HMC5883L.
   pi.i2c_write_byte_data(h, 0x00, 0xF8)  # CRA 75Hz.
   pi.i2c_write_byte_data(h, 0x02, 0x00)  # Mode continuous reads.

   read = 0

   start_time = time.time()

   while (time.time()-start_time) < RUNTIME:

      # 0x3 = X MSB, 0x4 = X LSB
      # 0x5 = Y MSB, 0x6 = Y LSB
      # 0x7 = Z MSB, 0x8 = Z LSB

      # > = big endian

      (s, b) = pi.i2c_read_i2c_block_data(h, 0x03, 6)

      if s >= 0:
         (x, y, z) = struct.unpack('>3h', buffer(b))
         print("{} {} {}".format(x, y, z))
         read += 1

   pi.i2c_close(h)

pi.stop()

print(read, read/RUNTIME)

WiFi
Posts: 3
Joined: Sat Oct 19, 2013 6:01 pm

Re: I2C clock stretching

Sat Mar 19, 2016 8:17 am

I am using this BitBanging Workaround since years - it is my preferred solution when programming in C.

http://www.byvac.com//downloads/Pi/bcm2835_i2cbb.zip

5 Stars recommendation!


Needs address modification for different Raspberry Versions.

Have Fun

Regards

fenwiz
Posts: 1
Joined: Sat Feb 24, 2018 5:45 pm

Re: I2C clock stretching

Sat Feb 24, 2018 5:55 pm

I have also encountered this bug with the I2C driver. Having researched the problem, I discovered a work around provided by Hobbytronics in the form of way to run the clock at a slower rate, giving the slave device more time to respond. Here is the link to their article where you can download the slowdown application.
http://www.hobbytronics.co.uk/raspberry ... stretching
I hope this helps :-)

jimer
Posts: 3
Joined: Tue Oct 01, 2013 7:02 am

Re: I2C clock stretching

Sun Jun 24, 2018 3:00 pm

Just to summarise the RPI does do clock stretching but by default it will only allow the slave to hold the clock low for 0.6mS and so for 'real' devices such as slow EEPROMS or LCD displays this time out is just too small, something like 30mS would be more appropriate.

The timeout is set in one of the BCM registers and successfully altering this register can change the timeout to 30mS or more thus solving all of the issues associated with clock stretching. There is no need to slow the clock down or use any other 'work around'

I have a single Python function that will read and write to any i2c device including a general call here: http://www.pichips.co.uk/index.php/RPi_I2C_2018
example
import i2crpi
i= i2crpi.IIC(timeout=3000)

Can now be used:
mem = i2c(0xd0,[0,61],5)
Sends bytes 0,61 to the connected device with an i2c address of 0xd0, then it reads 5 bytes into mem, as a list of bytes.

It uses some c code in the initialisation of the class to change the value of the register. I modified the code from here: https://raspihats.com/i2c-hat/2016/02/1 ... meout.html

Until the next change..

Insurmountable
Posts: 33
Joined: Fri Oct 20, 2017 11:50 am

Re: I2C clock stretching

Sun Aug 12, 2018 9:25 pm

How do you read and write to a specific register on the BN0055 using this method?

The Adafruit code allows you to specify <address><register><data> this only gives you <address><data>.


The only way I could get the Adafruit code to run was by adding time.sleeps all over the place, I could get a quicker fix on my position using a sextant and the stars..

I compiled and ran the i2c_set_tout and it confirms it is loaded but it has no effect on the time stretching problem of the BN0055, no matter the time-out value I use.

hmf2015
Posts: 1
Joined: Wed Aug 15, 2018 1:00 pm

Re: I2C clock stretching

Wed Aug 15, 2018 1:10 pm

Daer all, I wrote a comment to "https://github.com/raspberrypi/linux/issues/254", because I found a workable sollution to work with the BNO055 packaged GY-955 with a PI 2B.
Conclusion:
1. the bug in the BMC2835 seems to appear only with the frequence 100_000 Hz
2. the BNO055 works until 125_000 Hz (more than expected)
3. it's only a snapshot, the verification that the clock does the frequence is outstanding

Return to “Interfacing (DSI, CSI, I2C, etc.)”

Who is online

Users browsing this forum: No registered users and 14 guests