i2c: possibility to receive a (data) NACK from a slave without having log clutter (IDFGH-13870)

[eriksl]

Is your feature request related to a problem?

My code does probing of I2C devices. It's completely normal to have "address" NACK's. No problem there. But part of the probing process is also reading of certain registers. On some devices reading certain registers cause a NACK to be sent after the address was ACKed. This is required information to distinguish some devices from others. On that occasion the i2c driver will clutter the log with:

warning: i2c_master_transmit (ESP_ERR_INVALID_STATE) [0x103]
 I2C transaction unexpected nack detected
 s_i2c_synchronous_transaction(870): I2C transaction failed
 i2c_master_transmit(1072): I2C transaction failed

Over and over again.

I know you can set the field "disable_ack_check" and in that case the logging disappears, but ALSO the NACK isn't reported back to my function anymore, so it's useless.

Describe the solution you'd like.

So what I'd like is an alternative flag that only disables the logging, but does report the actual status (ACK/NACK) back to the calling application.

Describe alternatives you've considered.

Or just remove this logging altogether.

Additional context.

No response

[mythbuster5]

why not using i2c_master_probe to probe your device?

[eriksl]

I wrote:

On some devices reading certain registers cause a NACK to be sent after the address was ACKed.

This is at the stage where the device has already been probed and found to be present and responding. After that stage, sometimes further probing is required to distinguish between different types of models.

Many temperature sensing devices respond to a range of addresses from 0x48 - 0x4f, depending on the address lines configured. Most of the time they're using the same access model so it doesn't matter that much. But some need different approaches (for example lm75 v.s. tmp102). So in that case, you need to know what you're dealing with. Just the address responding isn't enough. A nice example is the tmp75 vs. lm75. They're almost exactly the same, but not completely. The only way to determine whether you're dealing with one or the other, is to access certain registers. One of them will react with a NACK, the other will just give some data.

At this point the i2c master code will print two or three lines of logging. That wouldn't be so bad in itself, but if you, like me, have a bus multiplexer with eight buses connected, you'll this amount times 16 times the amount of devices you probe this way.

I can imagine it wouldn't be so difficult to make this warning optional...

[mythbuster5]

Ok, I got it, make sense. If you're urgent, you can delete the related log by yourself. Because sync to github need some time.