diff options
author | wdenk <wdenk> | 2002-03-08 23:25:32 +0000 |
---|---|---|
committer | wdenk <wdenk> | 2002-03-08 23:25:32 +0000 |
commit | 6fcc18e0a92788073c9c869ed2ff86a2f44bdce9 (patch) | |
tree | 0bce6013bcc0c6daf1a435470146f0dcc6bcc3e0 /doc/I2C_Edge_Conditions | |
parent | ae6448002a5638aa7226e54f9e4807e917868c64 (diff) | |
download | u-boot-imx-6fcc18e0a92788073c9c869ed2ff86a2f44bdce9.zip u-boot-imx-6fcc18e0a92788073c9c869ed2ff86a2f44bdce9.tar.gz u-boot-imx-6fcc18e0a92788073c9c869ed2ff86a2f44bdce9.tar.bz2 |
Initial revision
Diffstat (limited to 'doc/I2C_Edge_Conditions')
-rw-r--r-- | doc/I2C_Edge_Conditions | 41 |
1 files changed, 41 insertions, 0 deletions
diff --git a/doc/I2C_Edge_Conditions b/doc/I2C_Edge_Conditions new file mode 100644 index 0000000..91557a3 --- /dev/null +++ b/doc/I2C_Edge_Conditions @@ -0,0 +1,41 @@ +I2C Edge Conditions: +==================== + + I2C devices may be left in a write state if a read was occuring + and the CPU was reset. This may result in EEPROM data corruption. + + The edge condition is as follows: + 1) A read operation begins. + 2) I2C controller issues a start command. + 3) The I2C writes the device address. + 4) The CPU is reset at this point. + + Once the CPU reinitializes and the read is tried again: + 1) The I2C controller issues a start command. + 2) The I2C controller writes the device address. + 3) The I2C controller writes the offset. + + The EEPROM sees: + 1) START + 2) device address + 3) START "this start is ignored by most EEPROMs" + 4) device address "EEPROM interprets this as offset" + 5) Offset in device, "EEPROM interprets this as data to write" + + The device will interpret this sequence as a WRITE command and + write rubbish into itself, i.e. the "offset" will be interpreted + as data to be written in location "device address". + +Notes +----- +!!!THIS IS AN UNDOCUMENTED I2C BUS BUG, NOT A IBM 4xx BUG!!! + +This reset edge condition could possibly be present in every I2C +controller and device available. We should probably have a bus reset +function for all our target CPUs. + +Many thanks to Bill Hunter for finding this serious BUG. +email to: <williamhunter@attbi.com> + +Erik Theisen <etheisen@mindspring.com> +Tue, 5 Mar 2002 23:02:19 -0500 (Wed 05:02 MET) |