Other Parts Discussed in Thread: CC2640, LAUNCHXL-CC2640R2
Hi,
SDK Version: 2.30.00.08
In the our application, the CC2640 is the only I2C master on the I2C bus, talking to 3 slave devices. We can get into a state where the I2C peripheral's MSTAT.BUSBSY bit is stuck high by injecting noise into the I2C lines (quick bursts of shorts to ground). This makes sense because the I2C peripheral thinks that another master is talking on the bus due to the noise on the bus. Once we get into this state, subsequent calls to I2C transactions fail due to MSTAT.BUSBSY being set. During this state, both SCL and SDA lines are at high. We have external pullups on the I2C bus.
My question is how do we reset the CC2640's I2C peripheral's MSTAT.BUSBSY bit after this noise event on the I2C bus? It seems that disabling and then enabling the I2C peripheral via the I2C_close() and I2C_open() function calls, respectively, does not clear the bit. Since the I2C driver handles removing the I2C dependency on the Serial Power Domain and I am not using the UART or SSI peripherals, I am making the assumption that the I2C is not powered after the call to I2C_close(). If this is the case, shouldn't all registers, including the MSTAT.BUSBSY bit, be reset on the next call to I2C_open(), which would power on the I2C peripheral via the Serial Power Domain? I know that performing a full system reset will reset the bit, but we are trying to avoid doing that.
One way that I was able to reset the bit was to externally toggle the SDA low and then high, while the SCL line is high, a STOP condition. Once the CC2640 see this, subsequent transactions succeed. This matches with the idea that the I2C peripheral thinks that another master is driving the bus. However, there is only one master on the bus and this solution will require a hardware solution which is not ideal. We are looking for a software solution to this problem that does not require a full system reset.
Any thoughts? Looking forward to your reply!
