I2C - long term stability problems?


I’m currently working on a project, which uses the Q2687H. The Q2687H is communicating with a number of i2c devices, which generates about 500 bytes/s, which should be within the theoretical maximum for the I2C bus at 100 kHz.

My driver works as follows:

  1. Initialize the I2C bus, by making one bus subscribe for each device on the bus, e.g. handle1 = adl_busSubscribe(…, 0x01, …); handle2 = adl_busSubscribe(…, 0x02, …); handle3 = adl_busSubscribe(…, 0x03, …);
  2. When a specific event happpens, e.g. an external interrupt received from one of the i2c devices, read data from the device, using adl_busRead(handlex, …, &databuffer); and the propagate it to the target functions in my application software.
  3. Unsubscribe using adl_unSubscribe.

The driver runs in its own thread and messages are used between threads.

With my software, I am able to run it for up to 20 hrs before I2C communication crashes, sometimes less, only 2-3 hours. When the I2C communication chrashes, no errors are generated, I simply just start getting random data from the i2cHandle. My guess is that the wavecom OS bus/i2c service has chrashed - the SDA pin is kept low, and no data is propagated through the bus, while at+wopen=7 responds that the software is running in target mode (the other threads are not halted, i still get information from them).

The solution is to pull the power from the board, resetting everything :s

My questions are now:

  1. Is the subscribe at program start, wait for event to occur, read data, unsubscribe at program termination the correct way of using the bus service, or should the bus operations be “atomic”, e.g. when the event occurs, where data is needed to be written then do:
    return OK

  2. What are your experiences with devices that use execessive clock stretching ? I have one slave which can halt the bus for at least 3 - 500 us - could this have an impact on the bus event service in the wavecom OS ? e.g. the bus service crashes due to bus access violations by a slave.

With friendly regards,

i remember having problems with any clock stretching.
my solution was removing the offending device from the I2C bus altogether (i’m using it on SPI now)

so i never really got into debugging the problem.