[#6784] i2c times out on system load
Submitted By: Lukas Weiss
Open Fixed In Release:
Found In Release:
ALL Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
2010.06-2010R1-RC2 Toolchain version or rev.:
App binary format:
Summary: i2c times out on system load
We found a problem in i2c-bfin-twi kernel driver that occurs more often on high system load.
Communication fails casually in REPEAT Mode and leads to a timeout ('master transfer timeout'), because the interrupt (XMTSERV, 0x40) that should set the RSTART Bit is served too late. The i2c hardware finishes the transfer with a STOP before, because Data Transfer Count (DCNT) reaches 0. After that the RSTART bit gets set when MEN is already cleared.
The timeout is not very nice for any program that has to wait >5 seconds for a i2c communication (especially when reading a RTC as in my case).
This problem still exists in current trunk, i have made a patch for 2010R1-RC5 to fix this problem. This sets DCNT to 0xff, to prevent the hardware from finishing the transfer automatically before the interrupt has been served.
--- Sonic Zhang 2011-09-06 02:42:48
You patch is not general enough to cover master TX/RX REPEAT mode transfer and
SMBus COMBINED mode transfer.
--- Sonic Zhang 2011-09-06 03:10:33
And you patch may cause TWI buffer write error and doesn't really solve this
If you set 0xff to DCNT, TWI controller always think there should be data
available in the TX buffer for next I2C clock. But, in the case TWI interrupt is
served to later, TX buffer is not filled, DCNT is not cleared and RESTART bit is
not set, then MERR interrupt is generated.
You should fixed this problem by raise the priority of your TWI interrupt.
--- Lukas Weiss 2011-09-06 03:22:46
This is certainly true. The patch *should* only affect REPEAT mode, as i do not
need SMBus for my application and i have no more time to spend on COMBINED mode.
If a run in more problems with i2c i would probably consider a complete rework
of the driver, because it seems not very straight to me.
--- Lukas Weiss 2011-09-06 03:56:43
[QUOTE]"You should fixed this problem by raise the priority of your TWI
--> Not possible on my system. This also happens in idle system with a high
priority of TWI interrupt.
I never run into MERR/BUFRDERR, are you very shure that this happens with
DCNT=0xff? Datasheet is not very exact here. I will test that when i have a
minute. Do you have any other solutions?
--- Sonic Zhang 2011-09-06 04:15:49
I mean the "TWI buffer read error".
Buffer Read Error (BUFRDERR).
 The current master transfer was aborted due to a transmit
buffer read error. At the time data was required by the transmit
shift register the buffer was empty. This bit is W1C.
Master Transfer Error (MERR).
 A master error has occurred. The conditions surrounding the
error are indicated by the Master Status register
Data Transfer Count (DCNT[7:0]).
Indicates the number of data bytes to transfer. As each data word is
transferred, DCNT is decremented. When DCNT is 0, a stop condition
is generated. Setting DCNT to 0xFF disables the counter. In this
transfer mode, data continues to be transferred until it is concluded
by setting the STOP bit.
--- Lukas Weiss 2011-09-06 04:49:32
I have read that. But i doubt that the hardware throws a error on a disabled
data transfer counter in master mode, it would not make any sense.
Ive tested that with a 3ms delay in ISR before setting the RSTART bit without
any problems (running at 100kHz bus speed). The bus is just held down for that
time (see attached scope screens of test with 1ms and 3ms delay in ISR before
settint RSTART). Even if a MERR could occur, after 3ms every ISR should have
--> My patch works excellent, with the exception of combined mode. Here the
problem probably still remains.
--- Lukas Weiss 2011-09-12 00:29:46
Status stays rejected? Next time i keep my improvements in house. Thought this
was a open source project, but in this case i can spend my time more efficient.
--- Sonic Zhang 2011-09-12 23:38:16
We are still consulting the hardware designer in ADI on the behavior of the
manual stop mode. Before we get an answer from them, we can't give you a
conclusion. That's why this bug is still open.
--- Sonic Zhang 2011-09-22 00:12:20
After consulting with ADI hardware designers, we figure out that the
"Buffer Read Error (BUFRDERR)" description in Blackfin HRM is not
correct. It only apply to BF537 rev. < 0.3. In later rev. and later announced
Blackfin chips, such as BF527 and BF548, a new TWI master feature "Clock
Stretching" is added into the TWI controller, while the error description
is not revised. That's why you don't see MERR interrupt after TX FIFO is empty.
Which Blackfin chip do you use? I will apply your patch and update the SMBus
transfer in the same way.
From ADI hardware designer:
Apparently all older parts of Breamer (Si Revs < 0.3 Rev of BF537) has a
problem where the BUFRDERR & BUFWRERR bits can be set, if the data
interrupts are not serviced within a period of time. We are discussing on this
to find out how to put the information for the older parts. For BF537 0.3 Si,
clock stretching feature was added to master and delaying the interrupt
servicing does not cause issues there. You can use the information in BF527 HRM
for now regarding the clock stretching.
In BF527 HRM:
Clock stretching is an added functionality of the TWI controller. This
new behavior of the master mode operation utilizes self-induced stretching
of the I2C clock while waiting on servicing interrupts.
During a master mode transmit, an interrupt is generated at the instant
the transmit FIFO becomes empty. At this time, the most recent byte
begins transmission. If the XMTSERV interrupt is not serviced, the concluding
“acknowledge” phase of the transfer will be stretched. Stretching
of the clock continues until new data bytes are written to the transmit
FIFO (TWI_XMT_DATA8 or TWI_XMT_DATA16). No other action is required to
release the clock and continue the transmission. This behavior continues
until the transmission is complete (DCNT = 0) at which time the transmission
is concluded (MCOMP).
--- Lukas Weiss 2011-09-26 01:07:55
We are using BF537 rev 0.3, so it is with clock stretching. Thank you for the
--- Sonic Zhang 2011-09-26 01:08:08
BF527 HRM puts forward a better solution for this bug on chips with new clock
stretching feature. Restart bit for a repeated transfer can be set at any time
early than MCOMP interrupt in addition to the last XMTSERV interrupt. The
attached patch set restart bit at the very beginning of a repeated transfer and
clear it before in MCOMP interrupt.
Please try the attached patch or checkout trunk head.
--- Sonic Zhang 2011-09-26 01:53:23
Should be "clear it in the second from the last MCOMP interrupt.
File Name File Type File Size Posted By
0001-Fix-bug-6784-i2c-i2c-bfin-twi-TWI-fails-to-restart-n.patch text/x-patch 4215 Sonic Zhang
i2c_3ms_delay.png image/png 43906 Lukas Weiss
i2c_1ms_delay.png image/png 46973 Lukas Weiss
i2c-bfin-twi.c.patch text/x-patch 1482 Lukas Weiss