Black Pill with adafruit ST7789

[heretop]

I have no more clue for your issue. Only debug can help on this as I do not have this board.

I finally got my command line debug working through st link. https://gist.github.com/ht93/93f4ed2667 ... 8e053403e3 is the debug log of my code (2.0.0 core, display not working). However it only runs 'Adafruit_ST7789 tft = Adafruit_ST7789(&SPI_1, TFT_CS, TFT_DC, TFT_RST);' and part of 'tft.init(240, 320);' since it's too long and running similar command for a long time. Let me know how can I provide enough info.

Code: Select all

//#include "pins_arduino.h"
//#include "wiring_private.h"
//#define ARDUINO_STM32_FEATHER 1
#include <SPI.h>
#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7789.h> // Hardware-specific library for ST7789

// https://learn.adafruit.com/2-0-inch-320-x-240-color-ips-tft-display?view=all#arduino-wiring-test
// https://cdn-learn.adafruit.com/downloads/pdf/adafruit-gfx-graphics-library.pdf?timestamp=1620544055

#define TFT_CS    PA4//8
#define TFT_DC    PB1//9
#define TFT_RST   PB0//10
#define TFT_MOSI    PA7//PB15//11
#define TFT_SCLK    PA5//PB13//13

SPIClass SPI_1(PA7, PA6, PA5);
//SPIClass SPI_2(PB15, PB14, PB13);

//Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_RST);
//Adafruit_ST7789 tft = Adafruit_ST7789(&SPI_1, TFT_CS, TFT_DC, TFT_RST);
//Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

int value = 0;

void setup(void) {
  delay(10000);
//  delay(1000);
//  delay(5000);
  Adafruit_ST7789 tft = Adafruit_ST7789(&SPI_1, TFT_CS, TFT_DC, TFT_RST);
  tft.init(240, 320);           // Init ST7789 320x240
  tft.fillScreen(ST77XX_BLACK);
  tft.setRotation(1);
  tft.setTextWrap(false);
  tft.setTextColor(ST77XX_WHITE, ST77XX_BLACK);
  tft.setTextSize(5);
  tft.setCursor(0, 75);
  tft.println("test");
  tft.setCursor(0, 125);
  tft.println("test1");

[ag123]

while you are debugging, did it 'freeze' anywhere?
i've a little suggestion
place

Code: Select all

Serial.println("before calling xxyy");

style codes to trace execution for the various tft.method() calls, you could interleave that in your sketch.
you can run the sketch with the various Serial.println() interleaved without doing any debug.

did it just run through all that prints? or did the run 'freeze' at any particular location?

the last time when i'm troubleshooting an lcd issue - the lcd is ili9341 spi
i get similar blank screen issues.
viewtopic.php?p=5769#p5769

in my codes i intersparsed various other codes to read and print the various lcd registers. the purpose of which is to assure myself that there is no problem with the spi comms. if you can send commands to the lcd to retrieve values of the status registers, it would help tell if spi itself isn't the problem.

initially i get corrupted register values coming from the lcd. it turns out that the lcd reset pin is needed for ili9341 lcd, and before the lcd init or rather as part of the init, i need to pull the lcd reset pin low to reset the lcd, then there is a bunch of initialization commands which needs to be sent, this block of initialization commands needs to be sent *after* the reset pin pulled reset is done.

once i got through this, the whole graphics test sketch and various things just works, no errors, no freezes whatsoever.
after i fixed the issue related to my ili9341 spi lcd display, this is the result of the graphics test run. prior before it is fixed, it is just a blank screen and nothing is displayed.
https://www.youtube.com/watch?v=MdySCPK6Dkw

[heretop]

while you are debugging, did it 'freeze' anywhere?
i've a little suggestion
place

Code: Select all

Serial.println("before calling xxyy");

style codes to trace execution for the various tft.method() calls, you could interleave that in your sketch.
you can run the sketch with the various Serial.println() interleaved without doing any debug.

did it just run through all that prints? or did the run 'freeze' at any particular location?

the last time when i'm troubleshooting an lcd issue - the lcd is ili9341 spi
i get similar blank screen issues.
viewtopic.php?p=5769#p5769

in my codes i intersparsed various other codes to read and print the various lcd registers. the purpose of which is to assure myself that there is no problem with the spi comms.

My code does not freeze at any location. I have put a blink led in the loop and my display setup and tft.println() in the setup. I always get the led blinking but no display. The debug gist I shared are the many lines of line by line debug output. Since it also contains the value of each variable for each function call, I think it could be good info.

[ag123]

this would suggest a 'comms' issue with the lcd, would you be able to check if there is some sort of a 'reset pin' way to reset the lcd like i've encountered with ili9341 spi lcd? if there is you may want to wire up that pin and pull lcd reset low for a while prior letting the rest of the lcd init codes run

[heretop]

this would suggest a 'comms' issue with the lcd, would you be able to check if there is some sort of a 'reset pin' way to reset the lcd like i've encountered with ili9341 spi lcd? if there is you may want to wire up that pin and pull reset low for a while prior letting the rest of the lcd init codes run

There is already a reset pin which is always connected and set in the function call. There is another pin which control the backlight, I have make it float and the backlight is always on. I also tested it once by toggle it, but it only change the on and off of backlight. Still no display regardless of the backlight value.

[ag123]

i think Adafruit lcd library actually takes care of using that reset pin, another thing though is to dig in to the lcd library code itself where it does the reset to see if you can keep the pin low for a longer period say like 1 ms or more, this is kind of to be assured that the lcd after all does a reset.

[TFTLCDCyg]

Reviewing thoroughly, in the STM32 2.0.0 kernel all the pins with all their possible functions are defined. The question is: does a conflict arise when having defined a multiplicity of tasks assigned to a certain pin when we only use it with a specific task ?, such as SPI port 1 with pins PA4, PA5, PA6 and PA7.

Core 2.0.0: Nucleo F767 + FT813 TFT only black Screen!

I did a little exercise with the Nucleo F767ZI board, I copied all the pin definitions from the STM 1.9.0 core (PeripheralPins.c) and substituted it in the pin definitions from the STM 2.0.0 core (PeripheralPins.c), the NHD screen FT813 of 3.5 " now is answered without problems en el kernel 2.0.0 !!!!

[heretop]

I did a little exercise with the Nucleo F767ZI board, I copied all the pin definitions from the STM 1.9.0 core (PeripheralPins.c) and substituted it in the pin definitions from the STM 2.0.0 core (PeripheralPins.c), the NHD screen FT813 of 3.5 " now is answered without problems en el kernel 2.0.0 !!!!

May I confirm that you just overwrite the 2.0.0 core (PeripheralPins.c) with STM 1.9.0 core (PeripheralPins.c)? I did that but I got error:

Code: Select all

C:\Users\E1200\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.0.0\libraries\SrcWrapper\src\stm32\analog.cpp: In function 'uint32_t get_pwm_channel(PinName)':
C:\Users\E1200\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.0.0\libraries\SrcWrapper\src\stm32\analog.cpp:262:44: error: 'PinMap_TIM' was not declared in this scope; did you mean 'PinMap_PWM'?
  262 |   uint32_t function = pinmap_function(pin, PinMap_TIM);
      |                                            ^~~~~~~~~~
      |                                            PinMap_PWM
C:\Users\E1200\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.0.0\libraries\SrcWrapper\src\stm32\analog.cpp: In function 'void pwm_start(PinName, uint32_t, uint32_t, TimerCompareFormat_t)':
C:\Users\E1200\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.0.0\libraries\SrcWrapper\src\stm32\analog.cpp:1016:65: error: 'PinMap_TIM' was not declared in this scope; did you mean 'PinMap_PWM'?
 1016 |   TIM_TypeDef *Instance = (TIM_TypeDef *)pinmap_peripheral(pin, PinMap_TIM);
      |                                                                 ^~~~~~~~~~
      |                                                                 PinMap_PWM
C:\Users\E1200\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.0.0\libraries\SrcWrapper\src\stm32\analog.cpp: In function 'void pwm_stop(PinName)':
C:\Users\E1200\AppData\Local\Arduino15\packages\STMicroelectronics\hardware\stm32\2.0.0\libraries\SrcWrapper\src\stm32\analog.cpp:1046:65: error: 'PinMap_TIM' was not declared in this scope; did you mean 'PinMap_PWM'?
 1046 |   TIM_TypeDef *Instance = (TIM_TypeDef *)pinmap_peripheral(pin, PinMap_TIM);
      |                                                                 ^~~~~~~~~~
      |                                                                 PinMap_PWM

The PinMap_TIM here in 2.0.0 was PinMap_PWM in 1.9.0, and another function used this PinMap_TIM.

[ag123]

there is one more particularity about adafruit lcd libraries
https://github.com/adafruit/Adafruit-ST ... 77xx.h#L93

Code: Select all

  Adafruit_ST77xx(uint16_t w, uint16_t h, int8_t CS, int8_t RS,
                  int8_t RST = -1);

which is that the reset pin is defined as an int8_t with a default value of -1. this can be a catch if for example a pin code of > 0x80 (127) is used.
on stm32 this may not be a 'surprise' as the pin may be an encoded form of a port / pin combo e.g. higher 4 bits is the port and lower 4 bits is the pin.
e.g. PA03 may be 0b 00010011, but that there is a chance the 8th bit could be marked as a 1 bit and it could be treated as a negative number due to the integer conversions.
erm, uh
for resaons i'm not sure it seemed adafruit doesn't use the reset pin for the st77xx series.
https://github.com/adafruit/Adafruit-ST ... ST77xx.cpp
instead a software reset is sent
https://github.com/adafruit/Adafruit-ST ... 89.cpp#L53

one of those things to try is

Code: Select all

// toggle TFT_RST to reset the lcd
pinMode(TFT_RST, OUTPUT);
digitalWriteTFT_RST, LOW);
delay(1); //ms, use a longer period if necessary
digitalWriteTFT_RST, HIGH);
delay(1)

... call the tft.init() or tft.begin() codes to initialize the lcd

this may after all help, if we assume that for an unknown reason the tft-lcd baud rates is out of sync (stm32 has very fast spi interfaces, not all peripherals can catch up) and the baud rates is off. doing 'hardware' lcd reset may help here as it would make the lcd retrain the baud rates.
i've observed this prior with ili9341 lcd, before that 'hardware' lcd reset, i simply received 'corrupted' status bytes from reading lcd registers.
doing this reset alone 'fixed' that and the register values that i read subsequently after that 'lcd pin reset' give sane values after that

[mrburnette]

...
I did a little exercise with the Nucleo F767ZI board, I copied all the pin definitions from the STM 1.9.0 core (PeripheralPins.c) and substituted it in the pin definitions from the STM 2.0.0 core (PeripheralPins.c), the NHD screen FT813 of 3.5 " now is answered without problems en el kernel 2.0.0 !!!!

A better approach (IMO):
https://winmerge.org/

An "overwrite" does no one any good at explaining the strange behavior as it leaves the question of corrective action(s) unknown.

this would suggest a 'comms' issue with the lcd ...

I agree. The "reset" implementation (or lack there of) reminds me of the strangeness in the ILI9341 LCD when I was implementing dual-hardware SPI on the ESP32.
I eventually had to implement _RST on both displays; even though initial testing indicated the implementation was not needed.

Code: Select all

// Software Pin Name  // GPIO: HSPI    VSPI           //  ILI9341 J2      // Notes: all HSPI pins can remap
// -------------------------------------------------- //    1 VDD 3.3V
// -------------------------------------------------- //    2 GND
#define HSP_CS                  15                    //    3 CS          <========== xSPI centric
#define VSP_CS                           5
#define HSP_RST    -1   //      27                    //    4 RST         <========== User Defined (Tie to VDD)
#define VSP_RST    -1   //              25
#define HSP_DC                  26                    //    5 D/C         <========== User Defined
#define VSP_DC                          16
#define HSP_MOSI                13                    //    6 SDI-MOSI    <========== xSPI centric
#define VSP_MOSI                        23      
#define HSP_SCLK                14                    //    7 SCK         <========== xSPI centric
#define VSP_SCLK                        18
// -------------------------------------------------- //    8 LED                     !!! 3.3V NOT 5V !!!
#define HSP_MISO    -1   //     12                    //    9 SDO-MISO    <========== xSPI centric (Not used ILI9341)
#define VSP_MISO    -1   //             19

// VSPI (default under Arduino)
SPIClass  SPI1(VSPI);
// Use ESP32 hardware VSPI and above defines
//Adafruit_ILI9341 tft0=Adafruit_ILI9341(VSP_CS,VSP_DC,VSP_RST);
Adafruit_ILI9341 tft0=Adafruit_ILI9341(&SPI1, VSP_DC, VSP_CS, VSP_RST);

// HSPI 
SPIClass  SPI2(HSPI);
// static const int spiClk = 1000000;           // 1 MHz ... default is 40MHz
// Use ESP32 hardware HSPI and above defines
Adafruit_ILI9341 tft1=Adafruit_ILI9341(&SPI2, HSP_DC, HSP_CS, HSP_RST);


void setup(void) 
{
  pinMode(VSP_CS, OUTPUT); //VSPI SS (may not be required for 'default')
  pinMode(HSP_CS, OUTPUT); //HSPI SS
  Serial.begin(115200);
  Serial.println(progname); 
  Serial.println(xxxx);
  tft0.begin();
  tft1.begin();