LEDs failing to light up.

[jwheare]

This may not be an issue with your software but I'm at a loss after a long thread in the Adafruit forums so I just want to make sure http://forums.adafruit.com/viewtopic.php?f=47&t=84544

Basically, the matrix has started only managing to light up at all if I jiggle the connector while it's making partial contact. And then, understandably sporadically.

As soon as I stop moving the connector, or if I push it in fully, the lights go out.

Here's a video showing what it looks like while running the demo sudo ./led-matrix -r 32 -c 2 -D 0

https://www.youtube.com/watch?v=5H9m9QuiyqE&feature=youtu.be

The hardware all seems fine (but may not be in some invisible way) and I have tried reinstalling the raspberry pi OS to a state where it was working previously.

Is there any way I can collect some debug information to see if everything is operating as expected from the software point of view? Or is this a symptom you recognise at all?

[hzeller]

The lighthing up you see there is just from random input you send to the matrix; it is not wonder that it lights up something randomly, but it won't give any insights in cable/connector issue. Only that the panel is doing 'something'.

The software doesn't know much if there is anything electrically going on wrong - it only sends data, never looks at inputs. So it can't do debugging diagnostic (you might uncomment DEFINES+=-DSHOW_REFRESH_RATE in lib/Makefile to give some confirmation that it does something).

Can you give me the output of a git diff origin to see the local changes in your branch ? You should have least the ADAFRUIT_HAT flag set.

The Makefile should make sure to recompile when the flags change, but it might be a good idea to make clean ; make to convince yourself.

To debug, I would measure the OE bit to see if it is giving a signal with a scope; if you don't have that, you should see some average value that is not 0v or 5V with a multimeter when the led-demo is running (see the images in the README to see where to expect the signal; you need to essentially measure between GND and OE- on the lowest row. Make sure to not accidentally short things while measuring).

OE is the most interesting signal to look at because even if the other cables are broken, this would make it flicker somehow. Next up in that list would be the CLK signal (one pin up in the connector compared to the OE) - it will indicate if data is clocked in.

Both of these signals are better measured with a scope though.

Also, I'd start with a fresh raspbian on a separate SD card and do a fresh checkout/compile of the rpi matrix code there and test.

The camera you mention in the Adafruit thread I don't know, so I have no experience if that would influence things. I could imagine if it does something that influences the pin-muxing.

[jwheare]

Thanks for the detailed suggestions. I'll see if I can get access to a scope and/or multimeter.

I've been regularly using clean, and tried DSHOW_REFRESH_RATE, which showed a value that seemed to vary appropriately with the DRGB_SLOWDOWN_GPIO setting (which I tried disabling and setting to 2).

I'll try a fresh reinstall now.

Here's my diff, against an up to date checkout:

diff --git a/lib/Makefile b/lib/Makefile
index dacf2b0..61b6e50 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -40,7 +40,7 @@ DEFINES+=-DRGB_SLOWDOWN_GPIO=1
 # If you have an Adafruit HAT ( https://www.adafruit.com/products/2345 ),
 # you need to use this option as the HAT swaps pins around that are not
 # compatible with the default mapping.
-#DEFINES+=-DADAFRUIT_RGBMATRIX_HAT
+DEFINES+=-DADAFRUIT_RGBMATRIX_HAT

 # Uncomment if you want to use the Adafruit HAT with stable PWM timings
 # The newer version of this library allows for much more stable (less flicker)

[hzeller]

The diff looks perfect. Not sure if I can debug anything more remotely.
(I don't have a HAT myself to test, but I hear from other users that it works just fine with the Makefile flag).

To continue your quest, I suggest to

• Check/replace IDC cable.
• Make sure that GND is properly connected on both the display and the Pi (probably it is if you connected it through the HAT). And Pi/HAT/Panel are all powered with a good 5V power source.
• Install a fresh copy of raspbian with a fresh checkout of the software to make sure nothing is messed up that way.
• Get a scope to see if OE/CLK work
  • If they don't work on the output pin, test if they work on the output of the Pi (see README to figure out which GPIO pins that would be). If that works, then maybe the HCT245 on the HAT is toast?

[jwheare]

Have now tried a new IDC cable and a fresh install of raspbian on a formatted sd card.

Just to clarify, the lighting up I see is definitely not random. If I run demo -D 0 and produce the flickering by jostling the connector, I can see the shape of the rotating coloured square it's just interrupted. I don't know if that helps narrow down the issue.

I'm going to try to track down a scope later on today for some measurements.

[hzeller]

Maybe the connector on the panel is loose. Try to re-solder all the pads of the connector.

[jwheare]

Here are the OE- and CLK signals measured from the base of the LED panel connector with everything plugged in fully.

http://youtu.be/tUajaw7x_Xw

[jwheare]

Measured from the labeled base pins here:

Looks like those signals are getting through fine. I'd rather not touch the soldering on this part, it looks and feels secure. If this indicates a faulty part I'll just ask for a replacement.

[jwheare]

One thing I just noticed having measured the other signals on the panel: A appears to be a constant voltage, while B, C and D show square waveforms. Not sure if this is normal (a quick glance of the code suggests not). All the RGB pairs and strobe show waveform signals too.

[hzeller]

Yep, A should be alternating as well. Do you see it at GND ?

Try unplugging the cable and measure the equivalent signals directly at the HAT output. If you see them there, then the cable might be badly crimped (shorting A with adjacent GND; can happen if the cable was slightly at an angle when crimped).

If you don't see it at the HAT output either, look at the equivalent output of A at the Pi (GPIO 22 with the HAT). If you see it there, then the HAT HCT245 is fried as it doesn't pass out the signal.

If you don't even see it there, the Pi GPIO output at least for that pin is probably fried.

What is the voltage swing you see on the scope ? I should be roughly 5V.

[jwheare]

Yup no signal on the Pi at BCM pin 22, just a 3.3V up trace (is that what you mean by voltage swing?). I presume the only fix for a fried pin is ordering a new Pi?

[jwheare]

I also tried setting that pin to 0 with the python RPi.GPIO library and the gpio command line tool but no matter what it's stuck at 1.

[hzeller]

Yeah, sounds like your Pi is fried.

[jwheare]

Yup, just got a new Pi and it's working beautifully now. Thanks for all the debugging help, I learned a lot. Sorry for the waste of time!