[BUG] No Bootscreen display on Hornet

[newbeetle]

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

Yes, and the problem still exists.

Bug Description

When compiling firmware for Artillery Hornet with the bootscren file, the screen does not display the Artillery logo but stays blank during the display time.

Bug Timeline

No response

Expected behavior

Expect display Artillery logo

Actual behavior

Blank screen during bootscreen time

Steps to Reproduce

No response

Version of Marlin Firmware

2.0.9.3

Printer model

Artillery Hornet

Electronics

Stock Artillery Ruby

Add-ons

No response

Bed Leveling

MBL Manual Bed Leveling

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Hornet.zip

[ellensp]

Graphics data works on a ramps with a REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER, so that is ok... I can't test on actual hardware

[newbeetle]

Last test with unmodified files from https://github.com/MarlinFirmware/Configurations and same thing. I will try another _Bootscreen file later. I disabled it in my last firmware.

[HeinzN]

Graphics data works on a another controller/screen, so that is ok... I can't test on actual hardware

While this (the 'another controller/screen') is true for most Stock Artillery printers (e.g., Sidewinder or Genius), this is not true for the Hornet, which uses an 'ordinary' 12864 display.

I am seeing the same symptom on my Sidewinder that I modified to use a FYSETC 12864mini display: no 'vendor' Bootlogo since 2.0.9.2 - and this was working fine on older versions up to and including Marlin 2.0.9.1.
Interestingly, I see another (maybe related?) symptom: also the Marlin logo animation does not work anymore, since 2.0.9.2 after a short black screen it just shows the "unanimated" small Marlin logo during bootup. (also here, on versions up to 2.0.9.1, it was working fine).

[HeinzN]

Graphics data works on a another controller/screen, so that is ok... I can't test on actual hardware

While this (the 'another controller/screen') is true for most Stock Artillery printers (e.g., Sidewinder or Genius), this is not true for the Hornet, which uses an 'ordinary' 12864 display.

Just noticed that I maybe got you wrong, @ellensp. I was under the impression you were refering to the 'external' touchscreen display used on most Stock Artillery printers... which of course is not showing the (Marlin) Bootlogos. But after reading your comment again, I now believe you were just stating that you do see the logo on other Printers.
Nevertheless, everything else that I wrote still holds true.

[thinkyhead]

Would you be able to test some bugfix-2.0.x commits to narrow this down?

The strategy is to find a commit from some point in the "distant" past where the feature works. Then, test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact day where it broke.

If you started from a point 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

[newbeetle]

I can do the tests.

[newbeetle]

How can I test as Artillery Ruby board was only implemented on version 2.0.9.3 ?

[HeinzN]

Would you be able to test some bugfix-2.0.x commits to narrow this down?

Of course I would be willing to do some testing (especially as your approach sounds pretty systematic :-) ).

Unfortunately, I'm a complete newbie to all of that git-stuff, so I currently have no idea how to easily

• fetch the sources up to a certain commit
• identify a point e.g. "256 commits in the past"

If somebody could give me some simple instructions (or guide me to a good 'how to' for this), I would be more than happy to support!

[newbeetle]

Maybe as you said it worked with 2.0.9.1 you can start at https://github.com/MarlinFirmware/Marlin/tree/a185ce22cf6e4fb15250815c5c39318606a7e65a Marlin 2.09.2 and go in the past to find the default.

You press the number with the arrow and you can go older with arrows in the bottom of the page.

[HeinzN]

I could identify the culprit!

Up to and including e705a7724eace3970a1792933e1f614d07cc2667 everything is fine, with 89898181bd2e92b420228021c12308fdb4314221 the Bootlogo (including the Marlin animation) is not shown any more.

I hope this will help @thinkyhead to find the root cause for our 'problem', and thanks for your quick support, @newbeetle!

[thinkyhead]

Thanks for tracking the problem to a particular set of changes, @HeinzN. It's interesting if that commit is the true cause, as it only deals with display brightness and contrast. The default contrast for your display is 255. Maybe it was saved to EEPROM incorrectly. Do you see any difference if you use M502 followed by M500 and then a reboot?

[HeinzN]

No, that doesn't change anything. Before that commit everything fine, with that commit: no Bootlogo.
Screen stays completely black for a short period (feels like around the same time it would take to display the bootlogo and do the Marlin animation), before the final unanimated Marlin logo is displayed.
I also looked from different angles, but there is not the slightest sign of the bootlogo showing up, screen is completely black (except I can notice the background light seems to be on).

[HeinzN]

Just in case this might help, please find my config files attached:
HeinzN_Marlin_config.zip

As said, my Sidewinder is modified to use a FYSETC mini 12864 v2.1, which I mounted "upside down" (so knob on the left).

[thinkyhead]

🤷🏻 I see nothing in that specific commit that could affect boot screens. Maybe that's not actually the one.

The linked commit was from Oct 2, 2021, whereas the Artillery Ruby board was only added on Nov 1, 2021.

[thinkyhead]

I'm looking at the LCD_RESET_PIN as a possible culprit, to see if it is set early enough, before the boot screen is displayed, or some time later, and if this could make a difference. The pins file says it ought to be HIGH (or 'open', whatever that means) for the LCD to "operate normally." So, you might try adding somewhere early in the setup() function in MarlinCore.cpp …

OUT_WRITE(LCD_RESET_PIN, HIGH);

[HeinzN]

I did some tests (trying 3 different "early" points in the setup() function), unfortunately this doesn't seem to have any effect.

But after carefully doublechecking again, I believe I might have to correct myself w.r.t. my statement "not the slightest sign". If I look downwards (which would be upwards, if the display would be mounted with "normal" orientation) from an extreme angle, I imagine seeing a slight shadow that looks like the Logo - so it might in fact have something to do with contrast settings...!
BTW: it seems for my display the default contrast value is 220. I also tested to change that to 255, but this had no effect.

@newbeetle: maybe can you also try that and look from very extreme angles onto the screen during start-up to see if you can confirm my finding?

PS: please note that the Sidewinder X1 does not use the Ruby board, but an MKS GEN L.

[thinkyhead]

a slight shadow that looks like the Logo

Sounds like the contrast may not be getting set until after the boot screen has completed. I'll have to look at the setup procedure more closely.

[descipher]

Please try #23567

[HeinzN]

Yes, this seems to be the right path. Looks to me like during vendor bootlogo and the animation part of the Marlin logo, the LCD contrast is set to the "MIN" value, while as the "INIT" value is only used at the end of the boot screen.

At least for my screen, the MIN at 120 is not enough for the logo to be clearly visible (except for looking from extreme angles), but after testing with a MIN of 180 I can confirm this is moving into the right direction. Thanks, @descipher!

I am just wondering now whether not also the bootscreen should already use the INIT value instead of "MIN"? (as it was in the past before the a.m. commit)

[descipher]

They should use the same value, was not aware it's doing multiple values. Looks like the boot screen is using the unset NVRAM 255 value and not the LCD_CONTRAST_INIT 220 value.

[descipher]

Updated the PR, this was more involved that just the Min/Max. It needed to handle an absence of EEPROM_SETTINGS and a flag to know when a ui set contrast was done.
It will now load the preferred value or a previously set EEPROM value.

[thinkyhead]

needed to handle an absence of EEPROM_SETTINGS

When there is no EEPROM to load, the settings.reset() method is called instead, so contrast should get set to the default there, and then settings.postprocess() should send it on to the LCD. This will also ensure that the right thing occurs when settings.reset() is called by M502 later.

The main thing is to make sure that the display is in a good state when the EEPROM is first loaded so that settings.postprocess() will send the contrast to the display.

a flag to know when a ui set contrast was done

If we ensure that contrast variable inits as zero (the norm), and that the minimum contrast is always >= 1, then we can use a non-zero contrast value as the indicator that the contrast has been set and save a byte of SRAM.

[HeinzN]

I can confirm now that with the latest version of #23567 everything works as expected here on my Sidewinder - Bootlogo (and animation) visible again, and also respecting the EEPROM contrast settings perfectly.
Thanks @descipher and @thinkyhead!

[thisiskeithb]

#23567 has been merged.

[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.