[BUG] Garbled display after update from 2.0.7.2 to 2.0.8

[hartmannathan]

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

Yes, and the problem still exists.

Bug Description

After updating from 2.0.7.2 to 2.0.8, the display is garbled - see images. Downgrading back to 2.0.7.2 fixes the problem. Problem exists in bugfix-2.0.x branch too. Hardware: BTT GTR V1.0, REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER.

I'll be happy to bisect from 2.0.7.2 to 2.0.8 to find the commit that broke it, if someone could tell me the git incantation :-)

Working correctly with Marlin 2.0.7.2:

Garbled with Marlin 2.0.8:

Bug Timeline

Appears in 2.0.8.

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

2.0.8

Printer model

Creality CR-10

Electronics

BTT GTR V1.0 and REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

Add-ons

No response

Your Slicer

Other (explain below)

Host Software

Other (explain below)

Additional information & file uploads

Configuration.zip

[ellensp]

several things changed that effected timing, and it was found that several platforms had incorrect timings to start with. Now corrected. But it means that things like this in your Marlin/src/pins/stm32f4/pins_BTT_GTR_V1_0.h file are no longer correct.

#if HAS_MARLINUI_U8GLIB
#ifndef BOARD_ST7920_DELAY_1
#define BOARD_ST7920_DELAY_1 DELAY_NS(96)
#endif
#ifndef BOARD_ST7920_DELAY_2
#define BOARD_ST7920_DELAY_2 DELAY_NS(48)
#endif
#ifndef BOARD_ST7920_DELAY_3
#define BOARD_ST7920_DELAY_3 DELAY_NS(600)
#endif
#endif

comparing it to another stm32f4 I see

#ifndef BOARD_ST7920_DELAY_1
#define BOARD_ST7920_DELAY_1 DELAY_NS(125)
#endif
#ifndef BOARD_ST7920_DELAY_2
#define BOARD_ST7920_DELAY_2 DELAY_NS(90)
#endif
#ifndef BOARD_ST7920_DELAY_3
#define BOARD_ST7920_DELAY_3 DELAY_NS(600)
#endif

try these.

[hartmannathan]

#ifndef BOARD_ST7920_DELAY_1
#define BOARD_ST7920_DELAY_1 DELAY_NS(125)
#endif
#ifndef BOARD_ST7920_DELAY_2
#define BOARD_ST7920_DELAY_2 DELAY_NS(90)
#endif
#ifndef BOARD_ST7920_DELAY_3
#define BOARD_ST7920_DELAY_3 DELAY_NS(600)
#endif

Thanks for your reply. I will try to test today and if this fixes the issue I'll send a PR.

[hartmannathan]

With the values above, the display is much improved but still slightly garbled; in other words, It seems the values above are close but not quite correct.

What is the meaning of the three delay values?

[thisiskeithb]

Maybe we can setup some better defaults. I'm noticing this issue across most boards with a 12864 LCD.

[hartmannathan]

Maybe we can setup some better defaults. I'm noticing this issue across most boards with a 12864 LCD.

Is 7796613 the commit that changed the timings? I am trying to figure out what the old timings were and translate them to the new timings, but I might be going down the wrong rabbit hole.

[XDA-Bam]

Maybe we can setup some better defaults. I'm noticing this issue across most boards with a 12864 LCD.

Is 7796613 the commit that changed the timings? I am trying to figure out what the old timings were and translate them to the new timings, but I might be going down the wrong rabbit hole.

Yes, but you also have to take #21546 into account, which made some delays a bit longer again (#20901 should have reduced shorter delays). Another user tested the delays on his SKR pro and came up with this, which is close to what ellensp recommended.

I would recommend that you try to first increase delay 1 to 150 ns, then the others one by one by 10 to 20 ns each. Oddly enough, AVR boards run fine with totally different values (125/0/125 instead of 125/90/600). You might also try those first.

[X-Ryl669]

I agree here. If you read each device datasheet, the expected delay are not like those written in the code. The code was initially hand tuned to account for the wasted cycles in calling the functions and many other overhead. Since now the DELAY_NS is a lot more precise, this tuning does not match anymore with previous code. So you'll need to adjust the timing (we might have missed some).

If I were you, I would start with what the datasheet says and bootstrap from there. You might need to reduce the delay by very small amount (on some ARM board, the cycle step is only 6ns) to account for overhead.

[X-Ryl669]

The datasheet list 600ns for delay 3, minimum 80ns for delay 2 (+ 2x the rise & fall time, but it's not expressed in the datasheet), and, and 120ns for delay 1 (+ 2x unknown rise and fall time). You can take some margin here.

So 125/85/600 should start working, and @ellensp values are logical too, not too far. The datasheet only state the rise & fall time for the signal should be < 200ns, but it does not say how short they can be (and this depends on the electronic of your board, wire length and so on).
Ideally, if you know what and how to do it, put an oscilloscope on the lines and observe the timings, and adjust in consequence.

[hartmannathan]

@thinkyhead was this issue fixed for all boards? The above fix mentioned by @thisiskeithb is for Octopus 12864 only.

[thinkyhead]

The same solution applies to all cases where the display is garbled, and generally the defaults should be close to the values from the datasheet as described above. If some pins file is specifying delays that are a bit too short, that file may be adjusted for a future release.

[hartmannathan]

Thanks. I'll test it next time I have an opportunity.

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