Python Help - Second ILI9341 Display White After Pi Update

obsidianspider

I tried manually removing the Python modules (I'm learning more about Python by this not working) but even after doing that and reinstalling the Adafruit library, I'm getting the same error. I'm not sure why it's looking for that Adafruit_BBIO.GPIO module.

Just for the heck of it, I installed the module.

sudo pip install Adafruit_BBIO

Now when I run it I get something different. I still think something is funky that the Pi thinks it's a BeagleBone.

$ sudo python imageparam2.py neogeo.jpg
Traceback (most recent call last):
  File "imageparam2.py", line 45, in <module>
    disp = TFT.ILI9341(DC, rst=RST, spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE, max_speed_hz=64000000))
  File "build/bdist.linux-armv7l/egg/Adafruit_ILI9341/ILI9341.py", line 134, in __init__
  File "build/bdist.linux-armv7l/egg/Adafruit_GPIO/GPIO.py", line 278, in setup
TypeError: argument 1 must be string, not int

Some googling about the TypeError: argument 1 must be string, not int leads to a StackOverflow post that mentions BeagleBone pins are strings, not integers.

Why does my Pi think it's a BeagleBone?!

I removed Adafruit_BBIO sudo pip uninstall Adafruit_BBIO and I'm back where I started.

$ sudo python imageparam2.py neogeo.jpg
Traceback (most recent call last):
  File "imageparam2.py", line 45, in <module>
    disp = TFT.ILI9341(DC, rst=RST, spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE, max_speed_hz=64000000))
  File "build/bdist.linux-armv7l/egg/Adafruit_ILI9341/ILI9341.py", line 132, in __init__
  File "build/bdist.linux-armv7l/egg/Adafruit_GPIO/GPIO.py", line 420, in get_platform_gpio
ImportError: No module named Adafruit_BBIO.GPIO

I really wish I knew what yesterday's update changed behind the scenes. In hindsight when it asked "Do you want to update the OS/Kernel?" I should have said "No" :-/

obsidianspider

As I've often said "the best way to find out how something works is when it doesn't"

I learned that the python modules end up being installed in /usr/local/lib/python2.7/dist-packages

From there I saw some .egg files

After determining that a .egg is just a renamed .zip file, I extracted the two Adafruit files to take a look at what was going on, and why it though my Pi was a BeagleBone

In the Adafruit_GPIO-1.0.2-py2.7.egg file there is a folder named Adafruit_GPIO and in there is a file named GPIO.py as was referenced by the error message.

GPIO.py on line 408 runs the get_platform_gpio function. Line 420 is where it looks for a Beaglebone if it can't find a Raspberry Pi.

def get_platform_gpio(**keywords):
    """Attempt to return a GPIO instance for the platform which the code is being
    executed on.  Currently supports only the Raspberry Pi using the RPi.GPIO
    library and Beaglebone Black using the Adafruit_BBIO library.  Will throw an
    exception if a GPIO instance can't be created for the current platform.  The
    returned GPIO object is an instance of BaseGPIO.
    """
    plat = Platform.platform_detect()
    if plat == Platform.RASPBERRY_PI:
        import RPi.GPIO
        return RPiGPIOAdapter(RPi.GPIO, **keywords)
    elif plat == Platform.BEAGLEBONE_BLACK:
        import Adafruit_BBIO.GPIO
        return AdafruitBBIOAdapter(Adafruit_BBIO.GPIO, **keywords)
    elif plat == Platform.MINNOWBOARD:
        import mraa
        return AdafruitMinnowAdapter(mraa, **keywords)
    elif plat == Platform.UNKNOWN:
        raise RuntimeError('Could not determine platform.')

Platform.py contains the platform_detect() function.

That attempts to get the version of the pi with the pi_version() function.

The pi_version() function is the problem.

def pi_version():
    """Detect the version of the Raspberry Pi.  Returns either 1, 2 or
    None depending on if it's a Raspberry Pi 1 (model A, B, A+, B+),
    Raspberry Pi 2 (model B+), or not a Raspberry Pi.
    """
    # Check /proc/cpuinfo for the Hardware field value.
    # 2708 is pi 1
    # 2709 is pi 2
    # Anything else is not a pi.
    with open('/proc/cpuinfo', 'r') as infile:
        cpuinfo = infile.read()
    # Match a line like 'Hardware   : BCM2709'
    match = re.search('^Hardware\s+:\s+(\w+)$', cpuinfo,
                      flags=re.MULTILINE | re.IGNORECASE)
    if not match:
        # Couldn't find the hardware, assume it isn't a pi.
        return None
    if match.group(1) == 'BCM2708':
        # Pi 1
        return 1
    elif match.group(1) == 'BCM2709':
        # Pi 2
        return 2
    else:
        # Something else, not a pi.
        return None

It's returning None so I decided to see why.

I ran cat /proc/cpuinfo and I found my culprit:

Hardware	: BCM2835

I'm not sure when this changed. I powered up another Pi 3 with an older version of Jessie on it and it reports

Hardware	: BCM2709

I also checked my Genesis Pi 3 which is as up to date as the Super Famicom Pi 3 and it's also reporting BCM2709. I'm thinking that when I applied the Raphnet patch to the kernel, that new chip identification came in to play.

To try to fix the issue I tried updating the function, rezipping the .egg and replacing the original Adafruit one.

With that modified module in place, the screen is once again working. Kind of. I'm getting garbled output, but at least it's doing something.

obsidianspider

I updated RetroPie to 4.1.17 just now, and thinking that maybe there may be a kernel update reapplied (there wasn't) I rebooted. The display was perfect! I checked the CPU and it's still reporting as a BCM2835. Then I went into a game, and the screen was back to garbled. At this point I'm thnking I may have a loose connection after removing and reinserting the cartridge.

Yes, I did try taking it out, blowing on it, and sticking it back in ;)

(I know that doesn't really work)

obsidianspider

I confirmed it's not a loose connection. I took the case apart, checked the wires, and the display was still giving garbled output. I then decided to try dusting off the pygame stuff I had been messing with months ago, and sure enough, the display works perfectly. (there's a cursor in the top left, which I don't remember before, but it's clearly not bad output.)

Now that I know it's a software issue with the Adafruit stuff, I need to figure out what the heck is going on with the garbledocity of its output.

obsidianspider

I managed to turn off the mouse pointer in pygame but pygame tends to chew up CPU cycles to the point that it's noticably slower when I SSH in. I could press on with making pygame respond to runcommand, but I'd really rather get this Adafruit stuff working again.

I'm not sure how to troubleshoot the scrambled display output. At least when I had that initial error message I had something to go on, but I'm not sure about where to create logs/traces while the python code is running to see what's going on.

Frustrating.

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.

0_1488580125970_Screen Shot 2017-03-03 at 5.28.01 PM.png

obsidianspider

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

0_1488582974609_Screen Shot 2017-03-03 at 6.15.48 PM.png

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.