Incomplete fillscreen in landscape mode

[N0ury]

With tft.setRotation(0) and tft.setRotation(2) everything works fine.
With tft.setRotation(1) and tft.setRotation(3) all functions work fine except fillscreen.

My screen is W 320, H 240 (in portrait mode).
Documentation says it is a ST7789V (note the V at the end).
It's a display from STM and I use it with two different STM boards.

When I use tft.setRotation(1) or 3, orientation is good, all writings are good too, but fillscreen doesn't fill the screen completly. The rest is either garbage, or previous background if I don't disconnect the screen when flashing the new sketch.

I don't understand what happens.

Here's an extract of my platformio.ini:

build_flags =
        -D USER_SETUP_LOADED=1
        -D STM32=1
        -D NUCLEO_64_TFT=1
        -D TFT_INVERSION_OFF=1
        -D ST7789_DRIVER=1
        -D TFT_WIDTH=240
        -D TFT_HEIGHT=320
        -D TFT_MISO=PA6
        -D TFT_MOSI=PA7
        -D TFT_SCLK=PA5
        -D TFT_CS=PA9
        -D TFT_DC=PB10
        -D TFT_RST=PA1
        -D SPI_FREQUENCY=80000000
        -D TFT_RGB_ORDER=TFT_BGR ; Colour order Red-Green-Blue
        -D LOAD_GLCD=1   ; Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
        -D LOAD_FONT2=1  ; Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
        -D LOAD_FONT4=1  ; Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
        -D LOAD_FONT6=1  ; Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
        -D LOAD_FONT7=1  ; Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:-.
        -D LOAD_FONT8=1  ; Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.
        -D LOAD_GFXFF=1  ; FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts
        -D SMOOTH_FONT=1

Here's a small code that produces the problem

#include <Arduino.h>
#include <SPI.h>
#include <TFT_eSPI.h>

TFT_eSPI tft = TFT_eSPI();

void setup() {
        tft.begin();
        tft.setRotation(1);
        tft.fillScreen(TFT_RED);
        tft.setCursor(10,10);
        tft.setTextColor(TFT_WHITE, TFT_BLACK);
        tft.println("Hello World!");
}

void loop() { }

And the result:

Here's an other display showing good drawing but bad background

[Bodmer]

Run the Read_User_Setup sketch and post the serial monitor output.

[Bodmer]

Also drop the SPI clock rate to 40MHz, 80MHz is marginal and may cause screen commands to fail.

[N0ury]

Here's the result

[code]
TFT_eSPI ver = 2.5.33
Processor    = STM32
Transactions = Yes
Interface    = SPI
Display driver = 7789
Display width  = 240
Display height = 320

MOSI    = GPIO -58
MISO    = GPIO -57
SCK     = GPIO -49

>>>>> Note: STM32 pin references above D15 may not reflect board markings <<<<<
TFT_CS   = D8
TFT_DC   = D6
TFT_RST  = D-63

Font GLCD   loaded
Font 2      loaded
Font 4      loaded
Font 6      loaded
Font 7      loaded
Font 8      loaded
Smooth font enabled

Display SPI frequency = 80.00
[/code]

[Bodmer]

I checked the ST7789V data sheet and the maximum recommended SPI clock rate is 15MHz, so 80MHz is likely to be pushing the over-clocking too far.

[N0ury]

same with SPI_FREQUENCY=15000000

[N0ury]

Also drop the SPI clock rate to 40MHz, 80MHz is marginal and may cause screen commands to fail.

It's the same with SPI_FREQUENCY=40000000

[Bodmer]

OK, try the alternative driver:

-D ST7789_2_DRIVER=1

[N0ury]

I checked the ST7789V data sheet and the maximum recommended SPI clock rate is 15MHz, so 80MHz is likely to be pushing the over-clocking too far.

I checked the ST7789V data sheet and the maximum recommended SPI clock rate is 15MHz, so 80MHz is likely to be pushing the over-clocking too far.

OK, try the alternative driver:

-D ST7789_2_DRIVER=1

It's the same but colours are inverted.

[Bodmer]

OK, this seems to be a problem peculiar to that display, processor or software environment. An ESP32 and RP2040 works fine in my setup with that display driver.

Have you changed the compiler optimisation settings?
Which version of the STM board support package are you using.

[N0ury]

OK, this seems to be a problem peculiar to that display, processor or software environment. An ESP32 and RP2040 works fine in my setup with that display driver.

Have you changed the compiler optimisation settings? Which version of the STM board support package are you using.

I use PlatformIO without any changes
I use the command pio run -e clck2 -t upload

Here's the full platformio.ini file

; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[env]
platform = ststm32
board = nucleo_f411re
framework = arduino
monitor_port = hwgrep://0483:374b
upload_port = hwgrep://0483:374b
monitor_speed = 115200
lib_deps = TFT_eSPI
	SPI
	bodmer/TFT_eWidget@^0.0.6
	bodmer/TFT_eSPI@^2.5.33
build_flags = 
	-D USER_SETUP_LOADED=1
	-D STM32=1
	-D NUCLEO_64_TFT=1
	-D TFT_INVERSION_OFF=1
#	-D STM_PORTA_DATA_BUS=1
#	-D STM_PORTB_DATA_BUS=1
	-D ST7789_2_DRIVER=1
	-D TFT_WIDTH=240
	-D TFT_HEIGHT=320
	-D TFT_MISO=PA6
	-D TFT_MOSI=PA7
	-D TFT_SCLK=PA5
	-D TFT_CS=PA9
	-D TFT_DC=PB10
	-D TFT_RST=PA1
	-D SPI_FREQUENCY=15000000
	-D TFT_RGB_ORDER=TFT_BGR ; Colour order Red-Green-Blue
        -D LOAD_GLCD=1   ; Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
        -D LOAD_FONT2=1  ; Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
        -D LOAD_FONT4=1  ; Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
        -D LOAD_FONT6=1  ; Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
        -D LOAD_FONT7=1  ; Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:-.
        -D LOAD_FONT8=1  ; Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.
#       -D LOAD_FONT8N=1 ; Font 8. Alternative to Font 8 above, slightly narrower, so 3 digits fit a 160 pixel TFT
        -D LOAD_GFXFF=1  ; FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts
        -D SMOOTH_FONT=1

[env:main]
build_src_filter = +<main.cpp>

[env:ex]
build_src_filter = +<ex.cpp>

[env:arc]
build_src_filter = +<arc.cpp>

[env:clck2]
build_src_filter = +<clck2.cpp>

[env:colour]
build_src_filter = +<colour.cpp>

[env:sys]
build_src_filter = +<sys.cpp>

Is this what you asked me for?

[N0ury]

Here's also the json file for my board. It's the PlatformIO native one.
Not sure if this helps.

{
  "build": {
    "core": "stm32",
    "cpu": "cortex-m4",
    "extra_flags": "-DSTM32F411xE",
    "f_cpu": "100000000L",
    "mcu": "stm32f411ret6",
    "product_line": "STM32F411xE",
    "variant": "STM32F4xx/F411R(C-E)T"
  },
  "debug": {
    "default_tools": [
      "stlink"
    ],
    "jlink_device": "STM32F411RE",
    "onboard_tools": [
      "stlink"
    ],
    "openocd_board": "st_nucleo_f4",
    "openocd_target": "stm32f4x",
    "svd_path": "STM32F411xx.svd"
  },
  "frameworks": [
    "arduino",
    "cmsis",
    "mbed",
    "stm32cube",
    "libopencm3",
    "zephyr"
  ],
  "name": "ST Nucleo F411RE",
  "upload": {
    "maximum_ram_size": 131072,
    "maximum_size": 524288,
    "protocol": "stlink",
    "protocols": [
      "jlink",
      "cmsis-dap",
      "stlink",
      "blackmagic",
      "mbed"
    ]
  },
  "url": "https://developer.mbed.org/platforms/ST-Nucleo-F411RE/",
  "vendor": "ST"
}

[Bodmer]

I don't use PlatformIO but it all looks good. I will do some experiments tomorrow with a similar setup.

It is a rather peculiar fault signature which does not make sense!

Are you sure it is an ST7789V?

[N0ury]

I don't use PlatformIO but it all looks good. I will do some experiments tomorrow with a similar setup.

Thanks for your help!

It is a rather peculiar fault signature which does not make sense!

Are you sure it is an ST7789V?

Doc says there are three boards:

6.2 X-NUCLEO-GFX01M1 product history
6.2.1 Product identification XNGFX01M1$AZ1
This product identification is based on board MB1642-DT022CTFT-B01. The LCD used in this product is
DT022CTFT with driver IC ILI9341V.
Product limitations
No limitation identified for this product identification.

6.3 X-NUCLEO-GFX01M2 product history
6.3.1 Product identification XNGFX01M2$AZ1
This product identification is based on board MB1642-TCXD022IB5-D01. The LCD used in this product is
TCXD022IBLON-5 with driver IC ST7789V.
Product limitations
No limitation identified for this product identification.

6.3.2 Product identification XNGFX01M2$AZ2
This product identification is based on board MB1642-DT022CTFT-D01. The LCD used in this product is
DT022CTFT with driver IC ILI9341V.

I use the second one: X-NUCLEO-GFX01M2 (XNGFX01M2$AZ1)
This ref is visible on the previous photos.

[Bodmer]

I have run some tests and reproduced the problem.

I have a work-around for you until I track down what is happening. Add the following line after tft.begin();

tft.fillScreen(TFT_BLACK);

So your example should now look like this:

#include <Arduino.h>
#include <SPI.h>
#include <TFT_eSPI.h>

TFT_eSPI tft = TFT_eSPI();

void setup() {
        tft.begin();
        tft.fillScreen(TFT_BLACK);
        tft.setRotation(1);
        tft.fillScreen(TFT_RED);
        tft.setCursor(10,10);
        tft.setTextColor(TFT_WHITE, TFT_BLACK);
        tft.println("Hello World!");
}

void loop() { }

This then works and the screen is filled with red.

The extra line should not be needed, so I will have to track down the root cause.

[N0ury]

@Bodmer it works fine this way.
I have tried it with two steches and both work fine now.
It's a good workaround in the sens that it doesn't drop performance, and it's very easy.
Tell me when you will have solved definetly the issue and I will test again.
In the meantime do I have to close the discussion or leave it open?
Maybe opening an issue should be good.

[N0ury]

@Bodmer I've found that removing this line solves the problem too:

-D STM32=1

[Bodmer]

Removing that line will invoke the slower generic driver and is not recommended.

[Bodmer]

The problem is specific to the STM32F processors when used with the ST7789V driver.

There was a temporary fix done a long time ago to get around a problem #510 with that particular combination here:
https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/TFT_eSPI_STM32.h#L1030

Changing the line to to disable the patch fixes the problem for ST7789V displays:
#if defined(xxxST7789_DRIVERxxx) || defined(xxxST7789_2_DRIVERxxx)

This appears to be an issue with timing or line states as the two code lines should be equivalent.

I will have to check if the fix breaks the library for the older ST7789 chips and older board packages before implementing it. I may have to create a specific driver switch for the V display variant.

[Bodmer]

I have updated the master library via #2942

Thanks for reporting this.

[N0ury]

I've just tried the new lib, everything works fine. Thanks for everything, and especially for your responsiveness.