Python Help - Second ILI9341 Display White After Pi Update

[caver01]

@obsidianspider Well, nobody can accuse you of not providing enough detail! ;-)

I have not been following your project and I am not familiar with the issue, but I had to post a quick reply and ask, is that a tiny screen on a cartridge, or a huge replica of a game console? Either way, it is looking pretty cool! I hope you get everything working the way you want.

[obsidianspider]

@caver01 said in Python Help - Second ILI9341 Display White After Pi Update:

Well, nobody can accuse you of not providing enough detail! ;-)

I'm really kind of stuck here, and it's frustrating because it used to work just fine. For months. I'm documenting what I tried not only for detail, but also to try to help anyone else who may run into this problem.

I'm getting quite upset at not being able to figure this out. I may try to put a fresh image on a different SD card, update it, then install the Adafruit stuff and see how that goes. I dunno.

[caver01]

@obsidianspider I have since reviewed your project thread and I gotta say, my hat's off to you! Very nice build. I hope you figure this out (I am sure you will). It has inspired me to finally take a closer look at my mausberry circuit and switch it over to a python script. I am sure I am just wasting CPU cycles. Your setup is a bit beyond me. I have some learning to do.

[obsidianspider]

I have said before that one of the nice things about the Raspberry Pi is that it's a "low consequence" computer, meaning that worst case, you can either just pop in a new disk or if the whole hing explodes, you're only out $35 or so.

After spending HOURS yesterday on figuring out what was going on with the screen not working and ultimately ending up with garbled output, I decided to take another Micro SD card, put a fresh image of RetroPie on it, update it fully, including Raspbian, and then reinstall the Adafruit library, and try again.

Lo and behold, it works.

Since the problem before seemed to stem from the bad identification of the SOC I ran cat /proc/cpuinfo and I'm seeing the

Hardware	: BCM2709

that my other Pi 3s are showing. I only put one game on to see how things are working, but in the RetroPie menu I'm getting the "Northwest" problem, so I'm going to apply the patch and see what happens. That takes a few hours to run, so we'll see.

[obsidianspider]

It looks like I'm not the first one to notice the BCM2835 issue. Even our RetroPie team has noticed it.

[obsidianspider]

After running the Raphnet fix, the CPU is once again reporting as BCM2835, so that's the issue, apparently the kernel coders have decided to correctly report the chip, which ultimately is a good thing, but it breaks this Adafruit script. Now to try to fix it again on the new image.

[obsidianspider]

Sure enough, fixing the GPIO module to tell it that it's a BCM2835 resulted in the same garbled image. Which tells me that something else is looking for that BCM2709 and is freaking out because it can't find it.

Oh well, at least I'm getting somewhere.

Time to pop the original SD card back in.

[obsidianspider]

I can't seem to tell if the issue is with the new kernel, or another piece in the Adafruit libraries that is somehow misidentifying the SOC.

I can see this being a bigger problem going forward too, because in doing a search for BCM2709 on my machine I see that Adafruit's retrogame also uses BCM2709 to determine GPIO layout.

I wonder if this is something I should bring up on Github? I'm not even sure how to do that exactly.

[obsidianspider]

I sent a message via the feedback link on Adafruit's site, but not sure if that will do anything.

[obsidianspider]

I also put a message up over at the Adafruit forums since Github says to try there first .

[herb_fargus]

@obsidianspider just throwing this out there but might be mutually beneficial if adafruit were willing to work on a module with us for inclusion with the setup script (more people would probably buy their hardware if there was an "easier" setup) I've been meaning to make a handheld (one day!)

[obsidianspider]

@herb_fargus This particular library wouldn't help with a handheld as it's just for static images, but they do have others that are used in their handheld kids/projects for enabling TFTs and also their Retrogame library (which I plan to use with a Pi 3 if I can get the 3 trimmed down enough to fit).

If I didn't need the "Northwest Fix" I'd reimage my spare SD card again, and be done with it, but I think that's shortsighted, because eventually that BCM2835 identifier will find its way into "regular" updates and then all kinds of stuff is going to break, as BuZz pointed out in that Github thread.

I'm hopeful someone will figure out what's going on with that garbled output, but I don't know if the updated kernel is causing issues, if the libraries Adafruit is using is doing something weird, or if my code modification to cause the platform to be detected as a Pi is to blame.

I don't know enough about Python, programming, hardware, or Linux to fully grasp this, but I'm sure as heck learning a lot as I've been digging into the issue.

[obsidianspider]

More confirmation that there's likely something up with SOC identification. When I was updating my Genesis Pi I noticed that the kernel was updated to 20170303, so I figured I'd update my Super Famicom Pi just to see what happens. Sure enough, after applying the new kernel, the SOC is once again identifying as BCM2709 and the screen is working correctly. That darn "Northwest" problem is back again though, so I'm going to try re-running the fix and see how that goes. If I knew where in the kernel source the SOC hardware identification was located I'd just change it, but I don't know where to look.

[obsidianspider]

It's working!

I reapplied the Raphnet kernel patch. The CPU is once again showing as BCM2835, but my screen's output is fixed! It looks like the 20170303 version of the kernel fixed the issue.

I'm really going to think twice about updating the software on my now working Super Famicom Pi.