STM32 I2C Target v2 read transaction consumes one extra byte

[AntoineGL]

Describe the bug
With STM32 v2 I2C Target: when a master requests to read N bytes, the zephyr i2c target callbacks end up requesting 1 extra byte.
Ex: Master wants to read 3 bytes, on target I observe 1 call to read_requested then 3 calls to read_processed => 4 bytes has been consumed.
This has been reproduced with Zephyr 3.3.0 and latest version of Zephyr and does not seem to be a regression.
Reproduced with a nucleo_g0b1re and a nucleo_f070rb.

Using an i2c analyzer, I observe that the correct number of bytes are read by the master.

This seems to be an issue with the TXIS flag. When this flag is set during an i2c event, it immediately triggers a call to read_processed (drivers/i2c/i2c_ll_stm32_v2.c function stm32_i2c_slave_event).
The issue is this flag only indicates that the last byte has been consumed, not that master requests another byte.

I have tried to add additional checks before calling read_processed (no stop condition nor NACK received) but it does not solve the issue as it seems that TXIS is set before master NACK or send stop condition.

To Reproduce
Steps to reproduce the behavior:

1. Take a board with an STM32 MCU that uses stm32 i2c v2 driver (stm32g0b1, stm32f070 ...)
2. Build an app that declares an i2c target with at least read callbacks for this board, and put some logs in read or stop callback to know how many bytes have been consumed.
3. Use any i2c master to perform a read of N bytes on the target.

Expected behavior
N bytes should be consumed on the target, not N + 1.

Impact
This extra byte read is lost (not received by master but considered sent by the target).

[aurel32]

I think this is by design of the I2C target API. The callback function is called when a byte has just been read by the controller (master in the old terminology) but before the ACK. It is both used to define the next byte and decide if the target should send a ACK or NACK, i.e. if it will accept more read or not. But at that moment the controller is free to stop the transaction, which is what you observe.

Therefore I think this is just a documentation issue and not specific to STM32.

[aurel32]

To add more data point, the behaviour matches the name i2c_target_read_processed_cb_t. In your case you observe 3 reads processed, which matches the number of reads the controller has done.

[AntoineGL]

Hello aurel32, thank you for your answers.

However, it is not the target that "should send a ACK or NACK", it is the master which ACK or NACK data. This callback i2c_target_read_processed_cb_t is "called when a read from the device is continued" (from documentation). The driver should wait for ACK before requesting the next byte, because it can't tell whether the read is continued or not without it.

When you read the STM32 I2C Target v1 implementation, you can see that there is an extra flag checked ("BTF": Byte transfer finished) that does not exist in v2 (and this flag is not set if a NACK is received).
There are others drivers such as lpc11u6x that wait for the ACK to call this callback.

I have also tested with a lpc55s69 board, and when master reads 3 bytes, there is 1 call to i2c_target_read_requested_cb_t and 2 calls to i2c_target_read_processed_cb_t, not 3 !

[aurel32]

Hello aurel32, thank you for your answers.

However, it is not the target that "should send a ACK or NACK", it is the master which ACK or NACK data. This callback i2c_target_read_processed_cb_t is "called when a read from the device is continued" (from documentation). The driver should wait for ACK before requesting the next byte, because it can't tell whether the read is continued or not without it.

Indeed you are correct about who send the ACK/NACK and about the API documentation. The name in the API is really poorly chosen then, it should have been i2c_target_read_continued_cb_t instead...

When you read the STM32 I2C Target v1 implementation, you can see that there is an extra flag checked ("BTF": Byte transfer finished) that does not exist in v2 (and this flag is not set if a NACK is received). There are others drivers such as lpc11u6x that wait for the ACK to call this callback.

I have also tested with a lpc55s69 board, and when master reads 3 bytes, there is 1 call to i2c_target_read_requested_cb_t and 2 calls to i2c_target_read_processed_cb_t, not 3 !

Thanks for checking. The problem on the STM32 is that the TXIS basically means that the transmit buffer is empty, so it happens even before the controller is sending the ACK/NACK. The STM32 v1 implementation uses the BTF interrupt flag (Byte Transfer Finished) for that, but it doesn't exist on the STM32 v2 implementation (there is only one for a NACK). Therefore I don't see an easy way to fix that.

[erwango]

@AntoineGL Is this issue still valid ?

[AntoineGL]

I think it is more like a chip family issue than a zephyr implementation issue, but there might be a workaround that I did not find.
In any case, there is a lost byte so still an issue :(

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.