[BUG] Display and Touchscreen Refresh issues with latest bugfix

[rq3]

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

Yes, and the problem still exists, even with the latest bugfix 2.1x code.

Bug Description

Compiled and installed latest (5/27/2022) bugfix with associated configuration files. There is a massive refresh issue on the display, and it can take up to 5 seconds to respond to touchscreen inputs.

EDIT: this issue still applies to Release 2.1, Release 2.0.9.4, and bugfix 2.1x as of June 6, 2022.

Bug Timeline

New today

Expected behavior

I expect the display and touchscreen to work

Actual behavior

Massive (many seconds) refresh issue with display and touch inputs.

Steps to Reproduce

1. compile and install latest bugfix

Version of Marlin Firmware

latest bugfix and configurations

Printer model

AnyCubic Predator

Electronics

Trigorilla Pro (STM32F103ZE)

Add-ons

none

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

2.1x_Configurations.zip

Regressing to bugfix from 5/22/2022 works fine.

[ellensp]

Electronics "stock" is not a clear answer..

To save someone else also having to search for this information

From example configs https://github.com/MarlinFirmware/Configurations/blob/bugfix-2.0.x/config/examples/delta/Anycubic/Predator/Configuration.h

#define MOTHERBOARD BOARD_TRIGORILLA_PRO
#define ANYCUBIC_TFT35
#define TFT_CLASSIC_UI

[rq3]

Electronics "stock" is not a clear answer..

To save someone else also having to search for this information

From example configs https://github.com/MarlinFirmware/Configurations/blob/bugfix-2.0.x/config/examples/delta/Anycubic/Predator/Configuration.h

#define MOTHERBOARD BOARD_TRIGORILLA_PRO #define ANYCUBIC_TFT35 #define TFT_CLASSIC_UI

Then the issue template should be changed. It says:
Electronics
Stock electronics, upgrade board, or something else?

The answer of "stock" seems to fulfill the requirement. One would expect that a new bugfix, with the latest "pretested" configuration would actually work on a stock machine.

[thisiskeithb]

Then the issue template should be changed.

The issue template asks you to attach a zip file containing your configs which you failed to do. We have no idea what your definition of “stock” is or what you changed from a default config.

[rondlh]

This could be related to this bug: #24241
This causes errors in the reporting, causing TFTs to not be able to read the settings correctly...

[thisiskeithb]

This could be related to this bug: #24241 This causes errors in the reporting, causing TFTs to not be able to read the settings correctly...

They aren't related since the TFT in the config is an FSMC TFT (not a standalone running separate firmware).

[rq3]

Then the issue template should be changed.

The issue template asks you to attach a zip file containing your configs which you failed to do. We have no idea what your definition of “stock” is or what you changed from a default config.

I clearly stated that I used the latest bugfix AND its associated configuration files. I changed nothing, other than the platformio.ini environment required for compilation. So, if a zip file were included by me, it would just be parroting what I had just downloaded from GitHub.

[Roxy-3D]

I clearly stated that I .....

rq3.... Please keep a humble tone when getting free help from the experts.

[rq3]

Then the issue template should be changed.

The issue template asks you to attach a zip file containing your configs which you failed to do. We have no idea what your definition of “stock” is or what you changed from a default config.

@thisiskeithb, configs attached. Please note that these are completely unchanged, and are as downloaded from the nightly build configurations on GitHub. They were directly pasted from the unzipped /config/examples/delta/anycubic/predator folder with no changes whatsoever.

I have done a WinMerge file compare between these configurations and my older ones, and can see nothing that would lead to the behavior I am seeing, so can only conclude that there is a problem in the later bugfixes themselves. Perhaps related to the new changes in ui_480x320.cpp and its associated files?

With these configurations, bugfixes starting on May 28 compile just fine, but when the resulting fimware.bin is loaded onto the printer, the display acts like a slow-scan TV screen, and touch inputs take many seconds (3-5) to react. This is true for both ClassicUI, and ColorUI.

The bugfix from May 22 works fine, and is currently loaded and running on the machine, with ColorUI.

All of the release dates that I reference are from the comments in version.h

Configs.zip

[rondlh]

So you say there are configuration differences, why not send the files that are actually in use and leave the judgement to the experts?

[rq3]

So you say there are configuration differences, why not send the files that are actually in use and leave the judgement to the experts?

The point is that bugfix after May 28 won't run EVEN with the completely untouched, as published, supplied example configuration files. It will compile, and the resulting firmware.bin loads onto the machine just fine, but the display and touch screen are unuseable.

I would think that the latest bugfix would run with the latest, virgin, untouched, unedited, as supplied example configuration files. It doesn't. I am merely reporting that fact.

The experts are perfectly welcome to compile the latest bugfix with the latest configuration files, as they currently exist on GitHub, load the resulting fimware.bin onto a brand new AnyCubic Predator, and see the resulting failure.

I can only act as a willing guinea pig for the results of any Marlin changes, as I actually have access to the machine and am willing to compile firmware and flash it until the cows come home. As many folks here may know.

[Roxy-3D]

@rq3 Do you know what change broke things for your printer? If it is just a couple of lines of code that cause the problem can you post them here? (Both the before and after would be helpful. If it makes sense I'll revert the changes for you.)

[rq3]

@rq3 Do you know what change broke things for your printer? If it is just a couple of lines of code that cause the problem can you post them here? (Both the before and after would be helpful. If it makes sense I'll revert the changes for you.)

@Roxy-3D, that's very generous, but I haven't a clue. All that I know is that somewhere between bugfix May22 and bugfix May 28 something changed. Just out of curiosity, I've done a few file compares on things like ui_480x320.cpp, and can see that there have been some substantial (?) changes, but I am nowhere near knowledgable enough to do anthing with that information.
Or even if that information is applicable.

For what it's worth, when the machine boots the 480x320 graphical LCD acts like a slow scan TV, taking many seconds to laboriously refresh the display, line by line, from the top down. After that, if I press a touch button, it takes 3 to 5 seconds for the machine to respond to the touch, and if the button press was requesting a screen change, it goes through the whole slow line-by-line routine again.

I did see that there was a recent merge (I think) having to do with serial activity, and I did manually revert those changes, but that had no effect at all.

Just to be clear on my approach, when I try a new bugfix, I download the bugfix and the latest configs. I then compile, and if successful, load the resulting firmware.bin.
If that is also successful, I do a numbered back-up of each firmware.bin from the machine itself after I have determined that the change hasn't been detrimental, add any needed config changes, even one by one if appropriate, recompile, and rinse and repeat.

That way I know what changes tripped me up, if any. Usually things go pretty smoothly. But this time I didn't get past the first boot with the new firmware.bin. And I know it's not a config issue, or at least not one that I introduced, because the config files used were completely unedited from the latest config/examples for the machine.

Hope this helps, and many thanks for the offer!

[rq3]

Latest bugfix 2.1, Release 2.0.9.4, and Release 2.1 all repeat after booting:
15:42:03.179 : echo:No SD card