samples: driver: i2c_scanner: correct i2c message length

[overheat]

Some SoC i2c driver doesn't support zero length of I2C message, and they will ignore this transaction if so. Then the sample will fail.

Fixes #14749 for STM32 and ATSAM boards

Signed-off-by: Aaron Tsui [email protected]

[overheat]

@pabigot Could you help me to review this code? The i2c_scanner sample fails on ATSAM and STM32 chipset.

[pabigot]

The transaction length must be zero. If a SOC I2C device doesn't support this, then the scan won't work. It may simply be that the SOC driver rejects a zero length transaction but the hardware would allow it.

The mechanism behind the scan requires that the transaction stop after the address is transmitted, as it is the implicit NACK to the address byte (lack of response from any subordinate device at that address) that indicates whether a device is present. Transmitting even a single byte of data introduces the possibility of changing the state of the device at that address in a way that leaves it unusable.

(Technically, even the zero-length transaction of getting its attention could make the device unusable, which is why the README for this example includes a warning about using this sample. It's unlikely the device would be permanently damaged, but it might require a power cycle to recover.)

So you'll have to address this in the I2C drivers for the failing SOCs.

[overheat]

@pabigot
Yes, I agree with you that "Technically, even the zero-length transaction of getting its attention could make the device unusable." I rise this PR in a very tight situation, it was few days before 1.1.4 release, and this i2c_scanner sample fails on STM32 and ATSAM.

I thought it's good enough for a demo. For your information, it "works" on several SoC, including STM, Nordic, NXP, and Atmel. Technically, just send one more frame and will still get NACK if no sensor attached.

Anyway, I will close this PR and try to address this in the I2C drivers for the failing SOCs sometimes.
I feel very sorry for bothering you at the weekend.

[pabigot]

@overheat That it correctly diagnoses absence of a sensor isn't the issue; it's what happens when a sensor is present and there isn't a NACK. Somebody could reasonably adopt this demo into an application and use it to determine which sensors are populated. If an SDP811 (for example) becomes unresponsive because it only got the first half of its two-byte command that would be a problem. The zero-length transaction, adopted from Linux i2c-detect, works on most devices so it's as safe as we can get.

No problem about the weekend; if it was I'd have just ignored the request until later.