Invalid I2C address after bad address register write?

Melexis MLX90640 Thermal Array Sensor: https://www.melexis.com/-/media/files/documents/datasheets/mlx90640-datasheet-melexis.pdf

I successfully changed the addresses on a few of these sensors, but then managed to mess up one of the rewrites and now its address is somewhere in outerspace, it seems.

Neither i2c_scanner on the Arduino nor i2cdetect (on a Raspberry Pi) are able to detect it, unless I expand the range to include the 0x00 general call address. I am able to detect the other sensors if they are connected.

With only the sensor in question connected, I get an ACK on a general call 0x00 write and ACK/NACK when attempting to read the register that should contain the address. This read returns 0x0000 which makes sense if it is truly at 0x0000 (a possibility, since I had to zero it out before the intended address), but I’m not sure if this isn’t some weird I2C master voodoo faking me out.

The address change involves a repeated start write to identify 16-bit register address, overwrite with 0x0000, write desired address, then power on/off reset.

Can anyone offer some insight into correcting this SNAFU?

Does data returned by 0x00 mean anything or is it a mirage of sorts? I’ve read that the general call is write only, but repeated start isn’t even part of the original I2C spec. So, I’m not sure if some devices treat it differently.

It's not completely unbelievable that the EEPROM cell with the device address was written to 0. As 0 is the "broadcast" address of the I2C bus, simply try to write a new I2C address using 0 as the current device address. Does that work?

Thanks for the reply! I didn't see a notification, earlier.

I've tried what you suggested, writing a valid address to the broadcast I2C address 0x00, as well as first zeroing it out (even though it appears to already be zero) and even reading/writing to the register which contains this data after startup, just grasping at straws. No luck on any of them.

I've verified my code works by changing the address and control reg settings back and forth on another identical sensor several times. No issues at all.

Disconnecting the sensor in question and connecting an identical sensor with a valid address (ex. 0x33) returns 0xFFFF (nothing) when I use the broadcast/general call address to read the address from EEPROM.

If I try to read it with the assigned address, I get the expected values. So, there is something different going on when the mysteriously-addressed sensor is connected, since I get 0x0000 with a broadcast/general call address read, but I don't know if it's of any usefulness.

That probably means that the sensor with the 0x00 address is not usable anymore, unfortunately.