2010-05-12 05:28:23     I2C driver - trunk

Document created by Aaronwu Employee on Aug 23, 2013
Version 1Show Document
  • View in full screen mode

2010-05-12 05:28:23     I2C driver - trunk

Rob Maris (GERMANY)

Message: 89334   

 

I read about a very recent patch of i2c-bfin-twi.c. Some time ago I already processed the patch regarding "faulty salve devices".

 

I'm working with a device (TCA6408A) which appears to be susceptible to latch-up or so, resulting in spurious keeping SDA low upon end of transmission. Your patch worked well to cope with this in order to have continuous operation.

 

However, further investigations showed that this clear difference was obeyable only with write transfers (using i2c_smbus_write_byte_data()).

Upon read transfers (i2c_smbus_read_byte_data()), hang-ups can still occur, resulting in the application process getting in unkillable "R"-state with high CPU load. I'd suggest that your measure in the interrupt routine would be valid for all sort of transfers, but apparently this is not exactly the case.

 

Perhaps the maintainer have an instant idea of a place where some hang-up with read transfers could occur. If desired, I can try to capture the precise status upon such a hang-up condition.

 

-Rob

 

P.S.: I have modified SCL timing slightly in order to better fit the specs when 400 kHz is used, see attachment.

 

patch

QuoteReplyEditDelete

 

 

2010-05-12 05:41:13     I2C driver - trunk

Michael Hennerich (GERMANY)

Message: 89335    Hi Rob,

 

Are you sung the latest driver from trunk?

We recently fix an bug where an interrupt may have been lost.

There have been also fixes to improve the timeout behavior.

So you should see an "master transfer timeout" error at some time.

 

In order to see where the hang occurs try to trace the execution with

printk("%s:%d\n", __func__, __LINE__); waypoints in the relevant driver functions.

 

-Michael

QuoteReplyEditDelete

 

 

2010-05-12 10:12:27     Re: I2C driver - trunk

Mike Frysinger (UNITED STATES)

Message: 89336   

 

the driver already has debug statements you can enable with #define DEBUG

QuoteReplyEditDelete

 

 

2010-05-18 08:36:46     Re: I2C driver - trunk

Rob Maris (GERMANY)

Message: 89511   

 

Michael: - sorry to be this late - I have been using latest trunk code, my diff was just related to this code. End of this week I'll try to debug this using the hints given.

 

-Rob

QuoteReplyEditDelete

 

 

2010-08-12 10:42:54     Re: I2C driver - trunk

Rob Maris (GERMANY)

Message: 92379   

 

@Michael (Hennerich):

 

I did some experiments with adding some printk statements. As a result, I have doubled a section that has been introduced a few months ago in a patch (adds up to 9 clock impulses to cope with faulty devices).

 

Let's look at this sample output (and refer to the modified source file attached):

 

!175! 9 8 7 6 5 64 !195! 9 8 7 0

 

At line 175 a loop counter starts, and ends up with 5, because the SDA is found to be high. But a after few lines of further processing, SDA is low again. For this reason I experimented with doubling the loop section (from line 195). There it goes okay. Note: this doubling is necessary only when read calls on I2C are being used. Note also that the trouble only occurs when the environment is quite harsh (in terms of EMC).

 

 

 

Or examine this one, where the process is still hanging:

 

!175! 9 8 7 6 5 4 3 64 !195! 9 0 Error: Read failed

Error: Read failed

Error: Read failed

!175! 9 0 ---IO_CARD write error - repeat

<3>i2c-adapter i2c-0: smbus transfer timeout

Error: Read failed

 

 

("Error:....." is a printout from the userspace SMBUS call, when the call delivers a negative result).

 

Putting the SDA loop section also behind the function where the "smbus transfer timeout" message is generated helps in this case. But in this experimental state, I found that this loop had to be doubled, too. In this case the communication gets re-established, however not immediately, but with a delay of approx. 2 seconds.

 

Note: When I disconnect the IC (it is attached via a small ribbon cable), any blocking is removed, and reattaching re-establishes the communication (i.e. also before all measures/workarounds implemented).

 

 

 

 

 

-Rob

 

i2c-bfin-twi.c

QuoteReplyEditDelete

 

 

2010-09-07 06:15:37     Re: I2C driver - trunk

Rob Maris (GERMANY)

Message: 93221   

 

Meanwhile I have a customer's feedback after having presented a linux image containing the driver modification. Read errors on I2C no longer result in hang-ups.

 

Please treat the modifications as test state. Of course the measures can be implemented a better way round.

QuoteReplyEditDelete

 

 

2010-09-22 11:45:15     Re: I2C driver - trunk

Rob Maris (GERMANY)

Message: 93755   

 

New fact:

 

Running with trunk while DCACHE is not in WRITEBACK mode makes very significant difference in terms of I2C reliability. In the case where I2C-bus communiation may have some susceptibility to errors, they become very frequent in Dcache writethrough mode. E.g. following error occurs frequently. i2c-0: smbus transfer timeout - just to inform about this.

QuoteReplyEditDelete

 

 

2010-09-25 03:04:46     Re: I2C driver - trunk

Sonic Zhang (CHINA)

Message: 93830   

 

Which smbus operation do you run in your test? What TWI baud rate do you use? Since TWI works only in PIO mode, it is possible that TWI interrupt is not handled in time occosationally, which may cause rx overflow, tx underflow or smbus restart failure. The attached patch tries to avoid rx overflow and tx underflow as much as possible. But, there is no easy way to avoid restart failure.

 

This patch is against SVN trunk. Please check if it helps.

 

i2c-bfin-twi-ignore-lost-interrupt.patch

QuoteReplyEditDelete

 

 

2010-09-28 11:10:06     Re: I2C driver - trunk

Rob Maris (GERMANY)

Message: 93914   

 

I'm using IC2_BLACKFIN_TWI with 150 kHz clock rate. What does PIO mode mean? AreTWI-peripheral resources not utilized as could be? Would you imagine 150 kHz as a too high rate?

 

The patch is not OK:

 

root: /> i2cset -y 0 0x45 2 31

Error: Write failed

 

See attached images, the correct case with three bytes. I did the test with trunk state of this source file for applying the patch.

 

Note: this trunk state, hence without the patch, still may hang sometimes (where I have to disconnect the 20 cm ribbon cable between main board and device board to stop the blocking), where my extra additions as documente above in this thread at least guarantees continued program flow.

 

i2cset_ok.png

patch_20100925.png

QuoteReplyEditDelete

 

 

2010-09-29 06:46:37     Re: I2C driver - trunk

Sonic Zhang (CHINA)

Message: 93969   

 

Is the writing fails through the MERR interrupt? If so, what the error bit?

 

PIO mode means a lot of interrupts if you transfer a large buffer. 150k means 150 x 128 = 19,200 interrupts per seconds. That's a lot of interrupts in a hash system. If the other higher priority interrrupt occurs frequency as well, several consequent TWI interrupts may be servered together later. Because SMBus transfer mode switching is also done in interrupt, lost interrupt may block the correct switch.

QuoteReplyEditDelete

 

 

2010-09-29 09:10:30     Re: I2C driver - trunk

Rob Maris (GERMANY)

Message: 93975   

 

Sonic: how can I view the error bit?

 

Interrupts: Indeed there are very many TWI interrupts. Will not be so much in the production app, but quite well in my worst case test app. I did some calculus, and my conclusion is: every byte transferred results in an interrupt. I checked the docs page, but this didn't give relevant infos regarding mode differences, since PIO-mode suggests that mode variances could be selected.

 

You write that circumstances can occur that "lost interrupts may block the correct switch". If this means: block the toplevel i2c function call, a timeout mechanism or the like should prevent this.

 

Another info: since about two weeks I found that not only heavier EMC stress seems to contribute to problems (SCL kept low, partially addressed with Hennerich-patch), but also other programs running with quite frequent interrupt usage, e.g. playing audio files. This fits with your suggestion.

Outcomes