MAX7219 Daisychaining - Data becoming corrupted?

Hi all,

I'm making a 7 segment display array using 100 x 4 digit, 7 segment displays and 50 x MAX7219 chips.

The first ~60 displays (30 chips) were working great. I then soldered another 20 displays (10 chips) and the data the chips are getting towards the end of the daisy chain are becoming almost random. Sometimes all the displays will work for a short bit as intended, and then sometimes displays will turn on and off at random, change brightness, display weird things etc. (see video).

I've been working on this project for awhile now (this is the 4th iteration of the PCB design!) and I've managed to solve all of the other issues I've run into but this one has me stumped.

My initial thoughts are that there is some sort of interference(?) or something causing this randomness. I've attached a short video of me turning it on and off a couple times, as well as the schematic and the test code I'm running.

Thank you and all help appreciated.

https://streamable.com/c018vr

#include <SPI.h>

// What pin on the Arduino connects to the LOAD/CS pin on the MAX7219/MAX7221
#define LOAD_PIN 10


void maxTransfer(uint8_t address, uint8_t value) {

  digitalWrite(LOAD_PIN, LOW);

  for (uint8_t i = 0; i < 40; ++i)
  {
    SPI.transfer(address);
    SPI.transfer(value);
  } 
  
  digitalWrite(LOAD_PIN, HIGH);
}
  

void setup() {
  
  // Set load pin to output
  pinMode(LOAD_PIN, OUTPUT);

  // Reverse the SPI transfer to send the MSB first  
  SPI.setBitOrder(MSBFIRST);
  
  // Start SPI
  SPI.begin();

  // Run test
  // All LED segments should light up
  // maxTransfer(0x0F, 0x01);
  // delay(3000);
  // maxTransfer(0x0F, 0x00);
  
  // Enable mode B
  maxTransfer(0x09, 0xFF);
  
  // Use lowest intensity
  maxTransfer(0x0A, 0x00);
  
  // Only scan one digit
  maxTransfer(0x0B, 0x07);
  
  // Turn on chip
  maxTransfer(0x0C, 0x01);
  
}

void loop() {
  
  // Loop through each code
  for (uint8_t i = 0; i < 0x10; ++i)
  {
    maxTransfer(0x01, i);
    maxTransfer(0x02, i);
    maxTransfer(0x03, i);
    maxTransfer(0x04, i);
    maxTransfer(0x05, i);
    maxTransfer(0x06, i);
    maxTransfer(0x07, i);
    maxTransfer(0x08, i);
    delay(1000);
  }
  
}
[7SDA (ATMEGA328P).pdf|attachment](upload://xDPB0vnVzxiI4b09x7ug7zd9MHg.pdf) (3.7 MB)

7SDA (ATMEGA328P).pdf (3.7 MB)

  • I'd start with checking the voltages down the string.

  • Do you have decoupling capacitors on each Vcc pin on all chips ?

  • Do you have access to an oscilloscope to look at clocking signal shapes ?

How are you running the clock signals? Please post a schematic.

Hi, thanks for your response.

I checked the voltage at a few of the chips Vcc pins and they're all getting around ~4.6V. This includes the displays that are working normally and those that appear not to be. I've checked the datasheet for the MAX7219 and this is within their operating range.

I have a 10uF and 100nF decoupling capacitor at every chip Vcc - mounted as close to the chip as I could.

Unfortunately I do not have an oscilloscope. Perhaps something I should invest in.

Oops, sorry. Forgot to append. It's at the bottom of the post now.

Okay, thanks. Can you save us some time and answer my question? It looks like all the clock lines are paralleled. What device output is driving that? Discuss.

I'm an engineer by trade (mechanical), however electronics is a hobby of mine so I'm by no means super technical with all of this. I'll do my best to describe:

All 50 chips are connected to the clock line in parallel. Initial version of my board were using an Arduino Nano to drive the clock, however, my most recent version I decided to try and teach myself something new by getting rid of the nano and using an ATMega328P. The clock line is connected to 'PB5' of the ATMega, which I believe to be the appropriate SCLK pin.

From the MAX7219 datasheet, my understanding is that the clock should be connected in parallel. I'm not sure if this helps, but below is an image from KiCAD with the clock line highlighted. It might be quite difficult to see so apologies in advance.

Thanks for your help.

You can't do that. The combined capactive load is too great. You need multiple drivers, each one only driving a few loads.

From the MAX7219 datasheet, my understanding is that the clock should be connected in parallel.

It's written for electrical engineers. The authors assume you know there is a fan out limitation.

2 Likes

This is very interesting, thank you. Back to the drawing board and time to order another bunch of displays and drivers!

1 Like

Before you commit to a new board, add some dead bug drivers, cut traces and wire into the existing PCB.

1 Like

Agree. You can probably save the board with some mods. It will be ugly but can work.

==> It will be messy but can work.

Fan-out of MAX7219:
===> Source Current/Input Current = 2 mA/1 uA = 2000. Is it correct?

Okay, I think some of my rat's nests are beautiful too. But maybe not other people. :slight_smile:

1 Like

Always have some Kynar 30AWG wire wrap wire on hand.

My eye-attractive and heart-satisfying beautiful baby though messy!

The back looks like a tumbleweed. :slight_smile: Nice work. I don't think the OP needs that much wire though... or 200m of it...

I've noticed a strange physical property of wire though. It almost always ends up shorter than the length that you carefully measured out to fit somewhere.

1 Like

This one is better with dual-colored wires containing less wires as I used 8279 Keyboard/Display Controller.
8086KitPic

I also think you should attempt to get what you have working before you waste money on another board only to find another problem.

You should only need a buffer chip like 74hc244. Make 3 extra buffered versions of the clock signal and same for the latch signal. After every 25 max chips, break the clock & latch traces and solder a buffered signal to the chip legs.

The SPI bus of a 16Mhz Uno runs AFAIK by default at 4Mhz.
You can change that to 8MHz or a division of that.
Try running the bus slower, at 2Mhz or 1Mhz.
That could get your display working as you have it now.

Replace this line
SPI.setBitOrder(MSBFIRST);
with
SPI.beginTransaction(SPISettings(2000000, MSBFIRST, SPI_MODE0));

That will prove your fanout problem.
Then use buffers, and you maybe can try 8Mhz for a faster display update speed.
Leo..

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.