Closed HYP96 closed 3 weeks ago
Hello @HYP96,
Thank you for your contribution. I believe you have opened the issue twice, which is a duplication of https://github.com/STMicroelectronics/stm32f4xx_hal_driver/issues/32 . Please close one of them.
Thank you.
Have you tested the HAL library using the AT24 series EEPROM chip or the MB85RC series FRAM chip? In my tests with an oscilloscope, the code is completely unusable and should be discarded. The reason is that 0x00 is written to the chip by mistake. This is an obvious disaster, and you could have cleaned up after the data was sent and received, not in the middle of the transfer. I don't know why you would rather make your code unusable than fix it or roll it back. @RJMSTM @ALABSTM @KRASTM
Hi @HYP96,
As explained by @KRASTM in #32, we could not reproduce the issue you described. Hence, we cannot consider our driver as faulty. Please allow us to close this thread again. Thank you for your comprehension.
With regards,
This change causes a serious issue: when using the
HAL_I2C_Mem_Read_IT(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size)
function, it enters an interrupt to sendDevAddress
andMemAddress
. However, whenI2C_MemoryTransmit_TXE_BTF
finishes sending and [hi2c->EventCount
] is greater than 2, it enters theI2C_Flush_DR(I2C_HandleTypeDef *hi2c)
function, causing an additional 0x00 to be sent, which prevents reading data from the EEPROM. Therefore, this place should not clear the DR, and all HAL library I2C functions should not perform the operation of clearing the DR register.