New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I2C HAL driver problem with HAL_I2C_Mem_Read_IT #7
Comments
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, |
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, |
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 :
Thanks and regards |
Hi Ali, |
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, |
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 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 |
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 : 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 May be an alignement with HAL I2C will solved the issue. Regards, |
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 Suppose you do a memory read by calling When Please explain if I am missing something in this execution sequence. Thanks, |
Hi and ok, I will try to reproduce this situation and come back to you Regards, |
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, |
Hi Jerome, Thank you for your analysis. An internal bug tracker will be created. With regards, |
ST Internal Reference: 80462 |
Hi all, For your information, fix available and integrated in ST internal database. Regards |
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, |
Possible bug in HAL_I2C_Mem_Read_IT, reported in the forum.
In stm32f4xx_hal_i2c.c near line 4597
The text was updated successfully, but these errors were encountered: