Problemas de cuelgue del controlador de matriz de leds MAX7219

Llevo algunos meses diseñando un sistema de carteles avisadores para carreteras que se basa en Arduino y en placas de 18x18 cm que contienen dos matrices de 8x8 leds, 64 verdes y 64 rojos...

...Para controlarlos elegí el integrado MAX7219, por ser barato y haber mucha información sobre su control. Probé el circuito a conciencia, diseñé la placa con Kicad, una empresa nos hizo diez prototipos, en RS encontramos los leds fiables y de la luminosidad adecuada y he montado seis displays en serie... todo bien...

...Pero resulta que el MAX7219 parece tener la insana tendencia a colgarse, y entonces deja leds encendidos de forma aleatoria que no hay manera de resetear por software, ni borrando ni deshabilitando el display afectado y volverlo a activar. La única manera es quitarle la alimentación y volverla a dar.

Debo decir que cada display tiene su propio regulador independiente de tensión 7805 y condensadores de filtro a la entrada y la salida, electrolíticos de 3.000 uF y cerámicos de 220 nF en paralelo con los anteriores. Las masas están cuidadas, los contactos de los conectores son sólidos, la tensión de entrada es estable y suficiente ya que proviene de una batería de 12 Volts 300 A/h ...pero los malnacidos MAX se me siguen colgando de vez en cuando.

Quiero remarcar que el problema no parece venir por el Arduino, que sigue funcionando sin problemas. El probado varios UNO y varios MEGA (estos últimos con memoria de sobra), con todo el programa de mensajes o solamente con un escueto programa de test, y de vez en cuando, tal vez un par de veces por hora, a alguno (no siempre el mismo) de los 6 MAX7219 que están es serie se le cruzan los cables y hace lo mismo, lo cual no es admisible en un cartel informativo de carretera en que la fiabilidad debe ser absoluta...

...Pese a estar convencido que ni el Arduino ni el programa tienen nada que ver, he realizado mil pruebas de todo tipo, he desactivado las interrupciones del Arduino, he probado diversos pines de salida para el Din, CS y Sck, y no consigo evitar este dichoso problema. La librería que utilizo es la habitual "LedControlMS.h"

Este circuito funciona con el bus SPI, pero de manera unidireccional, porque sólo utiliza el MISO y además las funciones de esta librería permiten utilizar casi cualquier pin, ignorando los del SPI por hardware del Arduino. En este aspecto ignoro si a través de esta librería se puede también controlar la velocidad SPI. Tal vez bajándola habría menos problemas, o también reforzando las señales Sck (impedancia más baja) que atacan en paralelo a todos los 7219 (este cartel lleva 12 -6 verdes y 6 rojos-, pero habrá algunos con 36)

No sé si alguno de vosotros se ha encontrado con el mismo problema...

Un saludo a todos

El control de velocidad es posible.

SPI Clock Divider

El max7219 solo pide un pulso de reloj de como mínimo 100nseg o sea 10Mhz quiere decir que todo lo que sea mayor en tiempo es aceptable. Un Tclk mayor no lo afecta con lo que ese no puede ser tu problema.

Supongo has visto con osciloscopio si las señales llegan claramente a los módulos, descarto que lo hayas hecho.

Que puedes contarnos sobre los leds.. a que corriente estan trabajando?
Tu software dices que no parece ser responsable, solo por preguntar, la cantidad de RAM esta bien ya que luego usaste MEGA y no cambió nada.

Usas Strings, punteros,? Ayudaría ver el código para descartar responsabilidad.

Y no se, pero ayudaría dentro de lo que puedas mostrar ver como es el hardware para entender mejor, y ponernos en un mejor contexto.

Las órdenes de control de velocidad las conozco, pero entiendo que son las del SPI de hardware del Arduino, que va con pines específicos según el modelo de placa, pero no sé si afectan al control del SPI a través de la librería que uso, que permite otros pines distintos...

El programa normal de control de carteles ahora no es importante, porque ya comento que los he probado con un sencillo programa de test sin ninguna floritura, simplemente escribiendo una palabra de forma repetitiva, borrando y volviéndola a escribir... y el problema sigue igual...

El circuito es sencillo, de hecho es el típico que se puede encontrar en sitios de divulgación de Arduino como Prometec o Luís Llamas, con algunas variaciones en la alimentación y filtraje...

...No obstante, entre este circuito y el final hay una pequeña diferencia. Aquí el 7219 de control de rojos está en cascada con el de verdes, pero eso lo cambié modificando las pistas de los circuito impresos acabados, para que al final, de un cartel de 6 dígitos, por una parte los verdes estuvieran todos en cascada y de la otra los rojos...

...Pero eso tampoco tiene que ver, me lo hacía antes con la antigua disposición y también ahora. De igual forma reduje al mínimo la intensidad (sobre los 5 mA por LED) y no hubo cambio de pautas en los errores. También cuando realizaba las pruebas del software utilicé las pequeñas matrices de 8x8 que se venden normalmente... con idéntico resultado.

Saludos

Hi,
Haz tratado de anadirle un delay cuando envias los comandos. Es posible que les estes enviando los comandos muy rapidos y no da tiempoa terminar la instruccion. Eso me paso a mi con el sensor de temperatura infrarojo. Al principio las lecturas era erraticas y el ponerle un pequeno delay cuando mandaba los comandos para leer la temperatura el problema se resolvio.

El max7219 solo pide un pulso de reloj de como mínimo 100nseg o sea 10Mhz quiere decir que todo lo que sea mayor en tiempo es aceptable. Un Tclk mayor no lo afecta con lo que ese no puede ser tu problema.

Que delay quieres agregar cuando puede trabajar a 10Mhz algo que jamàs el arduino puede suministrarle via SPI?

Ademàs ya dijo que probò otros pines no SPI lo que baja la velocidad considerablemente y aùn asi falla.

@Anilandro tienes un código con los módulos comprados para que lo pruebemos?

Bueno tal vez he dado con el problema. En este hilo se debate tu problema y creo que las hipòtesis estan bien fundadas. Ver link MAX7219 display errors

I wouldn't think the chip is actually crashing.
My bet would be that the chip is receiving a corrupted message (message with incorrect bits set or cleared) that is corrupting one of the upper registers which could all kinds of odd things from changing the pixel decoding, to turning the pixels off, to disabling columns, to changing the intensity etc...

This corruption could be caused by either s/w or h/w.

A h/w issue would be something like a glitch on the clock line due to something like ground bounce on
the power, or bit corruptionin the data bit, due to EMI etc..

A s/w issue could be due to the code or library creating an incorrect message
under certain specific conditions that rarely occur.
It could also be do to memory corruption do to some subtle bug clobbering a piece of memory that happens to affect a message sent to the 7219.

In some cases these types might be occurring more often than observed since they might clear themselves when the next message is sent, which might be a very short period of time.

These type of issues can be hard to track down.

I recently found an issue in the Parola max7219 library.
The observed affect was that after a download, random led matrix displays in a multi display chain might fail to function properly. Pixels might be appear to be random, or dimmer, than they should be on a given matrix display.
Even a hard reset of the AVR would not clear it up, only a power cycle would clear it up.
Everyone was convinced it was a 7219 "crash" issue and there were lots of accusations of it being an issue with "cheap" Chinese 7219 "fake" parts.
This ended up being a s/w issue in the library.
The s/w initialization of the 7219 was not properly setting all the necessary registers.
The issue would happen if there was a message in process when the AVR reset occurred.
That incomplete message would send a garbage message when the AVR reset and library started up.
When that garbage message would corrupt a register that was not being initialized, one more displays would fail to function properly.
For this case, I used a logic analyzer to catch the bogus commands being sent.
Luckily for me, the condition was very repeatable in a matter of seconds in my setup which made it much easier to track down.
The solution was to initialize all the 7219 registers, so while the AVR reset would still cause a register to get corrupted (which is unavoidable), the proper initialization sequence would configure the 7219 to work properly every time.

Your situation will be more difficult to catch.
Is the AVR ever being reset? (like perhaps a watchdog kicking in?)

If you had a scope, it would be useful to look at the power and clock signals to see if there were any issues.

You could reinitialize the 7219 which should clear up any issues, but that is really just masking the issue.

Muchas gracias por las respuestas, Surbyte y demás compañeros. Hasta mañana no voy a poder continuar con el tema de los carteles, ya que es un desarrollo para el lugar en que trabajo.

He leído atentamente el hilo del enlace a un problema que parece igual al mío, pero al final las causas se diluyen un poco. Puede ser una cuestión de registros corruptos o de problemas de alimentación o de masas. La segunda causa no creo que lo sea, ya que los cables son de sección considerable y hay generosos filtros a manta. Lo de los registros a causa de órdenes defectuosas podría ser, pero ¿como resetear tales registros sin quitar la alimentación?, porque en mi caso no parecen responder a ninguna orden de reinicio...

...Estudiaré un poco el datasheet del 7219, a ver que saco en claro. Ya daré noticias de como va la cosa.

Un saludo a todos

Concuerdo que se diluye pero al menos es una pista.. como seguirla todo un desafío.