mimxrt10xx: Wrong I2C transfer status

[loicpoulain]

Describe the bug
When running samples/drivers/i2c_scanner, application wrongly reports slaves found on multiple addresses. It is actually due to transfer success instead of failure. Interesting to note that only odd addresses are reported. Logic analyzer screenshot below.

To Reproduce
Steps to reproduce the behavior:

1. cd samples/drivers/i2c_scanner
2. west build -b mimxrt1064_evk

Expected behavior
Only connected slave reported
I2C transfer failure on NAK

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Screenshots or console output
***** Booting Zephyr OS v1.14.0-rc1-458-g41dad49 *****
Starting i2c scanner...
0x 5 FOUND
0x 7 FOUND
0x 9 FOUND
0x b FOUND
0x d FOUND
0x f FOUND
0x11 FOUND
0x13 FOUND
0x15 FOUND
0x17 FOUND
0x19 FOUND
0x1a FOUND
0x1c FOUND
0x1e FOUND
0x20 FOUND
0x22 FOUND
0x24 FOUND
0x26 FOUND
0x28 FOUND
0x2a FOUND
0x2c FOUND
0x2e FOUND
0x30 FOUND
0x32 FOUND
0x34 FOUND
0x36 FOUND
0x38 FOUND
0x3a FOUND
0x3c FOUND
0x3e FOUND
0x40 FOUND
0x42 FOUND
0x44 FOUND
0x46 FOUND
0x48 FOUND
0x4a FOUND
0x4c FOUND
0x4e FOUND
0x50 FOUND
0x52 FOUND
0x54 FOUND
0x56 FOUND
0x58 FOUND
0x5a FOUND
0x5c FOUND
0x5e FOUND
0x60 FOUND
0x62 FOUND
0x64 FOUND
0x66 FOUND
0x68 FOUND
0x6a FOUND
0x6c FOUND
0x6e FOUND
0x70 FOUND
0x72 FOUND
0x74 FOUND
0x76 FOUND

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK

[MaureenHelm]

I haven't gotten to the bottom of this yet, but it seems to be some kind of timing problem or race condition. If I step through the i2c driver with a debugger, the nack conditions are handled correctly and I don't get all the false positives.

[KwonTae-young]

I also have the same symptom on the stm32f4_disco board.
In my case, I changed the source as shown below and it is displayed properly.

diff --git a/samples/drivers/i2c_scanner/src/main.c b/samples/drivers/i2c_scanner/src/main.c
index 44c1724377..029dd176b5 100644
--- a/samples/drivers/i2c_scanner/src/main.c
+++ b/samples/drivers/i2c_scanner/src/main.c
@@ -38,7 +38,7 @@ void main(void)
 
                /* Send the address to read from */
                msgs[0].buf = &dst;
-               msgs[0].len = 0U;
+               msgs[0].len = 1U;
                msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;
 
                if (i2c_transfer(i2c_dev, &msgs[0], 1, i) == 0) {

[before]

***** Booting Zephyr OS build zephyr-v1.13.0-8609-g9481527d20df *****
Starting i2c scanner...
0x 4 FOUND
0x 5 FOUND
0x 6 FOUND
0x 7 FOUND
0x 8 FOUND
0x 9 FOUND
0x a FOUND
0x b FOUND
0x c FOUND
0x d FOUND
0x e FOUND
0x f FOUND
0x10 FOUND
0x11 FOUND
0x12 FOUND
0x13 FOUND
0x14 FOUND
0x15 FOUND
0x16 FOUND
0x17 FOUND
0x18 FOUND
0x19 FOUND
0x1a FOUND
0x1b FOUND
0x1c FOUND
0x1d FOUND
0x1e FOUND
0x1f FOUND
0x20 FOUND
0x21 FOUND
0x22 FOUND
0x23 FOUND
0x24 FOUND
0x25 FOUND
0x26 FOUND
0x27 FOUND
0x28 FOUND
0x29 FOUND
0x2a FOUND
0x2b FOUND
0x2c FOUND
0x2d FOUND
0x2e FOUND
0x2f FOUND
0x30 FOUND
0x31 FOUND
0x32 FOUND
0x33 FOUND
0x34 FOUND
0x35 FOUND
0x36 FOUND
0x37 FOUND
0x38 FOUND
0x39 FOUND
0x3a FOUND
0x3b FOUND
0x3c FOUND
0x3d FOUND
0x3e FOUND
0x3f FOUND
0x40 FOUND
0x41 FOUND
0x42 FOUND
0x43 FOUND
0x44 FOUND
0x45 FOUND
0x46 FOUND
0x47 FOUND
0x48 FOUND
0x49 FOUND
0x4a FOUND
0x4b FOUND
0x4c FOUND
0x4d FOUND
0x4e FOUND
0x4f FOUND
0x50 FOUND
0x51 FOUND
0x52 FOUND
0x53 FOUND
0x54 FOUND
0x55 FOUND
0x56 FOUND
0x57 FOUND
0x58 FOUND
0x59 FOUND
0x5a FOUND
0x5b FOUND
0x5c FOUND
0x5d FOUND
0x5e FOUND
0x5f FOUND
0x60 FOUND
0x61 FOUND
0x62 FOUND
0x63 FOUND
0x64 FOUND
0x65 FOUND
0x66 FOUND
0x67 FOUND
0x68 FOUND
0x69 FOUND
0x6a FOUND
0x6b FOUND
0x6c FOUND
0x6d FOUND
0x6e FOUND
0x6f FOUND
0x70 FOUND
0x71 FOUND
0x72 FOUND
0x73 FOUND
0x74 FOUND
0x75 FOUND
0x76 FOUND
0x77 FOUND

[after]

***** Booting Zephyr OS build zephyr-v1.13.0-8609-g9481527d20df *****
Starting i2c scanner...
0x3c FOUND

EDIT 1. This is also in #15545.

[carlescufi]

@MaureenHelm is this still an issue?

[MaureenHelm]

@MaureenHelm is this still an issue?

yes

[pabigot]

Confirmed this is still an issue. Using the shell i2c scan command (which replaced the utility used before) I'm seeing every other address returning valid.

I poked at it a bit and suspect the HAL LPI2C_MasterTransferNonBlocking doesn't handle a zero-length transfer correctly, completing with success without verifying the ack status of the address. Any sort of delay could cause the NAK to be received and recorded in another ISR invocation. That may be completely wrong, though.