Is there a bug in HAL_I2C_Master_Receive_IT (multiple interrupts during reception of last byte)?

[TClac.1]

I'm noticing lots of interrupts during reception of the last byte. Should there not just be one interrupt at the end of the last byte received?

The top trace in the following screenshot shows entry/exit to/from the I2C Event ISR.

[TDK]

Yeah, it seems a bit excessive. You could look at the I2Cx->SR1 bits to see why it's being triggered and go from there.

[TClac.1]

It looks like RxNE is not being cleared by reading DR?

Here is the log of events (SR) during a 2-byte read from a sensor:

[0] 0x00030001

[1] 0x00030002

[2] 0x00030040

[3] 0x00030040

[4] 0x00030040

[5] 0x00030040

[6] 0x00030040

[7] 0x00030040

[8] 0x00030040

[9] 0x00030040

[10] 0x00030040

[11] 0x00030040

[12] 0x00030040

[13] 0x00030040

[14] 0x00030040

[15] 0x00030040

[16] 0x00030040

[17] 0x00030040

[18] 0x00030040

[19] 0x00030040

[20] 0x00030040

[21] 0x00030040

[22] 0x00030040

[23] 0x00030040

[24] 0x00030040

[25] 0x00030040

[26] 0x00030040

[27] 0x00030044

[TClac.1]

...or will RxNE remain set as long as the receiving shift register is clocking-in data? If so, should ITBUFEN be reset for the last byte so that we just get the one BTF interrupt at the end?

[TDK]

I think it's a bug. RXNE isn't cleared so the IRQ keeps firing.

I tried to trace the logic in the default I2C event handler to find where the issue is, but it's pretty complex and I'm not that familiar enough with the I2C peripheral to do it quickly.

[TClac.1]

It seems the fix is trivial. Just don't enable the ITBUFEN interrupt in HAL_I2C_Master_Transmit_IT and HAL_I2C_Master_Receive_IT:

The resulting bus capture looks perfect:

It would be great if an ST engineer could comment on this and whether this is a sound solution.

[TClac.1]

...on reflection, this can't be a proper solution. There is no interrupt when the first byte of two has been received.