Closed jelledevleeschouwer closed 2 years ago
Hi @jelledevleeschouwer,
Glad to read from you again. Glad also to know the previous HAL release addressed the EXTI reset issue.
As for I2C topic, @ASELSTM is the one in charge and will handle this issue.
With regards,
Hi @jelledevleeschouwer,
First we would like to thank you for your contribution and for this detailed report. It has been forwarded to our development teams. We will get back to you as soon as they provide us with their feedback.
With regards,
ST Internal Reference: 120754.
Hi @jelledevleeschouwer,
A fix has been implemented and made available in the frame of the latest stm32l0_hal_driver V1.10.5 release. Please allow me then to close this thread. You can reopen it at any time if you still detect this issue.
With regards,
Dear @ALABSTM,
It seems you released a new HAL with a fix for #1, great! :+1: I do have another bug to report, however:
Set-up
Description When a NACK is observed during memory address transfer, it goes undetected until the next I2C transaction, and the I2C HAL produces a
HAL_I2C_ERROR_TIMEOUT
error rather than aHAL_I2C_ERROR_AF
error.We have observed a situation in which a I2C slave device NACK's a memory address (see sreenshot 1 below). However it seems the I2C hal cannot cope with this situation. When this occurs, the I2C driver is waiting for the
TC
bit to high in case a of a MemoryRead operation:stm32l0xx_hal_i2c.c:5266:
However, since the NACK occurs this operation times out. If we inspect the I2C peripheral register contents when this occurs, we observe:
But we don't notice any of that because the I2C HAL doesn't check for that NACKF anymore, we just observe a timeout and we get on with our business, but the next time we request an I2C read transaction the following occurs: the HAL I2C driver requests a memory read with I2C_RequestMemoryRead() wherein the transaction is initiated by configuring the transfer and generating a start condition, after which the driver waits for the Transmit interrupt status bit to become set (TXIS). In the subroutine responsible for this the NACKF status bit does get tested:
stm32l0xx_hal_i2c.c:6256:
Since the NACKF is still set from the previous I2C transaction, this new I2C transaction will be prematurely aborted, while the start condition and slave address will already be transmitted on the wire. If we inspect the register contents if has happened we observe:
Since the NACK was already detected during previous I2C transaction the STOP condition was already generated during previous I2C transaction (see register contents above). But now the current I2C transaction is prematurely aborted, in combination with the fact that the START condition and the I2C device address has already been transmitted on the wire, the BUSY flag is set high! Which prevents any further I2C transactions to be request from the HAL. This will generate timeout issues at each subsequent i2c_mem_read request:
stm32l0xx_hal_i2c.c:2450:
So I propose to please add a NACKF detection to memory address transfer phase as well, either by adding an additional call to
I2C_WaitOnTXISFlagUntilTimeout()
or by extending theI2C_WaitOnFlagUntilTimeout()
function with a test forNACKF
.What do you think is best?
Thanks, Best regards,
Jelle De Vleeschouwer
Screenshots