issues with Adafruit ST7789 240x280 display

[spencertweed]

I'm trying to run this on a raspberry pi zero w 2 with the adafruit rounded TFT display wired in SPI and I'm getting various issues.

Specifically the top 40 or so rows of pixels are just snowy fuzz. Looking into the printed lines of the terminal output I see that the driver assumes that the display is 240 x 240 when it is not. Changing st7735r.h DISPLAY_NATIVE_HEIGHT to 280 seems to have fixed this but I just get a row of snowy fuzz at the top of the screen now. I ran into the same issue with the adafruit Circuitpython library when running the st7789 script there and fixed it by setting the vertical offset to 20 pixels.

I'm also getting 2 columns of noise stretching vertically down the screen. Not sure what that is all about...

Lastly the display seems to be reversed horizontally!

Any help would be greatly appreciated. I know it is possible to fix because I was able to get everything working in python with the circuitpython module, so I'm sure it is just a matter of getting the settings right.

• Spencer

[spencertweed]

Additionally I am having problems shutting my pi down via a shell script since running the driver, which is a bit odd. Haven't been able to nail this one down yet but I believe it is related to this driver because when I try to quit the software via the commandline (ctrl+c) it just says "CSignal SIGINT (2) received, quitting" but then just stalls and never quits. sending a kill command does the same. Kill -9 does shut it down though.

[juj]

Adjusting the MADCTL register helps to flip the display horizontally.

Also I recall there may be some kind of offset in how the display controller reads the memory depending on MADCTL register values. E.g. if the height is 280 pixels, it could be that the pixels for those rows are located on memory rows [40, 319] instead of rows [0, 279]. Try adjusting this offset register: https://github.com/juj/fbcp-ili9341/blob/4aa3b97f4d295e3301651bd3dc3d314b25f2531e/st7735r.cpp#L95

[juj]

I have also seen the inability to shut down cleanly in some cases, not sure what causes that, I did not get to the bottom of it.

[spencertweed]

Thanks for the reply, I'll try it out. What is the MADCTL register?

[juj]

MADCTL is

https://github.com/juj/fbcp-ili9341/blob/4aa3b97f4d295e3301651bd3dc3d314b25f2531e/st7735r.cpp#L42-L69

[spencertweed]

I was able to fix the vsync issues as you suggested but I'm a little lost in the cpp syntax when it comes to flipping the column order (I'm more of a python guy...). Looks like around line 45 is the right area as you said but I'm not sure what exactly to adjust. Can you give me some pointers on what to change (no pun intended)?

• Spencer

[spencertweed]

Ok figured out how to shift the bits to swap the screen! Last bug is a bit more nebulous... which is that the screen seems to freeze after a few seconds. I saw the note in the readme.md to disable DMA and increase the SPI bus divisor, neither of which seem to have fixed it. I assume this is related to the quitting issue because it seems to be that when the screen freezes it does not want to quit gracefully. When I list the processes in linux (ps aux) I notice that there are 2 fbcp processes running, one as root one as user. Is that just a child thread or might that have something to do with the problem?

[juj]

If there are two fbcp-ili9341 processes running, then that is certainly an issue and will cause a crash. There should be only one.

However that one fbcp-ili9341 process will spawn a child thread, but that is a thread in the same process, not a new process. The thread will have the same user as the main thread (threads in same process cannot run under different user auth).

Maybe there's a startup script that is spawning fbcp-ili9341 already as root?

[spencertweed]

Ok I figured it out! Whenever the display is inactive for a few seconds it crashes, presumably when it goes to "sleep". I verified this by enabling NO_THROTTLING and it works beautifully, it just sucks 40% of my CPU continuously. Disabling SAVE_BATTERY_BY_SLEEPING_WHEN_IDLE improved CPU load and I've been running for a few minutes now with no crashes, so that seems to do the trick. That also fixed the quitting issues on shutdown btw.

Scratch what I was saying about the 2 processes, I'm new to linux and didn't fully understand the process status command - it was actually just the one process.

So what's the issue with sleeping? Is there something I can look into to find the bug, and is it worth fixing? I'm not super concerned with battery life and I can live with the 15% CPU load it currently draws, but if this is something fixable I'd like to fix it.

[matsondawson]

I have the same display and don't have the crashing issue. It appears internally it's a 320 x 240 display. Someone kindly posted some mods to fix the offset here. https://github.com/juj/fbcp-ili9341/issues/298

[matsondawson]

Even better, set this: st7735r.cpp

Line 95: SPI_TRANSFER(0x37/*VSCSAD: Vertical Scroll Start Address of RAM*/, 0, 0);

st7735r.h

#if defined(ST7789) || defined(ST7789VW)
#define DISPLAY_NATIVE_WIDTH 240
#define DISPLAY_NATIVE_HEIGHT 300
#define DISPLAY_NATIVE_COVERED_TOP_SIDE 20