7 years, 8 months ago.

DISCO-F746NG and I2C data length limit

Hello,

About 4 months ago, I asked this question:

https://developer.mbed.org/questions/68313/F746-I2C-data-transfer-size/

I don't know how to bring this question back up to the top of the heap, so I'm asking again.

I ran into this issue for a 2nd time now. Recently, I wanted to read the contents of a 24AA02 EEPROM. In order to read all 256 bytes of the EEPROM with a F746NG, it requires 2 separate I2C transactions. In the first operation I can get 255 bytes and in the second operation I get the last byte. If you try to read more than 255 bytes, all bytes are returned as 0xff.

This is not a problem in a KL25Z, K64F or nRF51822 - a single transaction of 256 bytes is possible.

Is this a hardware limitation in the F746NG?

Regards,

...kevin

1 Answer

7 years, 8 months ago.

Apparently on this MCU (and probably other STMs as well, but did not check), you need to set the amount of bytes that are going to be transferred at the start of the transaction. No idea how they do that with the byte-I2C mbed commands, but thats another question.

And as you probably can guess: While everything in the code is 32-bit, this actual length field in the hardware is 8-bit, limitting you to 255 bytes. It has a bit to allow it to continue directly afterwards with yet another 255 bytes (and etc), but that is not implemented in the mbed library. From the reference manual:

Quote:

If the total number of data bytes to be received is greater than 255, reload mode must be selected by setting the RELOAD bit in the I2C_CR2 register. In this case, when NBYTES[7:0] data have been transferred, the TCR flag is set and the SCL line is stretched low until NBYTES[7:0] is written to a non-zero value.

So it is a bit a hardware limitation: The hardware can do more, but that is not implemented in the mbed lib.

Accepted Answer

Thanks Erik,

I will go ahead and close both issues, knowing that this is a limitation of the device - just 1 more byte....

posted by Kevin Braun 27 Jul 2016