i2c_scanner is scanning reserved addresses

[bperrybap]

i2c address below 0x08 and above 0x77 are reserved.
https://www.i2c-bus.org/addressing/
The i2c scanner should be not be scanning the reserved address space.

[rahul-arasikere]

Some i2c devices could still be using the reserved addresses. I don't see why we should change it to ignore the reserved addresses.

[bperrybap]

Please provide a link to a slave device that has chosen to use an address in the reserved address range.
Here is a reason not to do it. Using reserved addresses can lock up the i2c bus since the reserved addresses are not valid addresses but rather bit patterns that are used for special purpose/reserved functions.
This is particularity true at the low end below 8.

[PaulStoffregen]

Sadly, chips not strictly following the 0-7 reserved spec do exist. AD3935 is one example.

[bperrybap]

Paul, I can't find anything on AD3935, perhaps you mean AS3935?
That chip really did screw up and uses a default base address of zero and with its internal pullups defaults to 0x3 but can changed to 2 or 1 - or even zero (zero won't work on any platform)
I noticed that SparkFun does not recommend or support using i2c on their product that uses that chip.

I'm guessing that they used that address range because they didn't want to license a real address.
They pretty much screwed themselves as there are platforms that do not support it since according to the spec, those are not valid i2c address since their bit patterns have special meaning.

[PaulStoffregen]

Agreed, that chip violates the official spec. But it does exist.

So let me ask you another question. Is there an expected real-world harm from sending an address-only zero length read command to these low numbered addresses? I'm not asking about what the spec says, but what is the actual real world worst case harm?

[bperrybap]

Does attempting to use the non existent i2c slave addresses 1 to 7 as slave addresses on the bus cause "harm"?
I guess it depends on what is meant by "harm" and on what Arduino platform & core.

Yes there are some real world cases where things won't work correctly and/or can cause lockups.

To me, in the bigger picture, it doesn't seem appropriate to knowingly ship code that violates the i2c spec or expects a Wire library to be able to do things that the spec says is not supposed to be done.
At a minimum there should be a comment in the i2c_scanner code stating that valid i2c slave address are 0x8 to 0x77
And if the code decides to scan outside of that range then there should be a big fat comment that states why it is attempting to scan slave addresses that don't exist and why/how the code expects it to work.

---

More details:

First a slightly different issue but it is related to rapid slave address scanning and the use of the non existent addresses.
A rapid scan doing multiple back to back beginTransmission() followed by endTransmission() doesn't work on the chipKIT package Wire library. It will lockup up the pic32 i2c h/w so it won't work anymore and the only recovery is a power cycle.
I worked with the chipKIT guys but this is unfixable in s/w.
If you put in a small delay of 20us it won't lock up anymore.

But.... and here is the part related to attempting to use the non existent 1-7 slave addresses.
On the chipKIT platform, you won't get an i2c error when attempting to use addresses 1 to 7 so it looks like there are always slaves there.

I have an i2c based text based LCD that uses a hd44780 command set but uses a message protocol similar to the PCF2119x chip (it might be using that chip internally; I don't know) and scanning the bus with those low addresses would end up with minor bus collision on SDA which would end up tricking the AVR Wire library into thinking that there was another master on the bus.
The AVR Wire library would wait for the other master to do its transaction, which never happens.
And because there is no timeout, the AVR would be locked in a tight loop spinning forever.
Yes the Wire library has recently been modified to not get stuck in a loop like this but it isn't the default so even today if you run the i2_scanner using addresses 1 to 7 with that slave plugged into the bus, the AVR will lock up.

I have no idea what happens on other platforms and cores since I no longer scan these non existent addresses in my diagnostic tools nor in my hd44780 lcd library that automatically locates the i2c slave address of the LCD device.

Once I stopped scanning the non existent slave addresses and added the small delay for pic32, I've not had any issues related to this on any platform so I haven't done any testing to see how the various Wire libraries react when trying using these non existent slave addresses.

[PaulStoffregen]

FWIW, found another chip using an address < 8.

https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1966.pdf

I2C address is documented in table 15 on page 16 & and figure 13 on page 17.

[bperrybap]

At least according the datasheet for the ADAU1996 in table 15 on page 17and figure 13 on page 18,
the chip doesn't have to operate in the non existent slave address range.
It can be configured for i2c addresses 0x24, 0x44, and 0x64
So they didn't totally screw up like the guys that did the AS3935 chip.