Update marlinui_DOGM.cpp to fix pin 0 configuration.

[kgy2002]

Description

Reset pin_list[U8G_PI_A0_STATE] to init state to prevent changing pin 0 pinMode.

There is a bug in u8glib on Arduino that's setting this pin (U8G_PI_A0_STATE) to 0 following initialization through the use of u8g_SetAddress() and using this pin to update the pin direction on subsequent initializations.
The U8G_CLASS constructor provides the first initialization which doesn't change the pin direction (U8G_PI_A0_STATE = U8G_PIN_NONE) but does change the U8G_PI_A0_STATE value to 0 immediately following the init.
Upon first call to u8g.firstPage(), a second initialization is called with the pin value changed to 0 which will override the pin 0 configuration.
Rewriting the pin value to U8G_PIN_NONE prior to u8g.firstPage() prevents changing of the pin config.

Requirements

Presumably any board that uses pin 0 as any pin config except OUTPUT plus any DOGM LCD.

Benefits

Pin 0 function will not be overridden using a DOGM LCD.

Configurations

config.zip

Related Issues

#21277

[thinkyhead]

Could this change be made in the U8glib-HAL instead? It seems like a pretty low-level and "privileged" information to include in basic bitmap drawing code.

[kgy2002]

PR made on U8glib-HAL. Fix is done differently but achieves the same result. Limited to SW SPI init in the new PR.

[thinkyhead]

I see some other files we might want to check…? There are a bunch of custom U8G implementations in the Marlin HALs — mostly files starting with u8g_com_.... These files also make reference to u8g->pin_list[U8G_PI_A0_STATE].

Anyway, thanks! I will look more closely at your u8glib changes later this afternoon.

[kgy2002]

Right, per the discussion in the issue, u8g->pin_list[U8G_PI_A0_STATE] gets written to by u8g_Begin and all over the init process by u8g_SetAddress so I'm not sure if the u8g_com files can be modified.

void u8g_SetAddress(u8g_t *u8g, u8g_dev_t *dev, uint8_t address)
{
  dev->com_fn(u8g, U8G_COM_MSG_ADDRESS, address, NULL);
}

    case U8G_COM_MSG_ADDRESS:                     /* define cmd (arg_val = 0) or data mode (arg_val = 1) */
      u8g->pin_list[U8G_PI_A0_STATE] = arg_val;
      break;

[thinkyhead]

I tweaked the PR on u8glib-HAL to check for ARDUINO — which seems like the right thing by those comments. If it looks good to you I will merge the fix after your review. Thanks again!

[rhapsodyv]

We are having similar issue with SMT32....

The issue is: Marlin keeps a global uglib instance, that makes it init in the __libc_init_array, before any system initialisation... and uglib try to do hardware things on init... this is messing up everything...

(gdb) bt
#0  WWDG_IRQHandler () at /Users/keith/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/startup_stm32f103xe.s:114
#1  <signal handler called>
#2  pinMode (ulPin=ulPin@entry=23, ulMode=ulMode@entry=1) at /Users/keith/.platformio/packages/framework-arduinoststm32/cores/arduino/wiring_digital.c:31
#3  0x08013b10 in u8g_dev_rrd_st7920_128x64_fn (u8g=0x200009e4 <u8g+8>, dev=0x2000006c <u8g_dev_st7920_128x64_rrd_sw_spi>, msg=<optimized out>, arg=0x0) at Marlin/src/lcd/dogm/ultralcd_st7920_u8glib_rrd_AVR.cpp:123
#4  0x0802240a in u8g_InitLL (u8g=u8g@entry=0x200009e4 <u8g+8>, dev=0x2000006c <u8g_dev_st7920_128x64_rrd_sw_spi>) at .pio/libdeps/STM32F103RC_btt_stm32/U8glib-HAL/src/clib/u8g_ll_api.c:53
#5  0x080224fc in u8g_Begin (u8g=u8g@entry=0x200009e4 <u8g+8>) at .pio/libdeps/STM32F103RC_btt_stm32/U8glib-HAL/src/clib/u8g_ll_api.c:191
#6  0x08022544 in u8g_InitSPI (u8g=u8g@entry=0x200009e4 <u8g+8>, dev=<optimized out>, sck=<optimized out>, mosi=<optimized out>, cs=24 '\030', a0=255 '\377', reset=255 '\377') at .pio/libdeps/STM32F103RC_btt_stm32/U8glib-HAL/src/clib/u8g_ll_api.c:255
#7  0x08021f50 in U8GLIB::initSPI (this=this@entry=0x200009dc <u8g>, dev=<optimized out>, sck=sck@entry=25 '\031', mosi=mosi@entry=23 '\027', cs=<optimized out>, cs@entry=24 '\030', a0=<optimized out>, a0@entry=255 '\377', reset=<optimized out>, reset@entry=255 '\377')
    at .pio/libdeps/STM32F103RC_btt_stm32/U8glib-HAL/src/U8glib.cpp:45
#8  0x08012b5e in U8GLIB::U8GLIB (reset=255 '\377', a0=255 '\377', cs=24 '\030', mosi=23 '\027', sck=25 '\031', dev=<optimized out>, this=0x200009dc <u8g>) at .pio/libdeps/STM32F103RC_btt_stm32/U8glib-HAL/src/U8glib.h:75
#9  U8GLIB_ST7920_128X64_RRD::U8GLIB_ST7920_128X64_RRD (reset=255, cs=24, mosi=23, sck=25, this=0x200009dc <u8g>) at Marlin/src/lcd/dogm/HAL_LCD_class_defines.h:63
#10 __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at Marlin/src/lcd/dogm/marlinui_DOGM.cpp:79
#11 _GLOBAL__sub_I_u8g () at Marlin/src/lcd/dogm/marlinui_DOGM.cpp:472
#12 0x08022c30 in __libc_init_array ()
#13 0x08009266 in Reset_Handler () at /Users/keith/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/startup_stm32f103xe.s:97
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The correct fix here is: don't have a u8glib global var OR u8glib don't try init hardware on constructor, having a "init" method to be called on setup.

[adolson]

My apologies - I commented on the wrong thing. :\