Issues with i2cm.h and cfa.h API for I2C EEPROM I/O

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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.

Thanks!

Eric

1 Solution
Anonymous
Not applicable

Thanks J.T. but we have tried what you suggest and it does not appear to work as advertised.

If you have been able to get this to work as described, then I wonder how your method is different than ours.

I just realized that our write protect pin is connected to P26 and P26 is bonded with P12 and we have not disabled P12.

I'm going to disable P12 and see if it makes any difference.

What I have found is that cfa and i2cm behave exactly the same, and in other threads I have seen it written that they ARE the same thing under the hood.. so if you could please clarify why you think cfa should work when i2cm doesn't that would be helpful.

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

One of my comrades just informed me that the SDK we are using is 2.2.1 (not 2.1.1).. just in case it matters.

0 Likes
Anonymous
Not applicable

Hello Eric,

1.  You are correct - 14 bytes is the limitation.

2.  I2cm.h will not do what you want in this case.

3.  The cfa.h will be able to split it up into larger transmission packets.

4.  This should work - it should send it out in 14 byte chunks.

Hope this helps

JT

Anonymous
Not applicable

Thanks J.T. but we have tried what you suggest and it does not appear to work as advertised.

If you have been able to get this to work as described, then I wonder how your method is different than ours.

I just realized that our write protect pin is connected to P26 and P26 is bonded with P12 and we have not disabled P12.

I'm going to disable P12 and see if it makes any difference.

What I have found is that cfa and i2cm behave exactly the same, and in other threads I have seen it written that they ARE the same thing under the hood.. so if you could please clarify why you think cfa should work when i2cm doesn't that would be helpful.

0 Likes