When it does not answer

Six symptoms

Pick what you see. The ringed part of the board is where to look, and the sentence under it is the check to make.

The scan

Every check starts here. This loop calls each address from 1 to 126 and prints the ones that acknowledge:

for (int a = 1; a < 127; a++) {
  Wire.beginTransmission(a);
  if (Wire.endTransmission() == 0) {
    Serial.print("found 0x");
    Serial.println(a, HEX);
  }
}

Put it in setup() after Wire.begin(), with Serial.begin(115200) before it. The TK31 prints found 0x50. In MicroPython, print(i2c.scan()) does the same and prints [80], which is 0x50 in decimal.

Not found: the wiring

Swapped SDA and SCL is the usual fault, and it harms nothing. Count from the square pad: GND, VCC, SDA, SCL. Then check your board's pins: A4 and A5 on an Uno, GPIO 21 and 22 on an ESP32, GPIO 8 and 9 on an ESP32-S3, GP4 and GP5 on a Pico.

Then VCC: on your board's logic supply and actually connected. And the jumper on the back: if it has been cut and nothing else on the bus has pull-ups, SDA and SCL float and nothing answers.

Two TK31s on one bus both answer at 0x50 and the scan shows one. There is no way to move one of them; give it its own bus.

Found, but the data is wrong

Old values, or 255 after a write: the read went out while the chip was still writing. Wait after every write, with delay(5) or acknowledge polling.

255 everywhere, even after a write that waited: the sketch or library is sending one address byte instead of two, so it reads and writes somewhere else. Libraries for the small 24C02 do this.

Text with its end at its start: a write crossed a 64-byte page edge and wrapped. Sixty-four-byte pages has the fix.

One byte that will not hold: wear. A million writes finds the loop that did it.