D/C and RESET potentially flipped

[Electro707]

So I wasn't happy with the LCD initialization, where if I removed g_lcd.begin() the LCD didn't work even though the next line is a hard reset, so I decided to investigate further.

The closest LCD I was able to find was the following, which almost matches in look of the one used in the cube model.
https://www.buydisplay.com/download/manual/ER-TFT013-2_Datasheet.pdf

I probed around the connectors vs the datasheet, and every pin matches up...EXCEPT for D/C and RESET, which are swapped.

This would make sense as to the issue I was seeing, as the LCD wasn't getting an actual reset.

I will test it in firmware and let you know how it goes.

[Electro707]

Can confirm this is the case. While I still need both LCD initialization functions, I tested this by adding lcdHardReset() right after g_lcd.fillScreen(LCD_BLACK); g_lcd.setTextColor(LCD_WHITE, LCD_BLACK);.

When set to what the firmware previously defined the pins as, the display continued on like normal, but after the swap the LCD went to black, which is what I would expect out of a reset (it being in sleep mode after a reset)

[Times-Z]

This confirms the issue is with the pinout rather than the init sequence itself.

Next steps should be:

• fix the D/C ↔ RESET mapping in firmware
• document the discrepancy versus the datasheet / cube model to prevent future confusion
• on my side I can check if others models have the same (like the small tv one)

Nice catch — this was a subtle one to track down

[Electro707]

The thing about the init sequence that bugs me still is that both g_lcd.begin(); and lcdRunVendorInit(); must be called for the display to work. I looked at the source for g_lcd.begin(), and it sends initialization commands similar to what lcdRunVendorInit() calls, so why removing one causes a failure of the screen (especially requiring g_lcd.begin(), even after the D/C and RESET swap? I did check that g_lcd.begin() doesn't set some internal flag or creates memory inside of the TFT library.
Furthermore, g_lcd.begin() changes the SPI mode to SPI_MODE2 through _override_datamode, but then for lcdRunVendorInit() and the rest of the run-time sequences it changes to SPI_MODE0. According to the datasheet, SDA is sampled on the rising edge and the SPI polarity doesn't matter, so SPI_MODE_0 or SPI_MODE_3 should be what's application, the other modes should be shifting weird data.
On top of all of that, I see the CS is set so it's active-high, but according to the datasheet it's active-low.

I will do further investigation on the above.

[Times-Z]

I don't find (and maybe doesn't exist) the documentation for the screen.
I assume this specific case is one of the weird oem init sequence

I assume too that the screen (and the wiring) you find is not the same, the cube one is CS drivend active high for sure

[Electro707]

I did notice when CS was low the screen did not respond.

I am starting to think that the display is a slightly different driver IC than the ST7789. I did not see any strange inverters that would leave to be believe the signals are inverted

I have attached some close up images of the only identifies on this display. So far they wield nothing in terms of good searching them.

[Electro707]

Here is something interesting: with the firmware of my fork, probing with my logic analyzer, I can see that the CS line (pin 8 on the display), I get low all the time. This was with my PR #21 code, and the display worked last on it.

EDIT: Also confirmed with the develop branch that the CS line is always low

[Electro707]

Created a basic arduino sketch below that just toggles the pin low-high.
I can probe that both pin 2 and 0 on the LCD connector are toggling, but not the CS line. This is with and without the LCD physically connected

void setup() {
  // put your setup code here, to run once:
    pinMode(15, OUTPUT);
    pinMode(2, OUTPUT);
    pinMode(0, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
    digitalWrite(15, HIGH);
    digitalWrite(2, HIGH);
    digitalWrite(0, HIGH);
    delay(500);
    digitalWrite(15, LOW);
    digitalWrite(2, LOW);
    digitalWrite(0, LOW);
    delay(500);
}

[Electro707]

So here is something funny: turns out the CS line, at least in the cube model, is just shorted to GND. Not sure how I didn't catch it the first time. Must have offset my probe by 1 pin on the esp12 (gnd is right near gp15 after all)
That would make sense as to why it was working this whole time: CS no matter what state wasn't actually getting toggled on the LCD.

If you have the smallTv model can you please check continuity between the CS pin on the LCD flex and GND?

This would actually explain why this whole time in develop CS "must be high", as that IO was set to the reset line, and without it holding itself high the display would reset.

[Times-Z]

There is the screen, on left the cube, on right the smallTV

I didn't find any inscription like yours in my sample of screens

[Electro707]

Those inscriptions were found on the display on the left (I have the same one) on the blue die area, just really zoomed in.

[Times-Z]

I was able to see this on the right, nothing on the left :

I assume I don't have any device capable of that zomm level :D

[Times-Z]

There is full res picture of the small TV screen that I can produce with my devices :