Method to Provide Exclusive Access to a Shared I2C Bus Resource (I2C MUTEX)
Original Publication Date: 2002-May-08
Included in the Prior Art Database: 2003-Jun-21
In today's I2C bus structure there is no architected way to obtain exclusive access to any I2C bus resource. Any I2C master may read and write to any device without concern for what other agents may be doing. This may lead to a situation where a device that needs multiple separate transactions to perform an operation may be corrupted by multiple I2C masters accessing the device. This invention will allow multiple I2C masters that follow the "I2C MUTEX semaphore protocol" to arbitrate and gain exclusive access of a shared I2C resource. The invention is composed of an I2C based memory device, control logic to prevent multiple I2C masters from setting their semaphore bit and a protocol to ensure serialized access to a different I2C resource. The invention is built such that an I2C master can read and write data to the device using the standard Philips I2C protocol. To the I2C masters the invention looks like a standard I2C based memory device. The can support as few as two masters and is only limited in size by the number of I2C master that require access to the shared resource. Each I2C master is assigned a bit in the invention with the highest priority master owning the MSB. No two I2C masters can share a bit. Each I2C master is assigned a different bit since by the I2C arbitration rules, two different I2C masters can successfully write the same data to a device during the exact same I2C bus transaction. If a single bit were to be used, two I2C masters could presume that they each have exclusive access. To obtain a lock, the I2C master performs an I2C write transaction to the invention setting its semaphore bit to a zero and all other bits to a 1. The write transaction is allowed to span multiple bytes so the I2C master and invention must follow the I2C spec accordingly. If no other I2C master has previously requested a lock, the semaphore bit corresponding to the I2C master will be set to zero. If a different I2C master previously requested a lock, the write transaction will be halted by a NACK during the last data phase of the transaction. This NACK behavior will indicate to the current I2C master that the invention is already processing a locked transaction. If the I2C master does not get a NACK during the last data phase, it owns the I2C MUTEX. Alternatively, if the I2C master can not respond to NACKs in this manner or chooses not to, then the I2C master may read the invention to determine if its bit has been set. The master is then free to perform operations on the shared I2C resource. After completing all locked transactions the owning I2C master then writes all one's to the invention; this will clear the semaphore bit. The invention is then able to perform another lock. The invention will respond to read I2C transactions and indicate in the data stream which master owns the lock. Any master may reset the lock so that if a device malfunctions while holding the I2C MUTEX the lock can be reset. Masters must be careful not to inadvertently reset the lock.