rkoebler
Posts: 8
Joined: Wed Jun 19, 2013 9:02 pm
Location: Germany
Contact: Website

Re: I2C clock stretching

Wed Aug 14, 2013 5:04 pm

I've analyzed the I2C clock-stretching-problem in more detail and tried to document it.
See http://www.advamation.com/knowhow/raspb ... c-bug.html

From what I've seen, what Gert said is unfortunately only partly correct:
  • Clock-stretching only works directly after I2C-Read-acknowledge-phases (after reading ACK/NACK), and only if the clock is stretched by more than 0.5 clock periods.
  • Clock-stretching does not work at the beginning of I2C-Write-acknowledge-phases.
    (i.e. at the moment where the slave has to decide whether to send an ACK or NACK)
  • In addition to the problem that the slave may miss a too short clock-pulse, the Raspberry Pi also reads SDA too early when the clock is stretched. So, even stretching the clock by a very very small amount in the I2C-Read-acknowledge-phase results in corrupted data.
@Gert: Is there any hope that this bug (which makes I2C nearly useless on the Raspberry Pi for clock-stretching devices) will be fixed?

In addition, I've found a quite elegant workaround for devices, which stretch the clock after an I2C-read-acknowledge-phase by <0.5 clock pulses: An appropriate additional I2C-microcontroller could be used, which listens on all I2C-addresses, and always adds clock-stretching of >=0.5 clock-cycles to every I2C-Read-acknowledge-phase (more or less an "I2C-Read-ACK-stretching-delay-injector"). I've implemented and tested this in my Raspberry Pi-extension-board AdvaBoard RPi1, so that at least arbitrary stretches directly after I2C-Read-ACK-phases work without corrupting the data...

whowantspi
Posts: 35
Joined: Mon Feb 11, 2013 12:00 am
Location: USA Alabama

Re: I2C clock stretching

Mon Nov 04, 2013 4:20 am

Is anything being done to fix this problem? Or is it going to be like this forever?

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

Re: I2C clock stretching

Tue Nov 05, 2013 11:19 am

The I2C clock stretching is done in hardware.
Therefore there is nothing we can do about it.

keendog
Posts: 4
Joined: Tue Nov 26, 2013 11:03 pm

Re: I2C clock stretching

Tue Nov 26, 2013 11:12 pm

I realize clock stretching is not recognized properly by the rpi i2c pins, but others have discussed implementing slower bus clock speeds to circumvent the issue. Is this acheived using a module coded in C that changes the CDIV field on the BCM2835?

Any others that have tried this? I am going in! Cover me.

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

Re: I2C clock stretching

Wed Nov 27, 2013 9:15 am

Gordon Henderson used the I2C interface talking to an Atmel chip on the Gertduino.
(I can talk about that now). The Atmel chip, as most controllers ALWAYS does clock stretching.
He found that it does work if he turns the I2C clock very low. I think it was about 10 KHz.

Do NOT, EVERY try that with a PIC! I did and found the PIC can NOT cope with slow I2C clocks.
I found on a 10KHz clock it requires 7 reads to get 1 byte out but works fine at 100KHz
I have no idea how they managed to screw that up. I am an ASIC engineer and I can't think
of a way to implement that if I WANTED!

hampi
Posts: 223
Joined: Fri May 31, 2013 11:29 am
Contact: Website

Re: I2C clock stretching

Thu Nov 28, 2013 8:45 am

Do NOT, EVERY try that with a PIC!
There is an exception to this rule when you implement the i2c in software code. In my case I use the PIC interrupt INT to detect high to low transition which can be interpreted as a start bit if SCL stays high. My hacking can be seen from

https://github.com/oh7bf/PiPIC/blob/mas ... 12si2c.asm

In such an interrupt driven code clock stretching does not make sense since the microcontroller could be waiting very long time in the interrupt service routine and exit only after watch dog timer reset.

Yesterday I discovered a new "feature" in the code. I did not test it very carefully with a second i2c chip connected at the same time and there seems to be a WDT timeout when simultaneously writing and reading an other chip. Need to see if that can be fixed somehow.

Edit: Correct link and typo. The "feature" has been fixed a long time ago already.
Last edited by hampi on Mon Feb 09, 2015 7:30 pm, edited 1 time in total.

highwalker
Posts: 3
Joined: Wed May 14, 2014 4:26 am

Re: I2C clock stretching

Sun Jun 22, 2014 4:49 am

Folks,

This might seem like flogging the dead horse, and raising the dead here, but I am hoping this post might give hope to folks trying to use the RPi interfacing with other microcontrollers over I2C.

Going through the BCM ARM peripherals document seems to indicate there is a handling built-in for this issue. The register in question is DEL register in the BSC. This has two fields REDL and FEDL which, IMHO, can be used to address the clock stretch issues mentioned. The interesting field is the REDL which is basically asking the BSC controller to apply a READ DELAY of x clocks before reading the data.

I believe using this to apply a 1 clock delay should address the "bug".

I am writing a direct access I2C lib for my use which will offer the freedom to set this register, although I am not sure how this can be used with the kernel implementation.

I look forward to comments from the experts on this find.

Thanks,

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

Re: I2C clock stretching

Sun Aug 10, 2014 2:43 pm

I am not sure but I think that only helps if clock stretching happens during the ACK phase. It would not work if the clock is stretched anywhere else.

noopie
Posts: 1
Joined: Thu Oct 16, 2014 11:17 pm

Re: I2C clock stretching

Thu Oct 16, 2014 11:20 pm

Hey highwalker, did you have any success with your lib?

ttww
Posts: 4
Joined: Thu Oct 31, 2013 8:43 pm

Re: I2C clock stretching / communication solution

Mon Dec 01, 2014 7:52 pm

I had the same problem :-)

My setup was:
  • Arduino Uno with an I2C receive and request function (build with Eclipse on Mac and AVR toolchain) (slave)
  • Raspberry Pi with Java and Pi4J libs (master)
After fixing following points, anything was working perfectly (several million bidirectional transfers without any error) :
  • Adding "baudrate=75000" to the linux i2c_bcm2708 driver (default is 100000). For doing this you have to create a "/etc/modprobe.d/i2c.conf" file and adding a "options i2c_bcm2708 baudrate=75000" line.
  • Avoid transferring more than *ONE* byte per request. I had always failiures in any configuration when I tried more.... You need some kind of buffer handling for transferring more data (e.g. collect all incoming bytes until a CR on the slave side or requesting single bytes until an CR on the master side)
  • Wire.onReceive(...) and Wire.onRequest(...) functions are called from the ISR and HAVE TO BE FAST.... Don't use Serial output, I even failed with controlling some max7219 matrix display, which I used for debugging :-)
  • Use the Arduino watchdog :-) So your Arduino can recover if the I2C bus hangs (e.g. if you stop the master in the middle of an I2C cycle)
...may be the fun with you...

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

Re: I2C clock stretching

Mon Dec 01, 2014 7:59 pm

Use the Arduino watchdog :-) So your Arduino can recover if the I2C bus hangs (e.g. if you stop the master in the middle of an I2C cycle)
I have built some I2C interfaces. I always added a time-out register so the interface would recover if the clock stretching was
going past some set time limit. e.g. 100 I2C clock cycles.
It is interesting to see that hardly any I2C devices have that vitally important feature.

Casey Goodwin
Posts: 1
Joined: Fri Feb 06, 2015 5:08 pm

Re: I2C clock stretching

Fri Feb 06, 2015 7:04 pm

Now that Raspberry Pi 2 (based on BCM2836) has been released, I'd like to bump this thread:

Is there is any documentation or testing to determine if the i2c clock stretching bug is still present in the BCM2836 or if clock stretching has been fixed (along with all the other improved specs)?

Background: To implement a medium area distributed sensor/control network for Smart Lighting applications, I've been developing a 64-channel i2c multiplexer and the Raspberry Pi's clock stretching bug is in direct competition with our goal to keep from adding more embedded platforms (nearly all our existing embedded systems are built on stock Raspberry Pi with a few software/OS tweaks). It would be great news if the Raspberry Pi 2 could serve as the controller without the need for an SPI-to-i2c bridge chip (e.g. NXP SC18IS600).

Thanks!

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20494
Joined: Sat Jul 30, 2011 7:41 pm

Re: I2C clock stretching

Fri Feb 06, 2015 8:20 pm

I believe the I2C is unchanged.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

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

Re: I2C clock stretching

Fri Feb 06, 2015 10:46 pm

jamesh wrote:I believe the I2C is unchanged.
I believe the I2C is unchanged

dms
Posts: 15
Joined: Sun Jun 24, 2012 11:31 am

Re: I2C clock stretching

Sun Feb 08, 2015 8:37 pm

I was hoping that the problem would be fixed in BCM2836.
The I2C on the PI is very difficult to use. Chips that require clock stretching
do not work and the usual work around - slowing the clock speed - also
does not work (reason unknown but I suspect the frequency is changed but
not the pulse width).
I am about to publish a Java interface for I2C on PCs and the PI and was hoping
for good news.
I am now hoping that PI software for FDTI Chips UMFT4222EV will be released soon.
This is a USB to I2C dongle that supports clock stretching and clock speed changing.
It works well on the PC and once available on the PI will allow the same Java programs
to run on the PC and the PC.
The PI 2 looks good but we need a working I2C
Regards
Don

joraff
Posts: 8
Joined: Thu Feb 19, 2015 2:27 am

Re: I2C clock stretching

Thu Feb 19, 2015 2:56 am

Tomorrow I will hook up an old pi and the 2 up to a scope, but in theory the unchanged i2c and increased clock of the Pi 2 may have made some other odd timing issues a little worse.

For instance there's an RFID board I frequently use, the SL030, that is a little slow to sink SDA at the beginning of a byte. I recall reading somewhere that the Pi samples almost immediately after SCL rises. This causes the MSB to aways be sampled when SDA is high. On the old Pis, you could tweak the baud rate to correct this timing. I haven't found a rate that works on the 2, which I just got.

joraff
Posts: 8
Joined: Thu Feb 19, 2015 2:27 am

Re: I2C clock stretching

Thu Feb 19, 2015 4:30 pm

Here's a shot of a Rpi model b+ at 100Khz. Is this clock stretch during ACK?
NewFile1.png
SL030 i2c ack
NewFile1.png (48.52 KiB) Viewed 6090 times

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1785
Joined: Thu Jul 11, 2013 2:37 pm

Re: I2C clock stretching

Thu Feb 19, 2015 5:08 pm

dms wrote:I was hoping that the problem would be fixed in BCM2836.
The I2C on the PI is very difficult to use. Chips that require clock stretching
do not work and the usual work around - slowing the clock speed - also
does not work (reason unknown but I suspect the frequency is changed but
not the pulse width).
I am about to publish a Java interface for I2C on PCs and the PI and was hoping
for good news.
I am now hoping that PI software for FDTI Chips UMFT4222EV will be released soon.
This is a USB to I2C dongle that supports clock stretching and clock speed changing.
It works well on the PC and once available on the PI will allow the same Java programs
to run on the PC and the PC.
The PI 2 looks good but we need a working I2C
Regards
Don
One possible workaround that's now much more viable on 2836 is the use of bitbashed GPIO to emulate i2c. With four cores available, doing i2c transactions at a sensible rate is now much more within reach.
Rockets are loud.
https://astro-pi.org

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

Re: I2C clock stretching

Thu Feb 19, 2015 7:38 pm

Chips that require clock stretching
do not work and the usual work around - slowing the clock speed - also
does not work (reason unknown....
The reason is well known! This is a repeat of a post I made a loooong time ago in this same forum.
See this document:
http://www.scribd.com/doc/131905944/283 ... erface-pdf
What you see in that scope trace (blue line) is exactly what I described in the above document.
(Search for "But the 2835 will blindly slam the clock down on the next clock edge time." and the following pictures)

The only solution is to make sure you have a long period in which the I2C clock is still high.
Long enough for both the 2835 and the attached I2C device to see it as a valid clock edge.
This means:
A/ Extreme fast reacting to the I2C interface seeing the address.
B/ Slow the I2C clock down very much.
The latter means that at some point it becomes more efficient to do the I2C interface using 'bit bashing'.
That is why you see that recommendation appearing often in this forum.
Note that another solution: preventing the I2C device from pulling the clock low in the first place,
is not available on most I2C devices. As such we are not the only ones who make design errors.

joraff
Posts: 8
Joined: Thu Feb 19, 2015 2:27 am

Re: I2C clock stretching

Thu Feb 19, 2015 7:52 pm

This was my first time to view this particular board on a scope, and now I know it's actually the clock stretching bug, and not a timing mistake.

Increasing the baud rate solved the issue on the older Pis, probably because the stretch duration then becomes longer than 0.5 clock periods, as documented by @rkoebler. I posted a little prematurely about the Pi 2 - the device tree was causing the baud rate to default to 100Khz. I updated the kernel and the device tree params took effect, and the Pi 2 now works same as the < Pi2B. I apologize.

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

Re: I2C clock stretching

Fri Feb 20, 2015 9:32 am

probably because the stretch duration then becomes longer than 0.5 clock
If your clock stretching period is such that it takes out the whole of the hight period that will work.
But you maybe playing with fire. e.g. if your I2C service routine is interrupted by a (higher level) interrupt things may go wrong again.
The error will still be there but now appear much less. e.g. once every two days.
Than again can be solved by disabling interrupts.
Knowing the underlying cause of a problem is the first step to solving it.

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

Re: I2C clock stretching

Wed May 06, 2015 3:05 am

Hello,

I've been reading a lot of the information that has been found on the I2C clock stretching issue. I was also having I2C problems, which may or may not be similar to what some of you are talking about. I was able to solve my I2C issues with some minor code modifications in i2c-bcm2708.c in the kernel source tree. I am on the Raspberry Pi 2, and I am not sure if Pi 2 uses the same exact peripheral silicon as previous Pis. Hopefully this post will help someone who has a similar issue to mine.

Note: My I2C issue only showed up during "combined" transactions. That is a start->write->restart->read->stop transaction. I am running the I2C at 100K baudrate. I am running the latest kernel, from main line source, 3.18.12-v7+.

*Clock stretching is supported, as well a clock stretch timeout value. This is documented in the BCM2835 BSC (I2C) peripheral guide that is floating around. I found that the default value that is loaded into the clock stretch timeout register is 64 (0x0100 0000). At 100,000 baud I2C, this would yield a clock stretch timeout of 64us (1/100K * 64). My issue did not lie here, but this could potentially help anyone where their slave device stretches beyond this period of time. In the driver, if a clock stretch timeout occurs, it is not handled very well. The function immediately returns an error value without really cleaning up the registers as far as I can tell. See the code excerpt below.
*There is a variable called "wait_loops" in the driver source. This is where my problem lay. This value was decrementing below zero and causing the driver to bail out of the I2C transfer halfway through the combined transaction (the same way it would for a clock stretch timeout). I doubled this value from 40 to 80 and my I2C has been working flawlessly, so far. I will be running more stress tests on it. See the code excerpt below.

It is inside the below function, inside the combined transaction if statement:

Code: Select all

static inline int bcm2708_bsc_setup(struct bcm2708_i2c *bi)
Here is an excerpt of the offending code:

Code: Select all

      do {
        s = bcm2708_rd(bi, BSC_S);
      } while (!(s & (BSC_S_TA | BSC_S_ERR | BSC_S_CLKT | BSC_S_DONE)) && --wait_loops >= 0);

      /* did we time out or some error occured? */
      if (wait_loops < 0 || (s & (BSC_S_ERR | BSC_S_CLKT))) {
        printk(KERN_ERR "Wait loops: %d\nBSC S_Reg: %u\n", wait_loops, s);     // ** I added this line for debugging **
        return -1;
      }
For me, wait loops was decrementing below 0 before either the BSC_S_TA | BSC_S_ERR | BSC_S_CLKT | BSC_S_DONE flags where able to be set. I am not exactly sure what is causing any of those 4 flags to not be set to 1 before the wait_loops variable times out. Anyways, by increasing the wait_loops, I allowed the driver more time to register one of those flags before timing out.

I was originally seeing a different I2C bus issue on older kernel builds. I've since updated my kernel. That issue was that my slave was clock stretching before sending an ACK to the master on the initial Read command portion of a combined transaction. This problem went away for me either by making the above kernel changes talked about above OR updating and building the latest kernel source (version noted above). I am not sure what fixed it, but it is not happening any more. If this issue crops up again for some reason, I will update.

Regards

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

Re: I2C clock stretching

Wed May 06, 2015 5:00 am

First of all: congratulations for your fix.
Not some comments.
I am not sure if Pi 2 uses the same exact peripheral silicon as previous Pis.
If you read the comments you will find out that it is the same in every FET.
I wanted to fix the I2C issue but it was not possible as it was waaaay to complex to do that using only ECOs.
*Clock stretching is supported, as well a clock stretch timeout value. This is documented in the BCM2835 BSC (I2C) peripheral guide that is floating around.
Of course, but it refrains to add: "but not at all points under all circumstances."
is 64 (0x0100 0000).
You probably mean Binary 0100 0000.

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: I2C clock stretching

Wed May 06, 2015 5:23 am

I'm not going to pretend to really understand this issue, but I am hoping you could confirm that the following simple change fixed your problem. Thank you.

Code: Select all

#define I2C_WAIT_LOOP_COUNT 40
changed to

Code: Select all

#define I2C_WAIT_LOOP_COUNT 80

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

Re: I2C clock stretching

Wed May 06, 2015 8:26 am

Ah that is software.
I don't know anything about the software.
I am the guy who did the hardware.

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

Who is online

Users browsing this forum: No registered users and 14 guests