# MAX7219 LED matrix shows garbage or a mirrored image: module type and chain order

> Fix a MAX7219 matrix: select the right hardware type in the library, check the chain order and power it from 5 V with a shared ground.

Canonical: https://roboticsengineering.in/fix/max7219-led-matrix-shows-garbage-or-mirrored/ | Published: 2026-11-03 | Updated: 2026-11-04

**Pick the correct module type in the library.** Different boards wire the rows and columns differently.

## What the message means

The same chip appears on boards with different orientation. The wrong setting mirrors, rotates or scrambles the picture.

## Fix it in this order

1. Set the hardware type to match your module in the library.
2. Try each type until the test pattern looks right.
3. Wire DIN, CLK and CS to the right pins and join grounds.
4. Power from 5 V with enough current for the LEDs.
5. Lower the brightness if the board resets.
6. Count the modules in the chain correctly.

## Why it happens

The MAX7219 drives eight digits of eight segments. A matrix module simply wires those outputs to LED rows and columns, and different board makers wire them in different orders. The chip sends the same data in every case, so the picture appears rotated, mirrored or scrambled until the library knows your layout. The MD_MAX72XX library offers several hardware types for this, including FC-16 and Parola, and trying each is the quickest way to find the right one.

Garbled output that changes when you touch the wires points to the supply or ground. Each module can draw a lot of current at full brightness, so lower the intensity setting (0 to 15) while testing, and make sure the grounds of the controller and the module are joined.

## If you see this, do this

| You see | Do this |
| --- | --- |
| Image mirrored | Wrong hardware type. |
| Modules out of order | Chain count or direction. |

## Related

[LED strip colours](https://roboticsengineering.in/fix/ws2812b-neopixel-flicker-wrong-colours/), [5 V current](https://roboticsengineering.in/fix/arduino-uno-5v-pin-current-limit-sensors-servos/).

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

The MAX7219 is a driver for eight digits of eight segments. A matrix module simply connects those 64 outputs to LEDs, and the maker decides which output goes to which row and column. Boards from different makers wire them in different orders. The chip and the data are identical, so the library has to be told which wiring you have, or the image appears rotated, flipped or in the wrong order.

When modules are chained, each one passes data to the next. The first module in the chain is the one nearest the controller, and each module can also be wired in a different direction. A message that appears reversed across a chain of four usually has a hardware type set wrongly, not a fault in the modules.

## How to confirm the cause

- Run a simple test pattern, such as lighting one pixel in the corner at row 0, column 0. Note where it appears on the module.
- Change the hardware type in the library and run again. Choose the type that puts the pixel in the corner you expect.
- Set the number of devices to match your chain exactly and try a pattern that spans all modules.
- If the pattern flickers or changes when you touch the wires, check the ground connection first. Join the grounds of the controller and the module.
- Lower the brightness. A board that resets when many LEDs light points to a weak supply.

## Worked example

This uses the MD_MAX72XX library. FC16_HW is one common type; try PAROLA_HW, GENERIC_HW and ICSTATION_HW if the corner is wrong. Pin 10 is the chip-select used in this example.

```
#include <MD_MAX72xx.h>
#include <SPI.h>
const uint8_t CS_PIN = 10, DEVICES = 4;
MD_MAX72XX mx(MD_MAX72XX::FC16_HW, CS_PIN, DEVICES);
void setup() {
  mx.begin();
  mx.control(MD_MAX72XX::INTENSITY, 2);   // 0 to 15
  mx.clear();
  mx.setPoint(0, 0, true);                // corner pixel
}
void loop() {}
```

## Common mistakes

- Using the wrong hardware type and then trying to fix the image in code.
- Counting the number of modules incorrectly.
- Connecting the input end of the chain to the output end of the first module.
- Powering many modules from the controller’s 5 V pin.

## If this did not fix it

- The data direction: DIN must go in at the input side and chain out through DOUT.
- Loose wires on a breadboard, which give random pixels.
- The library’s own pin settings if you use software SPI rather than the hardware one.