FAQ: [#6784] i2c times out on system load(2011)

[#6784] i2c times out on system load

Submitted By: Lukas Weiss

Open Date

2011-09-06 01:17:58

Priority:

Medium Assignee:

Sonic Zhang

Status:

Open Fixed In Release:

N/A

Found In Release:

2010R1-RC5 Release:

2010R1-RC5

Category:

Drivers Board:

N/A

Processor:

ALL Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

2010.06-2010R1-RC2 Toolchain version or rev.:

2010R1-rc4

App binary format:

N/A

Summary: i2c times out on system load

Details:

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.

Follow-ups

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

problem.

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

"You should fixed this problem by raise the priority of your TWI

interrupt."

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

[1] 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).

[1] A master error has occurred. The conditions surrounding the

error are indicated by the Master Status register

(TWI_MASTER_STAT).

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

been served.

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

Hi Lukas,

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

info.

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

Files

Changes

Commits

Dependencies

Duplicates

Associations