Hi, On Tue, Dec 04, 2007 at 04:45:12PM +0100, Wolfgang Wegner wrote:
I just found out what happens in this case: > Now I still have the problem that from time to time, the I2C bus gets > stuck and I can only revive it by resetting the processor (because > I did not find out what exactly happens). The error message is > > coldfire_i2c_start - I2C bus always busy in the past 500us timeout is -1 The coldfire somehow misses an acknowledge from a slave when it tries to read. There is no error handling, the transfer is simply aborted. However, the slave did react and is already switched to read - thus pulling SDA low. When the next transfer is started, the coldfire does find a pulled-low SDA lilne and aborts because it can not get bus mastership. I am not yet sure what exactly is the reason for the coldfire not getting the ACK from the slave, but there is a pitfall in the current I2C driver: waiting for the transfer to finish is done in a busy-wait loop with a fixed counter, which was originally implemented for an MCF5282. The MCF532x/537x is much faster, so probably the timeout is too short. I have modified the driver to have this timer configurable which seemingly improved the situation. I also tried interrupt-driven operation, but this did not change anything. Then I also introduced some quite stupid error handling to always perform a dummy read with NACK in case a read or address phase for read failed, but after introducing this, the problem did not yet occur again. (There is some printk in case this happens, but it did not show up yet.) In case somebody is interested, you can find the code at http://leila.dyna.ping.de/wolfgang/i2c-mcf.c (I do not have the proper environment to generate a patch at the moment, and it is work in progress, too, so I think this would not really be useful. Interrupt-driven operation is only implemented for MCF532x for now) Best regards, Wolfgang _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
