Recommended approach to reset MAX7219 devices?

I’m in the process of trying to figure out why my large (>100 matrices) MAX7219 display board is encountering glitches. I’ve spent a lot of time experimenting with clock speeds, bus transfer rates, and I’ve got something very close to a stable state. Despite being stable for minutes or hours, the most common glitch is that single matrices seem to shut off and on, get stuck pixels, or change contrast for some reason, and it’s not clear why. I’m fairly certain this is not a memory leak or something on the software side causing corrupted signals. That is to say, I don’t think the software is the problem, but that doesn’t mean that there isn’t a software solution to my problem.

Resetting the display fixes the problem. I want to do some debugging to investigate what about the reset process fixes the problem, but aside from running the high level get_device() (from demo_opts), the only methods that I can find to reset the display are the max7219 class’s show() and clear() methods. I’m really not sure which one of the two, or both one after the other, are responsible for resetting the device to a stable state again. It would be great if I could figure out what mechanism is actually “fixing” the devices and cut away any extra cruft that slows down this process so that it could potentially be run repeatedly with minimal latency added to the rendering of subsequent frames.

So, if I can find a way to meet this requirement, my hypothesis is that if I’m rendering frames on the display at a constant rate, I could inject the command that successfully cleans up the glitches every second (framerate+1 frames) or so and it would hopefully be fast enough prevent the glitched matrices from appearing glitched to the human eye, with minimal impact on performance in terms of overall average framerate.

I’m also analyzing the signals using a protocol analyzer and oscilloscope to see if there’s some other reason why the MAX7219 modules are doing this strange behavior. From this perspective, the hypothesis is that the devices being affected by the glitch are missing a clock cycle or something similar and that’s making their shift registers go out of sync from the others in the cascade. Not sure about this yet. Power reads clean on the oscilloscope, signals are 5V0 using a boost converter from the pi’s 3V3 outputs, everything is wired in parallel except the DOUT to DIN pins on each module which are wired in series. I’m using PCBs with 4x MAX7219 chips each, the typical ones found on Amazon and Ebay with 8x8 LED dot matrices. There’s no significant ringing or any other analog weirdness on any of the signal pulses as far as I can see. At this point there’s nothing I can really change with respect to wiring, the clock speed, or the SPI MTU chunk size that seems to make the display glitch less, so I’m hoping I might be able to get closer to a sustainable solution by resetting the devices as quickly as possible on a regular interval.

[drspangle]

Check it out…

I’m pretty confident that you could daisy chain these pretty much ad infinitum. This huge 5x 4x4 matrix array was exactly what I was trying to do.

[drspangle]

@thijstriemstra @rm-hull This is still ongoing. I don’t think this is a software issue, I think there’s actually a signal degradation problem with the MAX7219 devices arranged in cascades.

I’m still in the process of developing a PCB that can be used to strap together 4x4 modules so that they’ll work reliably. I’m learning that PCB design takes a lot of time and effort, though, so it might not be reasonable to expect a resolution in the very short term.