[BUG] TFT_COLOR_UI display lockup (in calibration)

[sk8board]

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

Yes, and the problem still exists.

Bug Description

After turning on the main power switch of the printer, the display will show "booting", then a Marlin logo, then sometimes the display requires calibration.

Many times when display calibration is performed, the display freezes with two "+" signs in opposite corners with the words showing "top left".

Cycling the power switch on the printer starts the whole process again. Sometimes I can get past the display calibration screen other times the display freezes again.

This problem occurs 50% of the time.

TFT_COLOR_UI is used

Bug Timeline

2.0.9.3 December 30, 2021

Expected behavior

For the display to function after calibration is complete.

Actual behavior

Many times when display calibration is performed, the display freezes with two "+" signs in opposite corners with the words showing "top left".

Cycling the power switch on the printer starts the whole process again. Sometimes I can get past the display calibration screen other times the display freezes again.

This problem occurs 50% of the time.

Steps to Reproduce

1. Turn on the printer
2. Sometimes the printer requires the display to be calibrated upon startup
3. Perform display calibration by pressing the corners of the display when prompted
4. After pressing the fourth corner of the display, the display will lock up and not function until the power switch is cycled.

Config.zip

Version of Marlin Firmware

2.0.9.3

Printer model

Two Trees Sapphire Plus

Electronics

Stock MKS Robin Nano V1.2 (mks_robin_nano35)

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

OctoPrint

Additional information & file uploads

TFT_COLOR_UI is used in configuration.h

[just-trey]

+1 with MKS Robin Nano V1.2 (mks_robin_nano35) and BOARD_MKS_ROBIN_NANO_V1_3_F4

@sk8board just FYI.I can as confirm with a power cycle it asks to calibrate again and always seems to work.

[Camillo0000]

Does anyone have a solution, I have the same problem?

[just-trey]

@Camillo0000 just a power cycle on the machine once or twice until it works. Does it not let you get past that?

[thinkyhead]

Please define/enable DEBUG_TOUCH_CALIBRATION and connect to the serial console before testing calibration. This will produce some extra output during the process which could be helpful.

[sk8board]

@thinkyhead I cannot find DEBUG_TOUCH_CALIBRATION in Configuration.h or Configuration_Adv.h. Where do I define DEBUG_TOUCH_CALIBRATION?

Also, what is a serial console and how do I connect to it? I have searched google without finding what you mean.

Do you mean to use Octoprint Serial Connection then enable Serial Logging?

[sk8board]

I have added #define DEBUG_TOUCH_CALIBRATION to Configuration.h and the software compiled without error. Therefore, I believe I correctly answered my first question in the previous post.

I then monitored Octoprint Terminal. Below is what I discovered.

First, I notice the problem with the display locking up occurs after sending M502. Every time I send M502, the display immediately locks up. If I do not send M502 before powering off the printer, then the printer will start without the display entering calibration mode.

Here are the test results:

Trial 1

Power on the printer, then display calibration is automatically started

Recv: TouchCalibration - State: 0, x: 30, raw_x: 1776, y: 30, raw_y: 311
[...]
Recv: TouchCalibration - State: 1, x: 30, raw_x: 1828, y: 289, raw_y: 1757
[...]
Recv: TouchCalibration - State: 2, x: 449, raw_x: 211, y: 30, raw_y: 365
[...]
Recv: TouchCalibration - State: 3, x: 449, raw_x: 192, y: 289, raw_y: 1775
Recv: Touch screen calibration completed
Recv: TOUCH_CALIBRATION_X -17156
Recv: TOUCH_CALIBRATION_Y 11886
Recv: TOUCH_OFFSET_X 502
Recv: TOUCH_OFFSET_Y -31
Recv: TOUCH_ORIENTATION TOUCH_LANDSCAPE
Recv: echo:Settings Stored (635 bytes; crc 7770)
Recv: //action:notification Settings Stored

Result: Display calibration completed with the display showing the main menu and the display functioning as expected

Trial 2

Power on the printer, the display shows main menu and the display functions as expected.

I noticed M502 will cause the display to lock up. To get the display to function again, I sent M995 which started display calibration.

Send: M502
Recv: echo:Hardcoded Default Settings Loaded
Recv: ok P31 B31
[...]
Send: M500
[...]
Recv: echo:Settings Stored (635 bytes; crc 1606)
Recv: //action:notification Settings Stored
Recv: ok P31 B31
[...]
Send: M995
Recv: ok P31 B31
[...]
Recv: TouchCalibration - State: 0, x: 30, raw_x: 1803, y: 30, raw_y: 304
[...]
Recv: TouchCalibration - State: 1, x: 30, raw_x: 1863, y: 289, raw_y: 1759
[...]
Recv: TouchCalibration - State: 2, x: 449, raw_x: 236, y: 30, raw_y: 226
[...]
Recv: TouchCalibration - State: 3, x: 449, raw_x: 285, y: 289, raw_y: 1756
[...]

Result: The display is locked up after sending M502. Sending M995 started display calibration, but calibration ended with the display showing two "+" signs in opposite corners with the words "Top Left".

Sending M995 again did not affect the display. The display remained locked up.

Trial 3

Power on the printer, then display calibration is automatically started

Recv: TouchCalibration - State: 0, x: 30, raw_x: 1811, y: 30, raw_y: 262
[...]
Recv: TouchCalibration - State: 1, x: 30, raw_x: 1850, y: 289, raw_y: 1690
[...]
Recv: TouchCalibration - State: 2, x: 449, raw_x: 226, y: 30, raw_y: 274
[...]
Recv: TouchCalibration - State: 3, x: 449, raw_x: 213, y: 289, raw_y: 1750
Recv: Touch screen calibration completed
Recv: TOUCH_CALIBRATION_X -17045
Recv: TOUCH_CALIBRATION_Y 11689
Recv: TOUCH_OFFSET_X 507
Recv: TOUCH_OFFSET_Y -17
Recv: TOUCH_ORIENTATION TOUCH_LANDSCAPE
Recv: echo:Settings Stored (635 bytes; crc 61759)
Recv: //action:notification Settings Stored

Result: Display calibration completed with the display functioning as expected

[thinkyhead]

Maybe the issue is related to a funky EEPROM. Try defining/enabling DEBUG_EEPROM_READWRITE and re-testing touch calibration and EEPROM commands to see if any of the stored fields are shifted to unexpected offsets. Then see if disabling TOUCH_SCREEN_CALIBRATION causes some change — after you've modified your Configuration with the calibrated values, of course.

[sk8board]

I have added #define DEBUG_EEPROM_READWRITE to Configuration.h and retested.

The result was the same. Octoprint Terminal did not show anything different compared to what I have provided in my previous post. Even when the display would lockup at the end of display calibration or when sending M502 or M500, the results were the same.

The next step shows how to prevent the display from locking-up.

In my previous post I mentioned that sending M502 would cause the display to lockup instantly. Eventually, this made sense to me since the Configuration.h did not have default settings for the display. When loading default settings, M502, the display did not have enough information to function.

After adding #define DEBUG_TOUCH_CALIBRATION to Configuration.h, I noticed after a successful display calibration, OctoPrint Terminal would show display calibration settings that I needed to add to Configuration.h

Recv: Touch screen calibration completed
Recv: TOUCH_CALIBRATION_X -17045
Recv: TOUCH_CALIBRATION_Y 11689
Recv: TOUCH_OFFSET_X 507
Recv: TOUCH_OFFSET_Y -17
Recv: TOUCH_ORIENTATION TOUCH_LANDSCAPE
Recv: echo:Settings Stored (635 bytes; crc 61759)
Recv: //action:notification Settings Stored

Therefore, I changed Configuration.h to the following:

enable TOUCH_CALIBRATION_X, TOUCH_CALIBRATION_Y, TOUCH_OFFSET_X, TOUCH_OFFSET_Y, and TOUCH_ORIENTATION TOUCH_LANDSCAPE.

I used the values shown above from OctoPrint terminal to define the display calibration values as shown below.

#if ENABLED(TOUCH_SCREEN)
  #define BUTTON_DELAY_EDIT  50 // (ms) Button repeat delay for edit screens
  #define BUTTON_DELAY_MENU 250 // (ms) Button repeat delay for menus

  //#define TOUCH_IDLE_SLEEP 300 // (secs) Turn off the TFT backlight if set (5mn)

  #define TOUCH_SCREEN_CALIBRATION

  #define TOUCH_CALIBRATION_X -17045
  #define TOUCH_CALIBRATION_Y 11689
  #define TOUCH_OFFSET_X        507
  #define TOUCH_OFFSET_Y        -17
  #define TOUCH_ORIENTATION TOUCH_LANDSCAPE

  #if BOTH(TOUCH_SCREEN_CALIBRATION, EEPROM_SETTINGS)
    #define TOUCH_CALIBRATION_AUTO_SAVE // Auto save successful calibration values to EEPROM
  #endif

  #if ENABLED(TFT_COLOR_UI)
    //#define SINGLE_TOUCH_NAVIGATION
  #endif
#endif

These changes to Configuration.h have stopped the display from locking up. When performing a display calibration, sometimes the calibration would end by showing "Calibration Failed", but the display would then show the main menu and function as expected.

I still do not know why display calibration fails about 50% of the time. Display calibration failure seems to be a bug. Therefore, this information should be considered a workaround.

A further workaround was to disable TOUCH_SCREEN_CALIBRATION. Now I never see the display calibration screen.

If you have previously added #define DEBUG_EEPROM_READWRITE or #define DEBUG_TOUCH_CALIBRATION to Configuration.h, then be sure to disable these before your final build. Leaving these enabled will cause the display to have a delayed response to touch.

[jmz52]

@sk8board
There is a verification procedure that checks raw data deviation between points of the same value to ensure that they are precise enough. Default TOUCH_SCREEN_CALIBRATION_PRECISION value is 80, meaning that if data deviation is greater that 20% the calibration will fail.

In your particular case the raw data were

Recv: TouchCalibration - State: 0, x: 30, raw_x: 1803, y: 30, raw_y: 304
Recv: TouchCalibration - State: 1, x: 30, raw_x: 1863, y: 289, raw_y: 1759
Recv: TouchCalibration - State: 2, x: 449, raw_x: 236, y: 30, raw_y: 226
Recv: TouchCalibration - State: 3, x: 449, raw_x: 285, y: 289, raw_y: 1756

raw_y values for state 0 (Top Left) and 2 (Top Right) are 304 and 226.
Calculated precision is 100* 226 / 304 = 74, which is less than 80, so calibration has failed.
Current implementation tries to restart calibration process, but for some reasons it stuck instead.

I need some time to catch up with current state of tft and touch code to find out where exact problem in the code is.

Until than I can offer you two workarounds:

• (recommended) Use stylus for touch screen calibration to improve precision
• Define TOUCH_SCREEN_CALIBRATION_PRECISION in your configuration file with some value lower than default 80

[sk8board]

@jmz52
Thank you for explaining what causes the calibration to fail. Do you expect a bug fix will be available for retry failure resulting in a locked up screen?

[sk8board]

@jmz52
Do you expect a bug fix will be available?

[sk8board]

Current implementation tries to restart calibration process, but for some reasons it stuck instead.

I need some time to catch up with current state of tft and touch code to find out where exact problem in the code is.

@thinkyhead it seems this problem has been verified. Should this be marked as a confirmed bug for a fix in a future release?

[sk8board]

Current implementation tries to restart calibration process, but for some reasons it stuck instead.

I need some time to catch up with current state of tft and touch code to find out where exact problem in the code is.

@thinkyhead it seems this problem has been verified. Should this be marked as a confirmed bug for a fix in a future release?

[sk8board]

Current implementation tries to restart calibration process, but for some reasons it stuck instead.

I need some time to catch up with current state of tft and touch code to find out where exact problem in the code is.

@thinkyhead it seems this problem has been verified. Should this be marked as a confirmed bug for a fix in a future release?

[thisiskeithb]

I believe this was fixed in:

• Touch screen calibration loop/stuck fix #25334

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions]

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.