RPi 3 B+ with Sense Hat getting "Error: cannot open framebuffer device." from snake.c example

Hi John,

I plugged in a Sense HAT into a Pi 3B (I don't have a model 3B+ handy), and then powered up the Pi.

What happens at boot-up, is that the LEDs light up in a spectrum, illuminated for 3-4 seconds, and then the LEDs extinguish.

I had no HDMI monitor connected, and am not using VNC. I connected to the Pi using SSH.

I see this:

If you're not getting that far, then if you're sure that you're on a recent version of Raspbian, and you're using the correct PSU (there's a difference between the official PSU, and mobile phone chargers, even if the current rating is the same or higher), then unfortunately there is a possibility your Sense HAT is faulty. I'm surprised though. There's not a lot to go wrong with the Sense HAT.

Hey, I fixed it.  I know what I did, but do not understand it.

In boot config.txt, I commented out the dtoverlay just under [all] and added in the present, as suggested in another thread:

https://lb.raspberrypi.org/forums/viewtopic.php?t=192033

[pi4]

# Enable DRM VC4 V3D driver on top of the dispmanx display stack

#dtoverlay=vc4-fkms-v3d

max_framebuffers=2

[all]

#dtoverlay=vc4-fkms-v3d

dtoverlay=rpi-sense

What did I just do?

What is vc4-fkms-v3d?

Did I just get sense hat to work, but now fouled other components?

Why do I have a section for pi4 when I installed on a pi3?  I do not recall specifying pi<anything> during install.

Thanks for any tutoring on dtoverlay.

Hi John,

Linux uses a more complicated than necessary method to configure up hardware, and the Pi uses a more complicated method than needed on it's accessory boards like the Sense HAT. What's occurring is that a serial bus (I2C) is queried at boot time, and the I2C memory chip on the Sense HAT reports back that it is plugged in. At that point, drivers can be loaded by looking up a file containing a compiled 'device tree overlay', that will be part of the Raspbian image. After that occurs, the end result is that a /dev/fb1 gets created. That's not a normal file, but more a special gateway into controlling the LEDs. Since it is a special file, it cannot be successfully used by copying like a regular file on the file system. If you were to power off, unplug the Sense HAT and restart, then that /dev/fb1 would disappear, since the I2C memory chip would be disconnected.

On the Sense HAT, there's some microcontroller (I've never checked the detail) but I believe it perhaps accepts commands from the Pi and transforms to LEDs being illuminated via an LED driver chip. So, at power-up, you're seeing the rainbow pattern for several seconds on the LEDs as a result of the microcontroller booting up and running some internal sequence. If you see that pattern then it's likely the microcontroller is fine, and the power supply is fine too. (incidentally, there's no guarantee when a 5.0V phone charger is used that it will function, because the Pi official supply doesn't output 5V, it outputs 5.2V over thicker-than-normal wires, and that plus the 0.2V voltage difference can be critical under heavy load). The Pi official supply is a terrible mobile phone charger, but a good-enough power supply. In contrast, a mobile phone charger is often bad for Pi powering, but excellent at phone charging. In a third category, if your PSU is some third party make but specifically designed for the Pi, then you're likely ok.

By you adding the lines to config.txt, you're forcing the Pi to load the device tree overlay file for the sense HAT, regardless of if the Sense HAT is detected (via the I2C memory chip) or not. If that's working for you, it suggests that the memory chip on the Sense HAT was corrupted. There are some instructions on how to reprogram that chip here: https://www.raspberrypi.org/documentation/hardware/sense-hat/

However it states the instructions might not work on Pi 3B - maybe they have not tested the reprogramming steps on that board. Anyway, there's nothing wrong with manually adding the lines to config.txt to work around the issue, as you have done. It just means that even if the Sense HAT is removed and the Pi is restarted, the drivers will still be loaded (and that's likely not a critical issue in this case).

I can't comment on why the vc4 bit is there, it could have been put there as a result of some other stuff being executed, or it may be normal (since the same Linux image gets loaded onto all Pi's). In any case, the '#' means it is commented out and not active. My Pi 3 (not Pi 3B) doesn't have any entry with vc4, commented or otherwise.

Thanks for the obvious time and thought you have put into your answers.

I attempted the process found in:

https://www.raspberrypi.org/documentation/hardware/sense-hat/

I captured the output found below.

It appears that the script is looking for a device that is not there.  I checked the directory, it looks like it is of a different structure than expected.

The structure is good through 12c-0, but then it looks like many subdirectories.  Some of them appear to be logical links back to somewhere previous in the directory chain.

I include the dump below, on the off chance it suggests an obvious answer to you.  Otherwise, I think I am satisfied with what I have.  I can mess around with the sense hat now.  Giving me a sense (pun) for how appropriate RPi+Sense is for my course concept.

I did look at the schematic.  I believe the only EEPROM is 64 bytes on the ATTINY88-MUR.  I think this chip comes in 4 or 8KB of FLASH.  This is pretty tight.  Probably not enough room to sense EE corruption and correct it.  I doubt whether some change in the AVR causes the issues below.  I would guess the directory structure changed so the script is no longer valid on the 3Bx.

Off topic, could you suggest a forum to discuss how RPi might be used to teach embedded FW programming... at the college level?

You have been very kind with your time and thought.  Many thanks.

Thanks for the obvious time and thought you have put into your answers.

I attempted the process found in:

https://www.raspberrypi.org/documentation/hardware/sense-hat/

I captured the output found below.

It appears that the script is looking for a device that is not there.  I checked the directory, it looks like it is of a different structure than expected.

The structure is good through 12c-0, but then it looks like many subdirectories.  Some of them appear to be logical links back to somewhere previous in the directory chain.

I include the dump below, on the off chance it suggests an obvious answer to you.  Otherwise, I think I am satisfied with what I have.  I can mess around with the sense hat now.  Giving me a sense (pun) for how appropriate RPi+Sense is for my course concept.

I did look at the schematic.  I believe the only EEPROM is 64 bytes on the ATTINY88-MUR.  I think this chip comes in 4 or 8KB of FLASH.  This is pretty tight.  Probably not enough room to sense EE corruption and correct it.  I doubt whether some change in the AVR causes the issues below.  I would guess the directory structure changed so the script is no longer valid on the 3Bx.

Off topic, could you suggest a forum to discuss how RPi might be used to teach embedded FW programming... at the college level?

You have been very kind with your time and thought.  Many thanks.

Hi John,

It might not be possible without some jumper wires and manually moving the I2C bus. The Pi has two I2C interfaces, and the EEPROM is on the other one compared to all other I2C devices on the board.

According to this link: https://www.madebymikal.com/raspberry-pi-hat-identity-eeproms-a-simple-guide/

I don't know for sure though, I've never tried it. Another possible scenario is that the EEPROM chip (it is labelled U6 on the board) is faulty, or isn't soldered on correctly.

Embedded programming is a large topic, I'm not sure which area you're looking into (e.g. sensor programming with the Sense HAT. I don't know of a source for college-level class material for it. The Pi is ordinarily used with Linux, so it's useful for general programming, or Linux appliance use (i.e. Linux embedded in some device). An IoT gateway would be another use-case.

It can be used without Linux, but that's unusual (and would be underusing it). Embedded programming can also mean microcontroller programming (the Pi has an applications processor, not a microcontroller on-board).

When I studied, embedded programming was more constrained than it is now, and a microcontroller trainer board was used, with a board plugged on top that was similar-ish to the Sense HAT (minus so many LEDs, and with fewer sensors).  The trainer board was plugged into a desktop PC (nowadays a Pi could be used if desired for that too) via RS232 (USB is more popular now!) and programming was taught in assembler (nowadays C would be a better replacement, although it's nice to see assembler too, at least briefly, to see how the C instructions are transformed by the compiler.

Programming projects included things like making castle shapes using the digital-to-analog converter (DAC) on the HAT-like board to view on a 'scope.

If your course is really aimed at teaching languages suitable for embedded programming, such as C, then that can also be taught with a Pi, on top of Linux.When I learned C, the teaching staff had created a simplified interface for input/output, so that the students could concentrate on learning program flow, functions, pointers etc., without getting bogged down with manipulating machine-specific input/output.

Also, if you've got students using the Pi, then programming using C alone would be very limited too, since nowadays software and hardware engineers need additional languages. Python is very productive, so that may be worth looking into as well (if not for embedded programming, for the ancillary tasks like testing embedded hardware). Anyway these are just some ideas.

Shabaz,

You have been a great source of information and mentoring.

I throw in the towel.  I have a configuration that can let me play with both python and C in exercising multiple sensors.

In my day job I am responsible for a field a service tool.  It services 70+ base machine models using ~40 controller types.  In no case can reprogramming be interrupted, or a controller taken 'out of the box", without my service tool being able to configure it appropriately for the intended machine.  That includes setting EEPROM default values.  In some cases, very similar to the one we believe exists on my sense hat, my program will catch corrupted EEPROM and restore a default value.

So I am a bit surprised the RPi does not have a requirement for HAT developers to include in the installation process a "restore HAT to default valutes" script.  Such a script would detect the RPi motherboard, revision of HAT and do the right thing.

I am also surprised that the sense hat got off of end-of-line testing with EEPROM corrupted.  As there are other posts on this, I am not the only one.

I have spent over 8 hours wandering through forums.  Luckily I bumped into you, and you took the time, such that I reduced the problem to the EEPROM is corrupted.

I will move on now to both spinning up Python on RPi and C programming.

You have been a great help.

over and out, John

For another possible other choice check out Micro python on raspberry Pi