Mini LCd stopped working once OS has booted

Hi, so i have been loving the Pi-Top[4] and everything has been going well, i have been using the mini LCD screen in my project and its been working really good, have a custom menu system and all sorts of fun stuff, will working the other day i looked away for 5sec and when i looked back the mini LCD was blank, restarted and the Pi-Top boot logo shows up and the battery icon shows up for 5sec but as soon as i get to the OS it goes blank.

I sent a CS email to you guys can was told to re-flash my OS… That is not a solution! How can you just tell a customer, “oh well, re flash time” with out even trying to help fix the problem, do you know how long it takes to get everything setup? Any chance of getting some actual help? Im kind of technical so feel free to lay it all out, just anything other than the lazy “re-flash time”

Hi @Justin, the reason we ask to re-flash the OS is because the OLED screen is driven by some python libraries and, if someone is customizing the OS a lot, then there is a chance that something can break - the easiest way for a customer support team to diagnose if it’s software or hardware is by using a fresh OS (which is a known baseline).

In terms of the boot-up sequence, the OLED screen is first driven by the pi-top [4]'s internal MCU, once the Pi is on it then hands over control to the Raspberry Pi. From this, we know that the OLED hardware is working properly which leaves two scenarios:

  1. Software issue on the OS (could be many things)
  2. A hardware connection issue between the Raspberry Pi SPI interface and the OLED screen

Can you get a new SD card and try booting with a fresh OS? This will keep your system intact and we can then pinpoint the problem before we start recommending opening the case and checking cable connections.

In terms of your “do you know how long it takes to get everything set up” conundrum - that’s a problem many pi users face and I share your pain. I’d recommend looking into Docker containers if your system is particularly complex, then your system can be OS-independent and with a single command, you can have it up and running again exactly as you want it. If the system doesn’t warrant that sort of solution, then using shell scripts and python setup.py files can get you a long way to a faster set-up time.

You can also try running:

ps -ef | grep python

and looking for a line that includes this:

/usr/lib/pt-sys-oled/pt-sys-oled

That will tell us that the OLED python driver seems to be running. However, even if it was running I’d still recommend flashing a new SD card and trying that for the reasons stated above.

@Justin I’ve run into the same issue at times. I just wanted to write and recommend listening clearly to what duwudi is saying. It’s just a test to verify that the issue isn’t hardware.

I immediately thought it was hardware myself and then I reloading a fresh install of the OS and the OLED started working normally.

I discovered that something in what I was doing with the OLED in my code was causing a loop that never stopped and it took over the OLED from returning to normal behavior.

It sounds like you’re think that he is saying that every time you have an issue with your OLED that you’ll have to reflash the OS and start over. I get it, I thought the same when I ran into the issue. But what a new install of the OS helped me discover is the OLED was fine on my pi-top and that it was something I was doing in my code changes that messed it up in the Python call for the OLED driver. Even if a reboot of the pi-top was done it wouldn’t work right. So run the install of the OS again and if your pi-top OLED starts working, you know hardware is fine and it’s a software issue.

Just my couple pennies worth.

1 Like

I’ll chime in and confirm that nine times out of ten, when I’m talking to someone who describes the OLED going black after boot, it means that there is a python loop running in the background.

What’s really whacky about this phenomenon is, when this happens and the OLED is blank, nothing else resets it (seemingly) than reloading the OS from scratch.

With a separate microSD, I load a fresh install of the pitopOS and boot the pi-top[4] up. Then remove that microSD and pop back in the previous microSD and everything is fine using that previously set up OS mSD.

Seems like re-booting with a newly flashed pitopOS microSD resets the OLED. But only a fresh install of the pitopOS will reset it. Once the microSD is used for the initial bootup, it won’t reset the OLED again. The OS has to be reflashed again to trigger that OLED reset.

Just got my pi-top 4 yesterday and this exact same thing happened to me (black OLED). I had to reboot with fresh install to get it back. I guess I will keep a spare SD card just for this as I am developing software specifically for the OLED and I guess it will happen again

Hi everyone, sorry if I came of sounding like a dick, that was not my goal, I was just a little meh about having to reflash the OS, I’m 90% sure it will fix the problem after reading the comments it sound like it just needs a resetting, so ill keep a fresh sd card around so I can reset it as needed.

I let the battery run down last night in the hopes it will reset things, ill also drop another sd card in and see if that resets it, it sound like this is a problem as I’m not the only one, any chance of a python lib the force a reset of the oled or something along those lines? Do we know what makes this happen? Are there any best practices, ill explain a little bellow as to what i was doing.

I dont use python and had to do some funky stuff to get the .net sdk working in c++.

A little backstory as to how I was using the oled from c++, I started with the new .net sdk you dropped, I then built a c# lib to run all the pi -top functions, managed oled pages/menu interactions(cup, memory, devices, connections, ect), I then decorate functions with a NativeExpose attribute, for a function to be callable from native code it needs to be static and have a delegate with the same function sig.

I host netcore3.1 in my c++ app, i then have a tool that uses reflection to parse the types in my c# lib and generate c++ classes to wrap the managed functions and extract function pointers, you can then just call the managed functions as you need like normal but from native code.

//Setup the function pointer
typedef void (CORECLR_DELEGATE_CALLTYPE* call_SetCoreValues_fn)(float core0,float core1,float core2,float core3);
call_SetCoreValues_fn SetCoreValues_ptr = nullptr;

//Get the function pointer
rc = load_assembly_and_get_function_pointer_2(
m_NetCoreLoader->GetPath(),
STR(“DotNetLib.FPiTop, DotNetLib”) /type_name/,
STR(“SetCoreValues”) /method_name/,
STR(“DotNetLib.FPiTop+SetCoreValuesDelegate, DotNetLib”) /delegate_type_name/,
nullptr,
(void**)&SetCoreValues_ptr);

//Call the function
if(SetCoreValues_ptr)
{
SetCoreValues_ptr(core0,core1,core2,core3);
}

Just got the fresh OS on a new sd card, issues fixed but dropping it in, letting the pi boot till the oled worked again then going back to my old OS and its all good!

You should add this to the knowledge base or something as its a simple fix and im 100% happy to do this any time i mess the screen up.

I didnt even need to use a fresh install, i found my old 16gb card, didnt think it had pi-topOS on it but it did and everything worked fine!.

@Justin glad it’s working now! Also, good effort on the C# and C++ libs, do you have a GitHub link?

I’ll investigate further on the “reset” of OLED. I’m quite surprised that once it has been turned on once with a fresh OS that placing the other OS back in retains it being in a working state - I would have expected the other OS to still be “broken”. I’ll revert once I have more information!

Yeah i was a little surprised it worked, it did make the screen play the first time boot animation and sound, stayed blank for 5sec and then was good to go, i dropped the “broken” OS card back in and it did the same thing, could it be as simple as needing to set it to that first boot state and then its good?

Bellow is the git I just setup for the code gen stuff, i just snapped it out of my main project so it may not be 100%, it does build and it all seems to work. The project file setup is a bit janky but it should get you started, not many comments right now but not much code and it should be simple to follow, ill update it soon with comments and a few other more advanced bits.

Tiba3195/netcore2cpp: netcore3.1 hosting and native code generator (github.com)

@duwudi - I’ve experience similar to Justin. The OLED stops displaying anything (except for the [4] animation during shutdown or boot-up). Then I boot with a different microSD with a different install of pitopOS and the OLED starts working again. – Then I return to the previous microSD and the OLED continues to work.

It’s a weird phenomenon because you would think that when the OLED stops working because of software, shutting down and rebooting would reset the OLED, but it doesn’t. So booting first from a microSD with the pitopOS that still needs to “initialize” seems to “reinitialize” the OLED and then going back to the previous microSD keeps the OLED working normally.

Almost like whatever is causing teh OLED to go blank is written to memory on the RPi and the only solution is to reboot with a fresh install of pitopOS and then go back to the other microSD to continue working normally.

@Justin – I totally get the frustration because I’ve experienced the same behavior and there’s some comfort in knowing others are too and that it’s just not me going crazy alone. :grinning:

I just got my Pi-Top 4 today and I’m having this problem, but flashing the OS doesn’t seem to help. The screen was working perfectly up till I was in the middle of trying the Data Analysis exercise on Further.

What I’m seeing: During boot, the “4” animation appears, and when the Pi is ready, it goes black and remains black. During shutdown, it animates, briefly shows the battery status, then turns off. I also get the battery status for a second after I plug the power in while the Pi is off.

I’ve tried reflashing the SD card that came with the kit, and flashed another SD card I had handy, but in both cases the result is the same.

Hi all - can everyone try using the latest OS image on the website, and let me know if that helps? We made a number of changes under the hood in this area that may have helped…

I just did and it doesn’t seem to be helping. I flashed the SD card with the latest image and booted, but once it got past the “[4]” animation the screen went dark (where during the first install it was showing me the IP address).

FWIW I see the same issue. I set up PI-TOP 4 DIY for first time today. Installed the latest 12-22-20 OS from the web site. Also had a message that the firmware needed to be updated, clicked on update it, saw nothing happen. Restarted the PI-TOP 4, got the message that the firmware needed to be updated. Clicked on update and then got a message that is was updating, then it was updated, and then I needed to restart, which I did. I haven’t see anything on the OLED display except the battery charging icon, and the “[4]” animation when booting, and ending up with a blank screen. I tried the ps -ef | grep python command and saw that /usr/lib/pt-sys-oled/pt-sys-oled was running.

I have this same issue. I used a freshly install pi-top OS, the last as today. The first time I tried it worked, but after clicking in the firmaware update the oled stopped working. I updater the eeprom again to check, but the issue persists. Seems to be a problem with the latest firmware update.

Using an older pi-top OS from an older image made this works again. I installed the older SD as @Tom-B said worked. Use older SD with older OS image, and then switch to the new one. IDK what the problem can be. Maybe pi-top can provide us some older OS images to workaround this.

1 Like

Same Problem here too.

Fresh Install with OS Image “pi-topOS-sirius_C781_2020-12-22_04-11-42.zip”. Clean Install and Reboot afterwards…

OLED Display remains Black.

Some Debugging Informations:

pi@pi-top:~ $ ps -ef | grep python | grep pt-sys-oled
root       876     1  3 20:29 ?        00:00:18 /usr/bin/python3 /usr/lib/pt-sys-oled/pt-sys-oled
pi@pi-top:~ $ pi-top  devices
HUB ==================================================================================================================
pi-top [4] (v5.4)
PERIPHERALS ==========================================================================================================
[   ] pi-top Touchscreen 
[   ] pi-top Keyboard 
[   ] pi-topPULSE 
[   ] pi-topSPEAKER (v1) - Left channel 
[   ] pi-topSPEAKER (v1) - Right channel 
[   ] pi-topSPEAKER (v1) - Mono 
[   ] pi-topSPEAKER (v2) 
pi@pi-top:~ $ pi-top oled draw "hallo"
Press Ctrl + C to exit.
# Nothing Changes on OLED Display!! OLED Display still remains Black.
pi@pi-top:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi@pi-top:~ $ sudo apt update
OK:1 https://apt.pi-top.com/pi-top-os sirius InRelease                             
OK:2 http://archive.raspberrypi.org/debian buster InRelease                                                 
OK:3 http://raspbian.raspberrypi.org/raspbian buster InRelease                                              
OK:4 http://packages.microsoft.com/repos/vscode stable InRelease                    
Paketlisten werden gelesen... Fertig      
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Alle Pakete sind aktuell.
pi@pi-top:~ $ sudo apt upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
pi@pi-top:~ $ vcgencmd bootloader_version
Sep 10 2019 10:41:50
version f626c772b15ba1b7e0532a8d50a761b3ccbdf3bb (release)
timestamp 1568112110
update-time 0
capabilities 0x00000000
pi@pi-top:~ $ date -R
Sun, 03 Jan 2021 20:47:43 +0100

Thanks everyone for the detailed feedback, we are looking into this issue as a priority - apologies for the inconvenience caused and we’ll get back to you ASAP with a solution :+1: