The driver doesn't work anymore

[paractmol]

After a few days of usage, the Inky examples don't work anymore. First I thought, the screen had some defect, but then, just in the case decided to check out how Waveshare reacts to Inky displays. It turns out the hardware still works, but something wrong with the inky.inky_uc8159 driver. It looks like it is blocked or something. Did anyone have experienced it before?

Right now to clean or render any image, I need to do the following:

1. I render image with the code:

   
   from PIL import Image
   from inky.inky_uc8159 import Inky

inky = Inky() saturation = 0.5

image = Image.open(image_path)

inky.set_image(image, saturation)

2. After the research, I found the specific parts that makes it work.
```python
import spidev
import RPi.GPIO
SPI = spidev.SpiDev()
GPIO = RPi.GPIO

RESET_PIN = 17
BUSY_PIN = 24
DC_PIN = 25
CS0_PIN = 8

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(RESET_PIN, GPIO.OUT)
GPIO.setup(DC_PIN, GPIO.OUT)
GPIO.setup(CS0_PIN, GPIO.OUT)
GPIO.setup(BUSY_PIN, GPIO.IN)

SPI.open(0, 0)
SPI.max_speed_hz = 4000000
SPI.mode = 0b00

RPi.GPIO.output(DC_PIN, 0)
RPi.GPIO.output(CS0_PIN, 0)
SPI.writebytes([0x82])
RPi.GPIO.output(CS0_PIN, 1)

RPi.GPIO.output(DC_PIN, 1)
RPi.GPIO.output(CS0_PIN, 0)
SPI.writebytes([0x12])
RPi.GPIO.output(CS0_PIN, 1)

Only after the last block is triggered, it does the magic.

Update:

Similar to that issue: https://forums.pimoroni.com/t/inky-phat-doesnt-update-display/5379/7

[Gadgetoid]

The UC8159 driver could be getting stuck in a "busy_wait" condition after sending the display data. Your second command - 0x12 - is Display Refresh which is what would normally cause that new data to be displayed.

You've pretty much got the latter half of _update() there:

https://github.com/pimoroni/inky/blob/421fe1bbf05c23a5a40b20948e510f804fd5d25e/library/inky/inky_uc8159.py#L301-L322

We seem to be getting intermittent issues with hangs on _busy_wait() and I've been unable to replicate them. I wonder if it would be worth limiting the wait period to something shorter and more reasonable, and removing the RuntimeError in a timeout condition.

In retrospect it's unclear to me why there would need to be a busy wait after writing data anyway. It's needed after display refresh to avoid triggering a new refresh during an existing cycle, but it seems like DTN1, PON and POF at most need a short, fixed delay.

[paractmol]

Thanks for the reply. Yeah, I was getting an issue with a timeout error first, but I presume I had to increase it because of the slowness of my raspberry pi. I did increase the time from 30 to 60, and then it worked fine. The issue was gone entirely, even when I reinstalled the driver.

The new issue happened after a day or two, which was super weird. I thought it was dead and randomly ran the examples from Waveshare. Even though they didn't work (cause of different pins, I suppose), it triggered the mentioned refresh. I debugged what it triggers without all the abstractions and found out that I needed to trigger this to make it refresh.

RPi.GPIO.output(DC_PIN, 1)
RPi.GPIO.output(CS0_PIN, 0)
SPI.writebytes([0x12])

For now, my app executes this code to make it refresh. Maybe I'll try to play around with the driver a bit more to figure out how I can fix it in the driver itself, so I wouldn't need to make a workaround.

Earlier today I have tried to make some changes to the driver, but all were unsuccessful. They were either only refreshing the border with red color or nothing much. For now, I have decided to go with the mentioned workaround.

[helgibbons]

Replacing the calls to busy_wait() in the driver with some short sleep times does seem to have resolved (side-stepped?) some rather persistent Timeout waiting for busy signal to clear issues for me.

[espoal]

I'm having the same issue but @rrubyist code didn't fix the issue :(

I'm using Raspbian lite on a Raspberry pi zero 2 W, with pre-soldered headers.

pi@raspberrypi:~/Pimoroni/inky/examples $ uname -a
Linux raspberrypi 5.10.63-v7+ #1488 SMP Thu Nov 18 16:14:44 GMT 2021 armv7l GNU/Linux
pi@raspberrypi:~/Pimoroni/inky/examples $ python3 identify.py 
Found: Black pHAT (SSD1608)
Display: 212x104
Color: black
PCB Variant: 1.2
Display Variant: 10
Time: b'2021-07-12 14:48:16.7'
pi@raspberrypi:~/Pimoroni/inky/examples $ 

Any command like python3 clean.py or python3 logo.py doesn't produce any display change or errors, the console seems fine.

Funny thing: yesterday evening was working, this morning I tried again and it's dead :(

@Gadgetoid is there anything I could do to help you debug the issue?

[Gadgetoid]

Funny thing: yesterday evening was working, this morning I tried again and it's dead :(

@Gadgetoid is there anything I could do to help you debug the issue?

@espoal double check that it's connected to the Pi firmly. Looks like you're using an SSD1608-based Inky pHAT and this issue relates to the UC8159-based Inky Impressions.

In your case the above code would be wrong for your display type, but there could be any number of other things awry. Did you install any additional software between it working and not working? Anything that might be running in the background and interfering with the GPIO?

[embersdev]

I am having the same issue on my pi zero 2. Example scripts all run fine, but nothing changes on the screen. I have 2 pi zeros, tested it on both with no luck. I do have an enviro+ which works just fine.

I currently have the pi headless 64bit running, but to rule that out, installed 32bit desktop. No dice.

Is there a specific script/test i can run to confirm whether its a bad display or not?

Its brand new, never worked.

[Gadgetoid]

@embersdev which display?

[embersdev]

Inky Phat Red. I actually got a reply from support and they stated its not supported on bullseye. I tried 32 and 64 bit bullseye, but plan to test installing the legacy os tonight see if it works on that.

[Gadgetoid]

Bullseye has been a bit of a debacle, but I don't see any reason why Inky shouldn't work (I suspect they mean the one-line installer will refuse to run, but I've fixed that now). I'm firing up a 64bit Bullseye (worst case) now to see what happens.

[Gadgetoid]

Just tested a new-ish red phat with a fresh 64bit Bullseye install and it works.

If it's not auto-detecting (you can test with python3 identify.py), try:

python3 name-badge.py --type phatssd1608 --colour red --name "Hello World"

(Both these python files are in examples/ of this repo)

[embersdev]

I tweaked the install script to make it work with bullseye also. Anywho, nothing is working to update the screen so I will assume its a bad screen and buy a new one I guess.

To be clear, all of the examples run just fine. It just doesnt actually update the screen.

[Gadgetoid]

Oh there's also a chance it could be a really, really old Inky pHAT - pre EEPROM - and supported by the old library. How long have you had it?

Edit: Old library is here: https://github.com/pimoroni/inky-phat

[embersdev]

Its not I get this when I run identify.

Found: Red pHAT (SSD1608) Display: 212x104 Color: red PCB Variant: 1.2 Display Variant: 11 Time: b'2021-06-02 12:31:37.2'

[Gadgetoid]

Well the EEPROM works at least. I'd fully expect explicitly updating with the SSD1608 type to work, ie from above:

python3 name-badge.py --type phatssd1608 --colour red --name "Hello World"

Guessing not that old, then? You should drop a line to support@pimoroni.com to see if they can sort you out with a replacement.

[Camper71]

I'm having the same issue. The Impression doesn't display when I run the examples...however if I try a Omni waveshare driver the previous example I ran will refresh on the screen. here is a link to my forum post:

https://forums.pimoroni.com/t/inky-impression-challenges/18704

[fotosyn]

The solution provided by @rrubyist worked for me. Thanks for helping me unbrick two units I have here. But I find I need to call this script to actuate any updates that have been sent to the Inky... so while it solves the problem it doesn't restore out of the box behaviours for me.

[Gadgetoid]

@fotosyn

This is tricky to nail down since I still don't have a panel I can replicate this with, but try installing the test library:

pip install -i https://test.pypi.org/simple/ inky==1.3.2

And see if that works without the hacks from @rrubyist

[fotosyn]

Mine's is on its way back to you so hopefully you can tinker with that one 👍

[Gadgetoid]

Excellent! (Albeit sorry for the trouble this is causing you!) I've been making do with a jumper wire to short the busy_wait pin!

[Gadgetoid]

@fotosyn I've got my hands on it, and managed to get it updating. The problem was the polar opposite to what I expected- busy_wait is exiting immediately which means the library does not wait long enough for the panel to power on, finish receiving data and so forth.

The fix is completely counter to the one posted above, but I should be able to merge them both into a fault tolerant solution that can function without busy_wait.

As for why busy_wait is faulty like this- I'll have to investigate!

[paractmol]

@fotosyn

This is tricky to nail down since I still don't have a panel I can replicate this with, but try installing the test library:

pip install -i https://test.pypi.org/simple/ inky==1.3.2

And see if that works without the hacks from @rrubyist

I am sorry for the late reply, I've tested 1.3.2 and it fixes the issue for me too! Thanks!

[paractmol]

And, unfortunately, again, it stopped working. I had to reinstall Raspberry Pi and install the latest driver. I was checking the available examples. Executed clean.py

It shows the following, and nothing happens to the screen itself.

Inky pHAT: Clean

Displays solid blocks of red, black, and white to clean the Inky pHAT
display of any ghosting.

Detected 7-Colour (UC8159)
Cleaning cycle 1

- updating with multi
/home/pi/.local/lib/python3.9/site-packages/inky/inky_uc8159.py:303: UserWarning: Busy Wait: Held high. Waiting for 1.00s
  warnings.warn("Busy Wait: Held high. Waiting for {:0.2f}s".format(timeout))
/home/pi/.local/lib/python3.9/site-packages/inky/inky_uc8159.py:303: UserWarning: Busy Wait: Held high. Waiting for 0.20s
  warnings.warn("Busy Wait: Held high. Waiting for {:0.2f}s".format(timeout))
/home/pi/.local/lib/python3.9/site-packages/inky/inky_uc8159.py:303: UserWarning: Busy Wait: Held high. Waiting for 32.00s
  warnings.warn("Busy Wait: Held high. Waiting for {:0.2f}s".format(timeout))

- updating with black
- updating with white

Cleaning cycle 2

- updating with multi
- updating with black

[ericcastro]

I can't make work any of the workarounds posted here and others too ?

I really need help unbricking this thing

EDIT: I was able to determine - in my case - why this same error was happening and why none of the workarounds posted were working, hopefully this will be useful to others:

the ribbon flex cable was faulty, and I was -most of the time- getting the error that the busy pin was held high.... but occassionally would get the panel to update, albeit erratically (some colors were not showing, screen refreshes were not constant). I tried pushing a bit the ribbon cable with my finger to the inside and it all magically started working again - for as long as I pushed the ribbon cable. when I let it go, problem would come back instantly.

my personal workaround: 3D print a case that would hold the whole board and panel in place AND push the ribbon cable for me. this is of course a temporary solution as I believe it will break definitely eventually and I will need a replacement. I wish I could just go to a store and get a new ribbon cable.

luckily, pimoroni has been amazing in customer support in helping me out, but I still wanted to post this in case anyone has the same issue as me