From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reinhard Meyer Date: Wed, 5 Mar 2003 06:42:59 +0100 Subject: [U-Boot-Users] I2C Initialization References: Message-ID: <05ff01c2e2da$20817c60$6d4ba8c0@alb.sub.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Its one of the trickiest things at all... For I2C Reset it is adviseable to cause at least a sequence of eight STOP one START and another STOP condition. Some Manufacturers (Microchip when I remember correctly) require that because in violation of the I2C Spec they do not recognize a STOP condition while expecting the Bits of a Byte. Otherwise you might end up writing an arbitrary value the last addressed location in your I2C memory if the previous transfer has been interrupted in an unfortunate state... (see also I2C Edge Conditions, which addresses a part of the Problem). I know it doesn't help you, but we put our Vital Product Data section in a part of the EEPROM that can be protected against writes by keeping the WP pulled high (ATMEL 24LC64: 6kb always writeable, 2kb protected). The test adapter will pull it low so it can be programmed during testing. In order to do that you need TWO general purpose I/O Lines. Its simple with the MPC8xx series, since the I2C Bus Pins can also be used as general purpose I/O lines. Can't you somehow directly control your I2C lines through the processor? ((Note to myself: check whether the SOFT_I2C driver in u-boot does that kind of init, if NOT add it?)) A wild idea might be to conditionally power the I2C devices to cause them a power-on-reset... Reinhard > This is an interesting topic, because I am actually > seeing I2C bus hangs on our own custom hardware > once and a great while. This hardware is PowerPC > based but doesn't use u-boot. I kind of narrowed > it down to the processor getting reset during > an I2C transaction. Since the slave device (EEPROM with a temp > sensor in it) doesn't have a reset, the bus gets stuck > low and when a master tries to start a new transaction > it can't because the bus appears busy. > > Which line did you attach a GPIO pin to? The clock or the data? > It seems that this would be a good generic solution to this > particular part of the problem to simply clock the slaves back to > a known state. I'm not sure if I've seen corruption as mentioned in the > I2C_Edge_Conditions doc. > > I was thinking, in my design, since I have independent control of the > reset to the processor subsystem in hardware, To make the code set a bit > which gates the reset to the processor subsystem while doing I2C accesses. > When the access(es) finish the bit would be cleared and then the reset would > be > allowed to take effect. This of course is very hardware specific, but just a > thought > I had. What _IF_ your systems hangs during that phase?