[BUG] E3 LCD Unreadable/uses half the screen

[dotdash32]

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

Yes, and the problem still exists.

Bug Description

Updated my fork's bugfix last night, and upon flashing the Ender 3 stock display is unreadable. It was working on an older version (commit 65cfbc0) but does not on the most recent version.

Bug Timeline

After 65cfbc0

Expected behavior

Display shows values, uses all 128 horizontal characters.

Actual behavior

Appes to only use ~75% of the screen, from boot onward. Display is unreadable as characters flash back and forth.

Steps to Reproduce

1. Update to latest bugfix
2. Flash on working hardware (display works on older versions of Marlin)
3. boot and observe LCD

Version of Marlin Firmware

latest bugfix

Printer model

Creality Ender 3

Electronics

SKR 2

Add-ons

No response

Bed Leveling

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

Configurations here

[ellensp]

The lcd seems to be missing bits... timings not quite correct for your lcd.

In Marlin/src/pins/stm32f4/pins_BTT_SKR_V2_0_common.h is

#if ENABLED(U8GLIB_ST7920)
  #ifndef BOARD_ST7920_DELAY_1
    #define BOARD_ST7920_DELAY_1   DELAY_NS(120)
  #endif
  #ifndef BOARD_ST7920_DELAY_2
    #define BOARD_ST7920_DELAY_2   DELAY_NS( 80)
  #endif
  #ifndef BOARD_ST7920_DELAY_3
    #define BOARD_ST7920_DELAY_3   DELAY_NS(580)
  #endif
#endif

add custom #define BOARD_ST7920_DELAY_1, BOARD_ST7920_DELAY_2 and BOARD_ST7920_DELAY_3 to your Configuration.h
Increase the delays

[thisiskeithb]

I'd be curious to know how different the timings are on your LCD.

The Creality single EXP CR10_STOCKDISPLAYs I have here work fine on the SKR2 using yesterday's bugfix (a3557e6).

[dotdash32]

Debugging story time:

I tried doubling, tripling, and then quadropoling the timing values (edited them directly in the pins file, oop), and that didn't make a difference. In hindsight, I think this is because these values were ignored by pins_postprocess.h.

I saw Keith mention doing a tree like search for the problem, so I started going back and checking out old commits.

• Checked out 17bf125 (July 13) which worked!
  • no change in timing there
• Checked out cc109c18 (Aug 8) which works!
  • had to copy config files, fix superficial errors
• Check out 9046524a (Aug 20) which works!
• Check out 6d3dec8b (Aug 28) which DOESN'T work
  • My gut tells me it's here, and likely in the pins_postprocess.h file.
• Check out f6dc56d9 (Aug 27) which works

So I think that means I know where the problem, just need to fix it now. I believe it's due to using LCD delays first, when in my case it needs to check for BOARD delays first. I created a PR that reflects these changes, but I don't have the infrustructure to test it on all platforms.

Old code in pins_postprocess.h

#ifndef ST7920_DELAY_1
    #ifdef LCD_ST7920_DELAY_1
      #define ST7920_DELAY_1 LCD_ST7920_DELAY_1
    #elif defined(BOARD_ST7920_DELAY_1)
      #define ST7920_DELAY_1 BOARD_ST7920_DELAY_1
    #elif defined(CPU_ST7920_DELAY_1)
      #define ST7920_DELAY_1 CPU_ST7920_DELAY_1
    #endif
#endif

I belive that this logic flow (which is reflected for ST7920_DELAY_2 and ST7920_DELAY_3) will always use the LCD defined timing before looking for the others. However, it seems that BOARD and CPU timings are designed to overwrite those on an as-needed basis, but they are not because the LCD timing is defined per display and don't handle the exceptions.

Ideally, I think it should default to longest delay between LCD, BOARD, and CPU, but unsure if that's necessary. Also, unsure if there is an easy way to do comparisons between DELAY_NS() funciton calls. From what I've seen, there are only a few CPU delays, so is it easier to move those into board definitions?

[thisiskeithb]

Resolved in #22713

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