I2C HAL driver problem with HAL_I2C_Mem_Read_IT

[pavel-a]

Possible bug in HAL_I2C_Mem_Read_IT, reported in the forum.

In stm32f4xx_hal_i2c.c near line 4597

[ALABSTM]

Hi Pavel,

Thank you for this one other issue you reported. I will forward it to our development team for analysis. I will let you updated as soon as I get an answer.

With regards,

[ALABSTM]

Hi Pavel,

I hope you are doing well. Would you mind centralizing here the details that could be needed by our development teams to analyze this issue (board reference, IDE, compiler, and their versions)?

Thank you,

[JRASTM]

Hi,

In our development phase, we already manage, mean validate a latency treatment of different flags.

By the way, as a no regression we have run our test on a discovery STM32F412G-DISCO board with an external EEPROM @100Khz on I2C1/PB6/PB7 connection, and no issue detected by our tests.

Can you help us to reproduce the issue, by giving us more details like :

• which sensor did you use ?
• which speed did you use ?
• shared a schematic of your HW implementation ?

Thanks and regards

[pavel-a]

Hi Ali, Pinged the reporter on the forum. (link above). There may be a certain holiday in their part of the world, you know... -- p

[ALABSTM]

Hi Pavel,

No problem. We will wait till the reporter on the forum answers you. Thank you very much for your implication and your several contributions so far. We do appreciate.

With regards,

[zacwbond]

I'm not able to share a schematic, but we have an STM32F412RGT acting as an I2C master using I2C1 on PB8 (SCL) and PB9(SDA). The clock speed is 400 kHz. There are three slaves on the bus, and the one we are talking to when the problem occurs is an LIS2HH12TR accelerometer.

As described in the post, I think the problem is that HAL_I2C_EV_IRQHandler() can't manage the case where both TXE and BTF are set. If you can get TXE and BTF set at the same time, you should see the same lockup we're observing.

Probably you could use some higher priority ISR to inhibit handling the TXE interrupt long enough that BTF is set, too, and then see what happens when HAL_I2C_EV_IRQHandler() finally executes.

[JRASTM]

Hi,

Understood the hypothesis, but by double check the handler, in both case RXNE or TXE with a BTF, the most important flag checked is BTF thanks to the last part of if condition of RXNE or TXE.

Here is an extract, you can find that TXE is checked only if BTF is reset, if BTF set it is BTF flag condition that is execute : if ((I2C_CHECK_FLAG(sr1itflags, I2C_FLAG_TXE) != RESET) && (I2C_CHECK_IT_SOURCE(itsources, I2C_IT_BUF) != RESET) && (I2C_CHECK_FLAG(sr1itflags, I2C_FLAG_BTF) == RESET))

Now by checking the code of hal i2c versus current hal i2c in our development branch, there are some issues corrected around Mem HAL I2C interface.

Like this one in particularity : ST Internal Reference 50144 integrated in version FW package F4 V1.24.2 This bug have been found using hal mem interface in case an error occurs during exchange between slave.

May be an alignement with HAL I2C will solved the issue.

Regards, Jerome.

[zacwbond]

Hi Jerome,

I agree with what you're saying: if TXE and BTF are both set, then the BTF is what is handled by calling I2C_MasterTransmit_BTF(). My point is that I don't think that's what should happen in the memory read case.

Suppose you do a memory read by calling HAL_I2C_Mem_Read_IT(). That sets the state to HAL_I2C_STATE_BUSY_RX. The SB and ADDR interrupts get handled properly, so that the next expected interrupt is TXE after the read address is sent. But if handling of that TXE gets held off, then both BTF and TXE will be set.

When HAL_I2C_EV_IRQHandler() is finally called, the conditional that you describe results in the execution of I2C_MasterTransmit_BTF(). But because the state is HAL_I2C_STATE_BUSY_RX, that function becomes a no-op, the interrupts are not cleared, and they continue recurring forever.

Please explain if I am missing something in this execution sequence.

Thanks, -Zac

[JRASTM]

Hi and ok,

I will try to reproduce this situation and come back to you

Regards, Jerome.

[JRASTM]

Hi,

Come back with news, i have take time to try to reproduce the issue by adding a delay treatment in IRQ handler.

And i confirm your statement, there is well an issue between TXE and BTF introduce by a latency treatment of flag on time.

I will treat this issue and come back with a fix candidate.

Is it possible to raise an internal ticket to follow this issue ?

Regards, Jerome.

[ALABSTM]

Hi Jerome,

Thank you for your analysis. An internal bug tracker will be created.

With regards,

[ALABSTM]

ST Internal Reference: 80462

[JRASTM]

Hi all,

For your information, fix available and integrated in ST internal database.

Regards Jerome

[ALABSTM]

Hi everybody,

@JRLSTM, thank you for your answers and for the fix.

@pavel-a and @zacwbond, thank you for having reported this issue. The fix will not be available in the STM32CubeF4 v1.25.0 package, but in a later one. In the meanwhile, please find attached this patch.

We hope this solves the problem from your side. I think this issue could be closed now.

With regards,