u/EmbedSoftwareEng

So, the I2C 7-bit addresses 0x00 - 0x07 are all reserved for "special purposes".

But, I found a CO2 concentration sensor that pays attention to writes to address 0x00 with a subsequent data byte of 0x06 to perform a commanded reset.

I've seen some devices that can get themselves discombobulated and I think that just pumping the SCL signal should get them to recombobulate themselves. So, I wrote a bus_pump() routine that just sends writes to address 0x00 to force the SCL line to toggle while holding the SDA line low the whole time.

But, if something out there is going to actually respond, operationally, to something like that, I need to find a different strategy.

So, does anyone know of any I2C devices that do weird things vis-a-vis the reserved addresses?

So, I'm building an I2C interface driver that's absolutely bullet proof. No matter what happens on the I2C bus, the driver never blocks for any appreciable period of time, and the application-facing calls will return error codes that accurately report what's happening on the bus.

As a toy application to test it out, I wrote a simple bus scan with change watchers for the interrupts flags, status, and synchronization registers.

I know I have a bunch of environmental monitoring peripherals at 0x0B, 0x29, 0x44, and 0x68. Problem is, I'm also getting an ack back from 0x6B, which there's nothing on the board that's supposed to be sitting on that address.

I have a mock up of it without the 0x0B device and the 0x44 is at 0x45 instead. It correctly detects devices on 0x29, 0x45, and 0x68, and no phantom on 0x6B.

Is it at all common for devices to ack more than one address? Why would the 0x0B device ack that address and also 0x6B, which is not documented as an address that it uses, in its datasheet.

This is just weird.

Also weird is when I run through the bus scan just as fast as the hardware will churn, I'll reliably go from 0x7F down to 0x47 with no issues, but testing 0x46 will lock something up. I need to find out what that is and kill it. Nothing untoward seems to be happening when I'm running the bus scan as a FSM that takes like 20 ms between interactions with the I2C interface hardware. So that's an added dimension.