potential 12864 display with Azteeq X3Pro on bugfix-1.1x

[ea69]

configuration is a custom printer based on ORD Rova3D chassis (Azteeq X3Pro controller) that someone discarded. Made a new X carriage for a single E3D V6 and a custom cable to interface a 12864 display to the controller's ICSP and EXP1/3 headers.

Have been running for months on 1.1.8 without issue. Bought an E3D chimera to do dual extrusion and started having weird bilinear bed leveling behavior. Saw that developers wanted homing/leveling problems replicated on bugfix-1.1x, so tried moving to that tree and encountered this display problem.

I have reduced this to the simplest configuration that reproduces the problem, eliminating extraneous details of my printer. The attached zip contains the modified files for 1.1.8 (display works) and bugfix-1.1x (display does not work).

pins_AZTEEG_X3_PRO.h is the same in both trees. I have no expectation this would be merged as I simply whacked the spindle/laser/VIK stuff at the end which does not pertain to me and inserted the pinout info I need.

The only changes to configuration.h in both trees is to define the board correctly:

#define MOTHERBOARD BOARD_AZTEEG_X3_PRO

and to enable the display by uncommenting:

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

The changes to ultralcd_st7920_u8glib_rrd.h are just to specify delay timing.

For 1.1.8, it is:

#define ST7920_DELAY_1 DELAY_0_NOP
#define ST7920_DELAY_2 DELAY_1_NOP
#define ST7920_DELAY_3 DELAY_2_NOP

For bugfix-1.1.x, it is:

#define ST7920_DELAY_1 DELAY_NS(0)
#define ST7920_DELAY_2 DELAY_NS(63)
#define ST7920_DELAY_3 DELAY_NS(125)

In both cases, I simply copied the delays used for REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER in pins_ANET_10.h

In 1.1.8, I get a Marlin logo on powerup, and status screen, and functioning menus. Pronterface and octoprint can connect to and recognize the printer.

In bugfix-1.1x, there is no powerup logo, status screen, etc. However, pronterface and octoprint do recognize the printer and it does show to be the bugfix tree if I execute a M503.

If I flash to bugfix-1.1x after 1.1.8. the last "page" selected while running 1.1.8 remains on the screen, so the display is not being reset or initialized. If I power cycle, the display is powered an illuminated, but remains blank.

I can flash either release and go between working and not working at will, so I do not believe I have a hardware issue.

I saw #10962 in the 2.0 branch that sounded similar, but involved the ST7565 controller, so it does not look like the fix made for that controller in the 2.0 branch would apply.

I am at a loss on next steps, other than trying to get access to a scope (difficult) and looking at the timings for ST7920_CLK_PIN, ST7920_DAT_PIN, and ST7920_CS_PIN.

Am I missing additional changes in bugfix-1.1x or something obvious?

Marlin FW files.zip

[thinkyhead]

If you can find the latest commit where the display still works, that will help to narrow down the difference that causes it to fail. Try downloading Marlin from –say– a month ago, two months ago, etc., until you find one that works.

[ea69]

definitely not a Marlin bug....

had previously wired the display using the EXP4/5 header which uses some of the same pins used for STEP/DIR on higher number extruders (same signals route to pololu/stepstick module locations).

when I moved to the chimera hot end, I also shifted my wiring over to EXP1/3 which are all unused Mega2560 pins.

My 1.1.8 directory had the correct pins_AZTEEG_X3_PRO.h and worked. But, I somehow grabbed on older version of that file (with the EXP4/5 pin definitions) when I pulled down bugfix-1.1x.

Sorry for the false alarm.

[github-actions[bot]]

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.