stm32_common/i2c_2: Fix repeated read condition

[MrKevinWeiss]

Contribution description

Fix the condition to return -ENOPNOTSUPP when i2c repeated read attempted.
Currently the error occures even if a read after write is attempted.
This is the standard way to i2c_read_reg which should be supported.
The -EOPNOTSUPP requires the previous R/W state to be reading.
This means a I2C_SR2_TRA must be checked to be 0.

This bug was caught by @aabadie with and using saul in iotlabs testbed.

Testing procedure

To test you can use the iotlab-m3 and test the lps331ap driver:

BOARD=iotlab-m3 IOTLAB_NODE=<my_iotlab_node> make flash term -C tests/driver_lpsxxx/

To ensure the no support error is correctly working:
BOARD=iotlab-m3 IOTLAB_NODE=<my_iotlab_node> make flash term -C tests/periph_i2c/

> i2c_write_bytes 0 0x5C 4 0x0F
Success: i2c_0 wrote 1 bytes
> i2c_read_bytes 0 0X5C 1 0
Success: i2c_0 read 1 byte(s) : [0xbb]
# This means i2c_read_reg is now fixed

> i2c_read_bytes 0 0x5C 1 4
Success: i2c_0 read 1 byte(s) : [0xbb]
> i2c_read_bytes 0 0x5C 1 0
Error: EOPNOTSUPP [95]
# This means the desired error code is still returned

Also testing procedure is documented in #12564

Issues/PRs references

Fixes #12564
Request to add test for CI RIOT-OS/RobotFW-tests#39

[MrKevinWeiss]

@aabadie ya, I don't know what I was thinking... Sorry. Also weird that the CI didn't catch that. I will have to look into that.

[aabadie]

I confirm #12564 is fixed by this PR. Thanks for tackling it so quick.

[MrKevinWeiss]

Thanks for finding it, silly mistake on my part.

[aabadie]

Reasoning for the fix is OK and comment is explaining it.

Before approving, it would be great to verify other affected STMs are also working (F2, L1, F4). But maybe this is not mandatory ?

[MrKevinWeiss]

They typically have the same base register map...
Checking the following reference manuals I can see that bit available:
[x] stm32f205
[x] stm32l152
[x] stm32f411

[aabadie]

Then let's go.

ACK

[MrKevinWeiss]

❤️