We are finding in our BCM20736S application (on SDK 2.1.1) which has an external I2C EEPROM the following issues/observations regarding the I2C API in the SDK: (Note: we are using a garden variety Atmel 512Mbit eeprom)
1. Both i2cm.h and cfa.h work for reading and writing but only up to 14 bytes of data (two bytes of address for a total of 16). Attempting to write 15 or 16 bytes of data (or anything larger) always fails.
2. The header files advertise that longer byte strings are supported but that they break them into separate 16 byte transactions. We are finding that this is not the case, and the functions don't work as advertised. Only a single 16 byte transaction per function call is working (14 data bytes for the write).
3. In any case, what we need is to write 128 bytes (page write to eeprom) of data in a single transaction. This is not supported but needs to be as it is very inefficient to write to eeprom in other than page mode. (We buffer data in RAM and write to EEPROM in full page chunks.)
4. The cfa.h and i2cm.h function calls do not always work on the first try. We have found success by embedding the calls in a loop with a max iteration of 20 with a wait of 1 millisecond between calls. Exiting the loop when the return status is SUCCESS or max iterations reached. This seems to be related to the internally timed page write cycle of the eeprom device, but it's not clear how. The eeprom datasheet puts maximum write time at 5 milliseconds. The 1mS waits appear to be needed for the i2cm loop but not the cfa loop. The loop coded with cfa.h and no waits (and no traces) typically completes successfully after no more than 16 iterations. The i2cm loop with a 1 mS wait completes with success status in 2 or 3 tries).
5. changing the I2C speed with i2cm_setSpeed() did not seem to affect the above performance. Using divisors of 240 (100kHz) and 60 (400kHz) both worked the same. I will need to check with an oscilloscope to be sure the set Speed worked as advertised. Have not done so yet.
6. Would like if Broadcom could expose some lower level I2C interface so we could write our own driver that supports page writes.