Possible bug with i2cdevWrite - sending a single byte of data, sends two bytes

[amitga]

Hi.
I recently ran into a problem while sending a single byte of data using i2cdevWrite:
My goal is to send/write a single byte of data to an I2C slave (no internal address/register).
When I send like this: i2cdevWrite(I2C_DeckBus, devAddr, 1, &myByte); actually my byte (uint8_t) value is sent as one byte, but there is also another empty (zero) byte sent immediately after that byte (within the same data transfer it seems).

I have confirmed this with various MCUs acting as an I2C slave (Arduino, PIC16f...).
This also happend if the data is a buffer/array of data, but we send 1 as the requested length.
If we choose to send more than 1 from a buffer, all works as expected.

I have looked into the code, and it seems related to the ISR handling the I2C events.
Specifically here:

crazyflie-firmware/src/drivers/src/i2c_drv.c

Line 567 in ef06e40

if(i2c->messageIndex == i2c->txMessage.messageLength)

I think that the problem may be that the messageIndex is not initialised/reset when that single byte is sent.
I added i2c->messageIndex = 0; right after:

crazyflie-firmware/src/drivers/src/i2c_drv.c

Line 570 in ef06e40

I2C_ITConfig(i2c->def->i2cPort, I2C_IT_BUF, DISABLE);

and it seems to solve the problem: working with sending a single and multiple bytes, as stated in data length when calling i2cdevWrite function.

But, I'm still not sure why this would happen in the first place, or if my quick fix is correct or can cause some other side-affects.

I would like to hear your thoughts about this.
BTW, I'm running a CF Bolt with a bit dated firmware, but its seems that the ISR logic hasn't changed much in master branch compared to mine (they are basically identical). I cannot confirm if this bug happens with newer/latest firmware (I would have to re-write my custom code).

Thanks!

[knmcguire]

Hi Thanks for notifying us on this! It seem that this should not happen, but we will discuss it internally why this happens. Probably we can give you an update on that next week.

[amitga]

Thanks!

[knmcguire]

Hi, sorry we were not able to handle this issue during this week's triage meeting so it will be the next, so that is 3 weeks (29th of March).

Hope this will not block your development too much, but if it does, please let us know.

[amitga]

Thanks.
Just an update: I ended up using i2cdevReadReg8 instead, which seems to work correctly (doesn't send an additional byte).

[knmcguire]

thanks for the update! good that this works for you and this will be useful information for us to figure out what is wrong

[whoenig]

Not sure if it's related, but https://github.com/bitcraze/crazyflie-firmware/tree/dev-systemId had some fixes(?) for I2C that we never ended up merging back to master, due to limited testing.

[tobbeanton]

I tested and could replicate this today. The strange thing is that any instruction after I2C_ITConfig(i2c->def->i2cPort, I2C_IT_BUF, DISABLE); fixes the problem. The STM32F405 I2C peripheral is bugged and this might be one of them. My guess is that the TXE interrupt isn't cleared fast enough or similar and gets called again which send another byte on the buss.

[tobbeanton]

Fixing this with an added instruction is as good as it gets right now.

[amitga]

Thanks for the updates!