I've been working with MQX's I2C drivers. First, I think it's clever how the I2C driver was worked into standard fio driver, and this model works well. However, both using the driver an examining the operation and code I am somewhat concerned.
Understand that I2C is one of the most delicate and fragile busses out there. If you aren't convinced of this I can point to entire design notes (practically a thesis) talking about the correct pull-ups to use on the bus. If you actually work though all the formulas, tolerances, capacitance, slew rates, etc, you find that there is no proper value of of pull-up that will actually meet all the criteria. Couple this with the 5 and 3V busses, trace lengths, conflicting documentation, variations between manufactures devices, etc. It's amazing or works at all. But is does generally work, and it is a compelling bus to use nonetheless.
So the thing is that the driver needs to be really robust, and expect things to go wrong on the bus... more so for I2C than any other basic serial communication bus. In using the MQX driver I have noticed a few things:
The interrupt driven I2C driver still relies on components from the polled I2C driver, specifically in the area of IOCTL. In the polled IOCTL code there are numerous busy polls waiting on a hardware register state change. However, I don't know that in every case the resister is guaranteed, by design or configuration, to change.
To hit one of these simply try to write to a device that is not there and flush the stream. It will get stuck here forever in i2c_pol_ki2c.c:
while ( I2C_S_BUSY_MASK == ((tmp=i2c_ptr->S) & (I2C_S_BUSY_MASK | I2C_S_TCF_MASK)))
In the driver simply search for every instance of 'while' that is coupled with the polling of a hardware register for a state change (there are seven of them in i2c_pol_ki2c.c). In every case is the register guaranteed to hit the terminal condition? My experience thus far says the answer is no.