search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.18k stars 19.21k forks source link

[BUG] MKS TS35 white screen after firmware update #22003

Closed delaosa closed 3 years ago

delaosa commented 3 years ago

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

After updating firmware successfully, screen turns to white and remains there. Using TFT_COLOR_UI or TFT_LVGL_UI makes no difference.

Workaround:

If TFT_DRIVER is set to ST7796, screen works as expected.

Bug Timeline

No response

Expected behavior

Screen shows selected UI.

Actual behavior

Screen shows a white screen.

Steps to Reproduce

  1. Compile.
  2. Flash
  3. Boot

Version of Marlin Firmware

2.0.8.2

Printer model

FLSUN Q5

Electronics

MKS Nano Robin V3 with TS35 TFT

Add-ons

No response

Your Slicer

Slic3r

Host Software

OctoPrint

Additional information & file uploads

Relevant configuration:

Configuration.h:

define TFT_COLOR_UI

define MKS_TS35_V2_0

rhapsodyv commented 3 years ago

I have a nano v3 and a mks ts35, and I flash it almost every day and it works fine.

If it need you to specify ST7796, that means that it is failing to talk with the display at early boot, so that can be related with your cables too.

But I could not reproduce it.

delaosa commented 3 years ago

Any idea what cable/pin check to be sure it's a cable thing?

rhapsodyv commented 3 years ago

Marlin talks with the TFT using SPI. We do two operations:

1) Read TFT identifier, so marlin can init it 2) Send data to draw in the TFT screen

Drawing (2) happens at very fast speed with not issues.

But to read the TFT identifier (1), we need to run in a very low SPI speed, because this operation is slow in the TFT side. Any bit loss in this process, will lead to marlin reading the wrong ID or even don't reading it at all... That would explain why you need to manually specify ST7796 - because marlin is failing to read it.

Check for the two cables that connect the TFT with the board. Maybe they are folded/bend, etc.

If it not solve, maybe you have some hardware conflict. For that, we need to know exactly what is connected to the board and what are your configs. For example: you could be using some SPI peripheral that is messing up with the TFT SPI...

delaosa commented 3 years ago

I've checked the cables and apparently they are fine. is it possible to reduce even more the speed to read that ID?

I have nothing connected to the board besides steppers using UART.

I've noticed in MKS repository there is a wiki page about this issue, apparently it's a common issue, perhaps an issue with newer batches.

https://github.com/makerbase-mks/MKS-Robin-Nano-V3.X/wiki/TS35_white_screen_problem

Additionally in MKS repository they explicitly set TFT_DRIVER in Marlin/src/pins/stm32f4/pins_MKS_ROBIN_NANO_V3.h.

rhapsodyv commented 3 years ago

Try commenting this line: https://github.com/MarlinFirmware/Marlin/blob/52ae3e6967bb6e3105d31772a58f820ca71477a9/Marlin/src/pins/stm32f4/pins_MKS_ROBIN_NANO_V3.h#L320

Maybe some new nano or tft revision are a bit different.

rhapsodyv commented 3 years ago

If the above not fix it, try changing this line: https://github.com/MarlinFirmware/Marlin/blob/fd270ddc6c5b4d78437d590ae8066326850555d7/Marlin/src/HAL/STM32/tft/tft_spi.cpp#L143 To:

SPIx.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_32;
delaosa commented 3 years ago

I tried both changes with same results, tft shows a white screen after updating.

Considering some TS35 screens have this issue, perhaps would be useful to include the TFT_DRIVER in:

Marlin/src/inc/Conditionals_LCD.h:

Original:

#if ENABLED(MKS_TS35_V2_0)          // Most common: ST7796
  #define TFT_DEFAULT_ORIENTATION (TFT_EXCHANGE_XY)
  #define TFT_RES_480x320
  #define TFT_INTERFACE_SPI

Changed:

#if ENABLED(MKS_TS35_V2_0)          // Most common: ST7796
  #define TFT_DRIVER ST7796
  #define TFT_DEFAULT_ORIENTATION (TFT_EXCHANGE_XY)
  #define TFT_RES_480x320
  #define TFT_INTERFACE_SPI
rhapsodyv commented 3 years ago

The problem with this change is: are all MKS TS35 guaranteed to be ST7796?

That advantage of the auto is that.

rhapsodyv commented 3 years ago

It seems they are using a different driver, but compatible with ST7796. I will create a branch that add some debug info for you test, so we can discover what marlin is reading from the TFT.

ellensp commented 3 years ago

I can reproduce this issue on my new mks ts35 v2.0

delaosa commented 3 years ago

It seems they are using a different driver, but compatible with ST7796. I will create a branch that add some debug info for you test, so we can discover what marlin is reading from the TFT.

ok, let's do some debugging.

ellensp commented 3 years ago

I was working with rhapsodyv till he had to go.
TFT_SPI::GetID first calls ReadID(LCD_READ_ID), this returns 0x1FFFFFF Since this is a fail it then tries ReadID(LCD_READ_ID4), but that also returns 0x1FFFFFF So no valid ID is read from the LCD

delaosa commented 3 years ago

I was working with rhapsodyv till he had to go. TFT_SPI::GetID first calls ReadID(LCD_READ_ID), this returns 0x1FFFFFF Since this is a fail it then tries ReadID(LCD_READ_ID4), but that also returns 0x1FFFFFF So no valid ID is read from the LCD

it's good not know we're not alone in this, let's try to figure it out.

ellensp commented 3 years ago

Its seems that mks (or their supplier) has changed their displays, probabably for a clone chip that does not give an id... A few things where tried, reading the id slower, waiting longer after power up then reading id. No id was readable.

ellensp commented 3 years ago

This kludge to use a LCD_DEFAULT_ID when the id cannot be read works. 

diff --git a/Marlin/Configuration.h b/Marlin/Configuration.h
index 366267aa7e..b8d31809ef 100644
--- a/Marlin/Configuration.h
+++ b/Marlin/Configuration.h
@@ -2453,7 +2453,8 @@
 // 480x320, 3.5", SPI Display From MKS
 // Normally used in MKS Robin Nano V2
 //
-//#define MKS_TS35_V2_0
+#define MKS_TS35_V2_0
+#define LCD_DEFAULT_ID 30614 // 0x7798

 //
 // 320x240, 2.4", FSMC Display From MKS
diff --git a/Marlin/src/HAL/STM32/tft/tft_spi.cpp b/Marlin/src/HAL/STM32/tft/tft_spi.cpp
index 32af67d158..afd74df780 100644
--- a/Marlin/src/HAL/STM32/tft/tft_spi.cpp
+++ b/Marlin/src/HAL/STM32/tft/tft_spi.cpp
@@ -129,8 +129,13 @@ uint32_t TFT_SPI::GetID() {
   uint32_t id;
   id = ReadID(LCD_READ_ID);

-  if ((id & 0xFFFF) == 0 || (id & 0xFFFF) == 0xFFFF)
+  if ((id & 0xFFFF) == 0 || (id & 0xFFFF) == 0xFFFF) {
     id = ReadID(LCD_READ_ID4);
+    #ifdef LCD_DEFAULT_ID
+      if ((id & 0xFFFF) == 0 || (id & 0xFFFF) == 0xFFFF)
+        id = LCD_DEFAULT_ID;
+    #endif
+  }
   return id;
 }
delaosa commented 3 years ago

assuming all TS35 V2 use the same drivers perhaps it's just easier to just force the use of the driver, however @ellensp code seems more general and reusable for another TFTs with the same issue.

What I don't get is why forcing driver works even when the ID is unknown.

rhapsodyv commented 3 years ago

@ellensp instead of a user config, add it to the TFT named driver section, as TFT_DEFAULT_DRIVER: Marlin/src/inc/Conditionals_LCD.h

#if ENABLED(MKS_TS35_V2_0)          // Most common: ST7796
  #define TFT_DEFAULT_DRIVER ST779
  #define TFT_DEFAULT_ORIENTATION (TFT_EXCHANGE_XY)
  #define TFT_RES_480x320
  #define TFT_INTERFACE_SPI
#elif ENABLED(MKS_ROBIN_TFT24)      // Most common: ST7789
  #define TFT_DEFAULT_ORIENTATION (TFT_EXCHANGE_XY | TFT_INVERT_Y)
  #define TFT_RES_320x240
  #define TFT_INTERFACE_FSMC
ellensp commented 3 years ago

a no user intervention work around has been implemented

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.