TM1637 display shows dashes or wrong digits: pins, brightness and segment order

CLK and DIO are not I2C. Use the pins named in your sketch and a TM1637 library.

What the message means

The module looks like I2C but uses its own two-wire protocol. A wrong pin or library gives blank or odd digits.

Fix it in this order

  1. Connect CLK and DIO to the pins in the sketch.
  2. Power from 5 V or 3.3 V as the module allows.
  3. Use a library for the TM1637.
  4. Set the brightness level with the library call.
  5. Check the 4-digit order if numbers appear reversed.
  6. Update the display only when the value changes.

Why it happens

A TM1637 display needs the right pins in the code for CLK and DIO, a matching library, and a clean supply. A wrong pin order or a library for a different module gives blank, dashed or wrong digits.

Check the CLK and DIO wires, power the module from the voltage in its specification, use a library written for the TM1637, and test with a fixed number first.

If you see this, do this

You seeDo this
All dashesWiring or library.
Colon missingSet the colon flag.

LCD blank, OLED blank.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

A TM1637 module is a driver chip for a four-digit seven-segment display and a key scanner. It speaks a two-wire protocol that looks like I2C because it uses a clock and a data line, but it has no device address and no acknowledge in the I2C sense. A normal Wire library will not talk to it. The library bit-bangs the two lines on any two digital pins you choose, which is why CLK and DIO in the code must match the pins you wired.

Dashes, blanks or odd digits come from four places: wrong pins, a library written for another module, a supply that sags, or a module variant whose digit order differs. The brightness level is also stored by the library and applied on the next write, so changing it without redrawing seems to do nothing.

How to confirm the cause

  • Light every segment with setSegments and four 0xFF values. If all segments glow, the wiring and power are good and the problem is in your number or text code.
  • Show a fixed number such as 1234 first, before using sensor data. This separates display problems from data problems.
  • Swap the CLK and DIO wires in code only (not on the module) to rule out a swapped pair.
  • If a six-digit module shows groups of digits in swapped order, that is how some boards are wired; reorder in code.

Worked example

This sketch uses the TM1637Display library and lights every segment before it shows a number.

#include <TM1637Display.h>

const int CLK = 2;
const int DIO = 3;
TM1637Display display(CLK, DIO);

void setup() {
  display.setBrightness(7);          // 0 to 7
  uint8_t all[] = {0xFF, 0xFF, 0xFF, 0xFF};
  display.setSegments(all);          // every segment on
  delay(1000);
  display.showNumberDec(1234);
}
void loop() {}

Common mistakes

  • Wiring the module to A4 and A5 because the pins look like I2C.
  • Expecting the colon to appear with showNumberDec; use showNumberDecEx with the colon mask (0x40 on common four-digit modules).
  • Calling setBrightness after drawing and expecting an instant change; call a display function afterwards.
  • Updating the display on every loop pass, which wastes time and can flicker on a slow bus.

If this did not fix it

  • Check the supply voltage and the ground wire; a loose ground gives garbage digits.
  • Check for a clone module that needs a different library or timing.
  • Check that no other library is using the same pins.
  • Check the wire length; keep it short for a clean signal.