[BUG] Nuked an important but in I2Cv2

[Giovanni]

I fixed an important but to the I2Cv2 driver in 3.0.0, before back-porting the fix to 2.6.x I wish some feedback.

If you had problems with that driver in the past then it could be a good idea to give it a try again.

Giovanni

[steved]

I've not had any particular problems with I2CV2, but I'll give it a try for you - I can test tickless mode, USART2 and I2C all on one set of hardware. It'll be a good test for I2C; I've got both ports on a 32F051 running fairly flat out, each driving a one-wire bus.

[Giovanni]

The problem was triggered by two [url]very close[/url] consecutive calls to I2C transmit functions.

I noticed with an application working with -O0 and failing with -O2. One of the interrupts of the first call was served within the "wait-for-busy-to-go-zero" loop of the second function bringing the driver in the locked state.

Giovanni

[Giovanni]

The driver still has a limitation, transfers above 255 bytes are not possible in the current implementation. Talking of I2C, how often are larger transfers required? are there real world use cases for that?

Giovanni

[steved]

The driver still has a limitation, transfers above 255 bytes are not possible in the current implementation. Talking of I2C, how often are larger transfers required? are there real world use cases for that?
Giovanni

I'm sure there are real world use cases; I tend to avoid them, because I often have a number of peripherals on a single bus, all of which need servicing in real time (albeit not lightning quick real time). So more than a few 10s of bytes is going to hold things up, especially as I stick to 100KHz because of rather long cables.

There's potentially a bigger problem in slave mode (which I have encountered) which is that if you have just received a large buffer to process, you have to rapidly copy it somewhere else befoe processing it, to avoid locking up the bus for long before acknowledging. Then you can get overruns...

So I don't find 255 bytes a limitation, although just occasionally a round 256, or maybe 260 (256 bytes of data plus address/size or similar) would be useful.

On the bug you fixed, I do remember coming across I2C lockups, mostly while debugging; usually solved by fixing my own code. But I mostly run with -O0. However I've run out of memory for that, so the current code is compiled with -O2.

[Giovanni]

I made more changes to the I2Cv2 driver, hopefully for the better.

1) It does no more use DMA callbacks, should generate way less interrupts.
2) It supports transfers >255 bytes but I haven't tested it yet.
3) I added some recovery code in case of SW timeout in order to release the bus by sending a STOP.
4) Code should be smaller.

Giovanni

[steved]

Just noticed an inconsistency in the latest i2c_lld.h header; around line 283 we have:

Code: Select all

  /**
   * @brief   Current transfer size.
   */
  i2caddr_t                 tsize;

The previous version I have said:

Code: Select all

  /**
   * @brief     Current slave address without R/W bit.
   */
  i2caddr_t                 addr;

That doesn't look right! (Not tested yet)

[Giovanni]

That "addr" field was not used at all so I removed it, "tsize" is new.

Giovanni

[rew]

I would guess that you can transfer a bunch of bytes to an eeprom in one write to the device. Writing 256 bytes in one go would then be useful. (even though others might have real time constraints that would NOT allow this). Anyway, already implemented good!

[mati]

It is my first post here
May I ask what is the status of I2Cv2 slave library (ChibiosOS 3) for STM32F0x2.

Sorry for my english.