Sense HAT, led’s stopped working just like that

[Abmvk]

When I power my RPI the SenseHAT shows its rainbow colours, so the LEDs work. In Python I tested sensors and joystick, they work. And until today the LEDs also worked. But now they have stopped, with clear, with messages, with individual pixels, they just stay dark, Thonny tells me everything works fine, but it doesn’t.

Where should I start looking?

[revell1]

A circuit diagram, and sharing your code would be a good start.

[bensimmo]

Did you update it yesterday and then it stop working?

If you write a new PiOS card, does it work again, (without updating it!)

If it is a recent update it may be the new PiOS kernel. I've not set mine up to check that.
Or another update that came down at the same time.

Do you have another Pi?
What Pi is it anyway?

[Abmvk]

A circuit diagram, and sharing your code would be a good start.

There is no more circuitry involved than the Sense HAT, I didn’t do anything to it.

And the code, well, any code. Just as simple as a sense.clear(255,0,0,) does nothing. No single pixels, no messages, nothing.

[Abmvk]

Did you update it yesterday and then it stop working?

If you write a new PiOS card, does it work again, (without updating it!)

If it is a recent update it may be the new PiOS kernel. I've not set mine up to check that.
Or another update that came down at the same time.

Do you have another Pi?
What Pi is it anyway?

I have tested it on two Pi’s, both Pi 400. Different SD cards, but I didn’t try it before updating yet, so I will try that

[turbospeed]

This is uncanny! I have the exact same issue, I just started working with the Sense HAT today after a few years of it being stuck in a box.

I tried numerous Pi's, a PI 3B with a touchscreen, a PI4B and a Pi2B.

The PI4B refused to boot at all with it attached - just a red flashing LED with the official Raspberry PI USB-C power supply.

The Pi3B displayed the rainbow leds on first power on, and shut off when booted. And then I added the sense-hat package, but it was already installed. The joystick worked as I could cursor around the terminal window and the other sensors were working. But I could get nothing on the LEDs. Of course, I had updated this before I tried it, or at least within the last few days. Tried adding dtoverlay=rpi-sense, but that didn't make any difference.

i2cdetect -y 1 on PI3B did this:

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- 5f 
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

raspigpio get gave me this:

Code: Select all

BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=4 alt=0 func=SDA1
GPIO 3: level=1 fsel=4 alt=0 func=SCL1
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=0 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=1 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=0 fsel=0 func=INPUT
GPIO 29: level=1 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=0 fsel=0 func=INPUT
GPIO 32: level=1 fsel=7 alt=3 func=TXD0
GPIO 33: level=1 fsel=7 alt=3 func=RXD0
GPIO 34: level=1 fsel=7 alt=3 func=SD1_CLK
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3
GPIO 40: level=0 fsel=4 alt=0 func=PWM0
GPIO 41: level=1 fsel=4 alt=0 func=PWM1
GPIO 42: level=0 fsel=4 alt=0 func=GPCLK1
GPIO 43: level=0 fsel=4 alt=0 func=GPCLK2
GPIO 44: level=1 fsel=5 alt=1 func=SDA0
GPIO 45: level=1 fsel=5 alt=1 func=SCL0
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

I was reading various forum posts and some even suggested re-flashing the EEPROM. But I didn't do that on the PI3B, as it said that was unreliable. I had a PI2B v1.1 so went to testing the PI2B with a last resort of reflashing later...

So I dropped back to an PI2B, with a fresh install (today - 03/18/2023), and had to put dtoverlay=rpi-sense into /boot/config.txt to get it shutdown the LEDS on boot. In the PI2B, tried installing sense-hat, but was already installed, and had the same result as the PI3B, sensors working but no LED changes - colour_cycle.py did nothing, text_scroll.py did nothing. Same result.

I ran i2cdetect -y 1 on the PIB2 and came up with this:

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- 5f 
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

same as before with the PI3B.

raspi-gpio get:

Code: Select all

BANK0 (GPIO 0 to 27):
GPIO 0: level=0 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=4 alt=0 func=SDA1
GPIO 3: level=1 fsel=4 alt=0 func=SCL1
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=1 func=OUTPUT
GPIO 8: level=1 fsel=1 func=OUTPUT
GPIO 9: level=0 fsel=4 alt=0 func=SPI0_MISO
GPIO 10: level=0 fsel=4 alt=0 func=SPI0_MOSI
GPIO 11: level=0 fsel=4 alt=0 func=SPI0_SCLK
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=1 fsel=4 alt=0 func=RXD0
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=0 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=1 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=0 func=INPUT
GPIO 29: level=1 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=1 fsel=1 func=OUTPUT
GPIO 32: level=0 fsel=1 func=OUTPUT
GPIO 33: level=0 fsel=0 func=INPUT
GPIO 34: level=1 fsel=0 func=INPUT
GPIO 35: level=1 fsel=0 func=INPUT
GPIO 36: level=1 fsel=0 func=INPUT
GPIO 37: level=0 fsel=0 func=INPUT
GPIO 38: level=1 fsel=1 func=OUTPUT
GPIO 39: level=0 fsel=0 func=INPUT
GPIO 40: level=0 fsel=4 alt=0 func=PWM0
GPIO 41: level=0 fsel=1 func=OUTPUT
GPIO 42: level=1 fsel=1 func=OUTPUT
GPIO 43: level=1 fsel=0 func=INPUT
GPIO 44: level=1 fsel=4 alt=0 func=GPCLK1
GPIO 45: level=1 fsel=4 alt=0 func=PWM1
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT
GPIO 47: level=0 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

No idea what I've done wrong here... so I reflashed it, using the instructions on the Sense HAT documentation page https://www.raspberrypi.com/documentati ... e-hat.html - with one change:

Code: Select all

./eepmake sense_eeprom.txt sense.eep /boot/overlays/rpi-sense.dtbo

as there is no /boot/overlays/rpi-sense-overlay.dtb - I have a SenseHAT v1.0 and picked the one above.

Flashing appeared to work:

Code: Select all

Opening file sense_eeprom.txt for read
UUID=71f0dff2-e501-425b-8841-3a7cb7944657
Done reading
Opening DT file /boot/overlays/rpi-sense.dtbo for read
Adding 893 bytes of DT data
Writing out...
Writing out DT...
Done.

xyz@raspberrypi:~/hats/eepromutils $ i2cset -y -f 1 0x46 0xf3 1
xyz@raspberrypi:~/hats/eepromutils $ sudo ./eepflash.sh -f=sense.eep -t=24c32 -w
This will attempt to talk to an eeprom at i2c address 0x50. Make sure there is an eeprom at this address.
This script comes with ABSOLUTELY no warranty. Continue only if you know what you are doing.
Do you wish to continue? (yes/no): yes
Writing...
1+1 records in
1+1 records out
1008 bytes (1.0 kB) copied, 0.414061 s, 2.4 kB/s
Closing EEPROM Device.
Done.
xyz@raspberrypi:~/hats/eepromutils $ i2cset -y -f 1 0x46 0xf3 0

followed by a reboot, but no difference.

Sorry to the original poster as this is not an answer, I have the same issue, but I thought this additional information may help

[Abmvk]

I do thank you for all the work! At least I dare to postulate a new hypothesis now: I am not crazy, the sense HAT is!

[4k3or3et]

Hi All,

yesterday i have updated kernel using apt upgrade on my RPi4B and led matrix on my SenseHat stopped working.

I have tried on clean image without update. It works fine then. As soon as I perform all updates it goes black again.

Sensors works fine in both cases.

[Abmvk]

Hi All,

yesterday i have updated kernel using apt upgrade on my RPi4B and led matrix on my SenseHat stopped working.

I have tried on clean image without update. It works fine then. As soon as I perform all updates it goes black again.

Sensors works fine in both cases.

That sounds promising. I will try a clean image today then. And then hope for the best, as future updates may correct the problem

[respire]

Hum, apparently something has changed under /sys/class/leds.
I use to turn off the leds of the RPI and now it does not work with led1 and led2.
You might want to look at this structure.

[DirkS]

Hum, apparently something has changed under /sys/class/leds.
I use to turn off the leds of the RPI and now it does not work with led1 and led2.
You might want to look at this structure.

Unrelated to this topic...
See viewtopic.php?p=2091639#p2091423

[respire]

Thank you.
Sorry for you if it's not related and so simple to fix.

[turbospeed]

Hi All,

yesterday i have updated kernel using apt upgrade on my RPi4B and led matrix on my SenseHat stopped working.

I have tried on clean image without update. It works fine then. As soon as I perform all updates it goes black again.

Sensors works fine in both cases.

That sounds promising. I will try a clean image today then. And then hope for the best, as future updates may correct the problem

I just tried this with the RPI2B, recreated the SD card but skipped the updates. Had to enable i2c and put dtoverlay=rpi-sense in the /boot/config.txt but now the LEDs on the Sense HAT work with the provided examples!

i2cdetect -y 1 produces:

Code: Select all

xyz@raspberrypi:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- 5f 
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

raspi-gpio get produces:

Code: Select all

xyz@raspberrypi:~ $ raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=0 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=0 fsel=4 alt=0 func=SDA1
GPIO 3: level=0 fsel=4 alt=0 func=SCL1
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=1 fsel=4 alt=0 func=RXD0
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=0 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=1 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=0 func=INPUT
GPIO 29: level=1 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=1 fsel=1 func=OUTPUT
GPIO 32: level=0 fsel=1 func=OUTPUT
GPIO 33: level=0 fsel=0 func=INPUT
GPIO 34: level=1 fsel=0 func=INPUT
GPIO 35: level=1 fsel=0 func=INPUT
GPIO 36: level=1 fsel=0 func=INPUT
GPIO 37: level=0 fsel=0 func=INPUT
GPIO 38: level=1 fsel=1 func=OUTPUT
GPIO 39: level=0 fsel=0 func=INPUT
GPIO 40: level=1 fsel=4 alt=0 func=PWM0
GPIO 41: level=0 fsel=1 func=OUTPUT
GPIO 42: level=1 fsel=1 func=OUTPUT
GPIO 43: level=1 fsel=0 func=INPUT
GPIO 44: level=0 fsel=4 alt=0 func=GPCLK1
GPIO 45: level=0 fsel=4 alt=0 func=PWM1
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT
GPIO 47: level=0 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

Going to try a few other things, but looking promising that something in the updates has broken it. I saw someone posted something about kernels being changed to 64-bit on the 32-bit OS and that breaks external modules somewhat, will try updating and setting arm_64bit=0 to see what happens there.


Thanks everyone for the responses!

[Daniel Gessel]

This might be solved, but something to check: the sense hat has a kernel driver that makes the leds available on /dev/fb*.

If you have no display attached (and no other source of a an fb device)) there will just be /dev/fb0. Use “fbset -fb /dev/fb0” to get the size of fb0 (/dev/fb1 and so on). If you don’t find an 8x8 framebuffer, then somethings up with the kernel driver install. If you find one, then permissions might be broken. You should be able to write to it with “cat /dev/random >> /dev/fb#”, where # is the 8x8 framebuffer.

If it works, the result will, with high probability, be ugly. You can turn it off with “cat /dev/zero >> /dev/fb#’.

Any “no space left on device errors” are normal, as /dev/random and /dev/zero provide unending streams, and the hat fb is 8x8 rgb565 pixels (128 bytes - not big enough to run the x-server on, or even the fbconsole…).

[Abmvk]

I have fb0 and fb1, fb0 gave a respons of “8x8”. I tried writing to it with the cat…>> /dev/fb0, it gave no errors but also no result.

[Daniel Gessel]

I think there may be a copy involved in the kernel driver, as in the 8x8 fb is just a block of memory and when modified, it gets pushed out over gpios by some cpu code. Somebody at RPi probably knows exactly, but I’m kind of curious. If I find anything, I’ll share.

[tcranger1]

Hi all,

I can confirm that the recent updates also broke my ability to manipulate the LEDs on the SenseHat. However, the sensors (temp, humidity, pressure) are all still functioning normally. Please let me know if you would like me to assist with any troubleshooting or potential fixes. Thank you!

[Daniel Gessel]

It looks like it is a problem with the copy of the 8x8 /dev/fb rgb565 buffer, across i2c to the hat, getting broken by doing "sudo apt upgrade". The problem is not in the hat firmware and the "virtual framebuffer" setup seems fine from userspace (the memory can be written and read back via /dev/fb#).

In testing I first found my leds worked writing to /dev/fb0 (32 bit RPi OS Lite, not recently upgraded), then did a "sudo apt upgrade" and they still worked. After reboot it happened: the leds no longer respond to writes to /dev/fb#.

Using generic i2c calls I wrote a block of data to the device at i2c address 0x46 and the leds light up fine. The buffer format on the atmel (the device at address 0x46) is 24 rows of 8 bytes each, the rows cycling through red, green and blue; the 24 individual component rows making 8 rgb rows tall. This makes sense to me for for row-by-row PWM as I understand it.

That doesn't narrow it down to a line of code, but it seems really likely the kernel "virtual fb" read => atmel via i2c write is failing (incorrect or simply not happening).

I use C, but the “manual write” across i2c can also be done using Python. The fb interface seems comparatively cumbersome, so unless there's a reason not to, I'll just go i2c direct in the future (I’d like to get rid of the fb code in the kernel - I like simplifying things - but I’m not that far along).

I think all the libraries and samples that use the fb interface are broken for the time being, tho'.

One thing, I haven’t done a ton with the sense hat but the leds are super bright even when I send 1s in the buffer. I’m wondering if brightness can be reduced modifying the atmel firmware (I guess that would mean lowering the PWM duty cycle) but that’s another topic.

[Abmvk]

As the Sense HAT is a product of the foundation, I assume this is a problem they will want to solve, and I think with the information from all responses here, it should be possible. So the main question now is, do “they” read a topic like this, or is there a way to point out there is a problem (and a solution)? I didn’t find an idea-box?

[bensimmo]

I linked to it with a post in the testing 6.1 kernel, which was released at the same time this problem came up, hence my post above about going back to the original downloadable image.

Also if this was moved to the AstroPi (SenseHAT section).
Can anyone roll back to an earlier 5.15 kernel just to check it is or is not that?.

[dom]

The author of the sense hat driver is aware of the breakage on the 6.1 kernel.
We'll need to wait for a fix.

[tractor]

I linked to it with a post in the testing 6.1 kernel, which was released at the same time this problem came up, hence my post above about going back to the original downloadable image.

Also if this was moved to the AstroPi (SenseHAT section).
Can anyone roll back to an earlier 5.15 kernel just to check it is or is not that?.

Before, with a dead LED array:

Code: Select all

uname -r
6.1.19-v8+

After downgrading, with a live LED array:

Code: Select all

uname -r
5.15.84-v8+

I can confirm the SenseHat LED array cannot be used after an upgrade to the the 6.1.x kernel.

[Daniel Gessel]

The author of the sense hat driver is aware of the breakage on the 6.1 kernel.
We'll need to wait for a fix.

DOH! I didn’t even check the kernel version: 6.1 seemed like “the future”. Oh well, it was interesting to dig in and I might still try to disable it anyway.

[Abmvk]

The author of the sense hat driver is aware of the breakage on the 6.1 kernel.
We'll need to wait for a fix.

great! I have no problem with waiting

[steveiliop56]

I can confirm that my sense hat leds are not working too after using kernel 6.1. But what could possibly destroy the matrix functionality with the new 6.1 kernel?