Marlin: [BUG] [bugfix-2.0.x] Unstable MKS MINI 12864 on fast MCU

Created on 1 Apr 2019 · 31Comments · Source: MarlinFirmware/Marlin

Description

MKS MINI 12864 display is unstable when used with fast MCUs.
Observed glitches:

mirrored picture
wrapped picture
contrast glitches
display turned off

Glitched observed on STM32F407VE-based board (168MHz) and Re-ARM board (100MHz)

Steps to Reproduce

Install Marlin on STM32F407xx or Re-ARM with MKS Mini 12864 display
Wait for 15-180 minutes

Expected behavior:
No visual glitches on display

Actual behavior:
Various screen glitches

Additional Information

No stability problems were observed on STM32F103C8T6 MCU (72MHz)

Workaround / possible solution

Add screen configuration commands to U8G 'data start' esc-sequence in
src\clib\u8g_dev_uc1701_mini12864.c file of U8glib library.

static const uint8_t u8g_dev_uc1701_mini12864_data_start[] PROGMEM = {
U8G_ESC_ADR(0), /* instruction mode */
U8G_ESC_CS(1), /* enable chip */

0x040, /* set display start line to 0 */
0x0a0, /* ADC set to reverse */
0x0c8, /* common output mode */
0x0a6, /* display normal, bit val 0: LCD pixel off. */
0x0a2, /* LCD bias 1/9 */
0x02f, /* all power control circuits on */
0x0f8, /* set booster ratio to */
0x000, /* 4x */
0x023, /* set V0 voltage resistor ratio to large */
0x081, /* set contrast */
0x027, /* contrast value */
0x0ac, /* indicator */
0x000, /* disable */
0x0af, /* display on */

0x010, /* set upper 4 bit of the col adr to 0 */
0x000, /* set lower 4 bit of the col adr to 4 */
U8G_ESC_END /* end of sequence */
};

Confirmed !

Source

jmz52

All 31 comments

Why don't you submit a PR for a permanent solution?

psavva on 1 Apr 2019

I will eventually.
I was not sure if this is a problem with display or with my custom shield for STM32F407 until yesterday another person reported the very same problem on Re-ARM.

jmz52 on 1 Apr 2019

I'm using the re-arm with no issues on the LCD, are you using software SPI or hardware? SD card? Check that you don't have those 2 clashing...

psavva on 1 Apr 2019

Hardware SPI. SD card works just fine and is not affected by display's glitches.
Also display glitches occurs even when system is idle and with no SD card inserted.

jmz52 on 1 Apr 2019

@Bob-the-Kuhn any advice?

psavva on 1 Apr 2019

Are you using a shared SPI between the display and SD card (like many boards do) or are they separate ones?

Can you explain what your workaround is doing? It looks like it is basically sending the screen setup commands every time you write to the display. How does this differ from how things are now? What are the downsides of doing this (increased screen update time presumably? Anything else?).

Do you know if this problem has been seen on any other displays (like the more common RepRapDiscount Full Graphic Smart Controller)? Do you have a link to the details of the ReArm problems?

gloomyandy on 1 Apr 2019

Shared hardware SPI on standard EXP1/EXP2 connectors.

Suspected root cause - A0 line switches too fast for display's controller and sometimes data are processed as commands. But this may be an electrical interference causing the same behavior.
Workaround is to send extra 14 bytes to reset all registers to 'correct' values at the beginning of new page.
The only downsize is an extra time needed to send these 14 bytes every 1.2 seconds. Not a big deal for a 100+ MHz MCUs.

If I recall correctly the RepRapDiscount Full Graphic Smart Controller uses software SPI. I only did brief test of its functionality and do not know if it is affected.

Link to ReArm problem topic (in Russian) https://3dtoday.ru/questions/chudesa-s-ekranom-mks-mini-12864/

Original code without extra re-initialization:

static const uint8_t u8g_dev_uc1701_mini12864_data_start[] PROGMEM = {
U8G_ESC_ADR(0), /* instruction mode */
U8G_ESC_CS(1), /* enable chip */
0x010, /* set upper 4 bit of the col adr to 0 */
0x000, /* set lower 4 bit of the col adr to 4 */
U8G_ESC_END /* end of sequence */
};

jmz52 on 1 Apr 2019

With a shared SPI bus do you not see display glitches when the SD card is active? Does that mean that the MKS MINI 12864 does not suffer from the problem of the RepRapDiscount Full Graphic Smart Controller does not in effect honor chip select?

If the problem is that the signals are too fast for the controller is it not possible to use a slower SPI bus speed when talking to the display? Shouldn't the SPI bus speed be independent of the processor speed?

gloomyandy on 2 Apr 2019

MKS MINI 12864 is based on a UC1701 display controller.
RepRapDiscount Full Graphic Smart Controller is based on a ST7920.
It's very unlikely the UC1701 has the same hardware 'chip select error' as the ST7920.

AnHardt on 2 Apr 2019

👍1

Sorry - I don't have the hardware to duplicate this.

I gotten the 12864 to work on slower cards without any problems once I had the pin definitions sorted out.

On the RepRap full graphics, if the display initialization isn't correct the problem is apparent immediately.

If @gloomyandy is correct then the display is needing to be re-initialized mulltiple times after power up. this only happens if there is a power or signal integrity issue (assuming no softwarebugs).

Bob-the-Kuhn on 2 Apr 2019

@gloomyandy, glitches seems to be 'SD-card independent'. They happens with or without SD card active.
Also active SD prints are not affected by these glitches and repetier host can list SD card content via UART or USB connection.
A0 and CS lines are technically not a part of SPI hardware - they are configured as GPIO output pins and are toggled by u8g com function.

jmz52 on 2 Apr 2019

Did you try just adjusting the SPI clock speed to see if that can fix the problem? You may need to use different clock speeds for the LCD and SD reader. On the MKS sBase (which shares a single hardware SPI device between the onboard SD card reader and the LCD SD card reader), we use different clock speeds when accessing the two. Seems to work well.

gloomyandy on 2 Apr 2019

I did. Default settings are
spiConfig = SPISettings(SPI_CLOCK_DIV2, MSBFIRST, SPI_MODE0);
I've tried to slow down SPI to SPI_CLOCK_DIV8 but it had no effect on display's stability.

jmz52 on 2 Apr 2019

I had been seeing the same thing on an SKR-V1,3. It takes a while, but the screen goes blank. It reappears briefly when you hit reset, with the last image it had. Now today, 4/13/2019, I pulled the current 2.0.x release for an SKR V1.1 that has the same display solid on the 3/9 pull, and it never shows an image until I press reset. Then again, briefly showing the last image it should have shown, when reset, that is, the knob works and I can move blindly through the menus.

jmdearras on 13 Apr 2019

The lib patch above fixed my display for the 4/12 version. Seems odd it needs it now. it really slows the display scrolling the SD card.

jmdearras on 13 Apr 2019

That patch also disables contrast control

jmdearras on 14 Apr 2019

Is anyone working on this?

jmdearras on 17 Apr 2019

I've run into a similar issue (wrapped text) on an I2C OLED display on a ReARM, while it does work correctly on another board. Here's a picture:

20190417_214602

This glitch happens randomly after a bit of time and goes away when the board is reset - during reset it displays the last image it had, but it's correctly aligned. The same display on a ESP32-based prototype controller does work correctly all the time.

Idorobots on 17 Apr 2019

I've run into a similar issue (wrapped text) on an I2C OLED display on a ReARM, while it does work correctly on another board.

That is what is happening on the MKS MINI 12864, except now on the latest 4/15 release, the display always starts blank, and only shows the presumed last image during reset. The code patch above partially fixes it, but something else is causing it.

jmdearras on 18 Apr 2019

Hi, the PR 14087 was designed to fix my issues using LPC1768, but could fix same issues in other platforms.
But I decide to insolate to LPC1768 because is the onlu hardware i own to test

DrDitto on 23 May 2019

👍1

Hi, I had similar issues, which were solved by this workaround.
I am running the SKR 1.3 (so LPC1768) with the Ender 2 display unit (MINIPANEL). Because the display unit uses one 10 pin connector I am using software SPI.
The display showed some pixels at startup, sometimes the main menu, but turned blank after a second or so.

Before discovering this solution I´ve tried several other things like different software SPI speeds and using the actual SPI instead - which brought no improvement.

So I guess this solution can be used for the MINIPANEL as well.

Maybe I will look further into the SPI transmission itself in the next few days..

Str8t on 27 May 2019

Ok I made a mix of this workarrround with others and change the minipanel to the hal instead od the library.
Actually mks_mini_128964 is totally stable and remains the contrast adjust.

https://github.com/MarlinFirmware/Marlin/compare/bugfix-2.0.x...DrDitto:bugfix-2.0.x

DrDitto on 28 May 2019

    static const uint8_t u8g_dev_uc1701_mini12864_HAL_data_start[] PROGMEM = {
      #if ENABLED(MKS_MINI_12864)
          U8G_ESC_ADR(0),             /* instruction mode */
          U8G_ESC_CS(1),              /* enable chip */
          0x040, /* set display start line to 0 */
          0x0a0, /* ADC set to reverse */
          0x0c8, /* common output mode */
          0x0a6, /* display normal, bit val 0: LCD pixel off. */
          0x0a2, /* LCD bias 1/9 */
          0x02f, /* all power control circuits on */
          0x0f8, /* set booster ratio to */
          0x000, /* 4x */
          0x023, /* set V0 voltage resistor ratio to large */
          0x0ac, /* indicator */
          0x000, /* disable */
          0x0af, /* display on */
          0x010, /* set upper 4 bit of the col adr to 0 */
          U8G_ESC_END                 /* end of sequence */
      #else
          U8G_ESC_ADR(0),             /* instruction mode */
          U8G_ESC_CS(1),              /* enable chip */
          UC1701_COLUMN_ADR(0),       /* address 0 */
          U8G_ESC_END                 /* end of sequence */
      #endif
    };

DrDitto on 28 May 2019

This change preserve the fysetc compatibility and fix the mks_mini_12864, glitches

DrDitto on 28 May 2019

Could propose a Pull Request?

On Tue, May 28, 2019, 7:20 AM DrDitto notifications@github.com wrote:

This change preserve the fysetc compatibility and fix the mks_mini_12864,
glitches

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/13550?email_source=notifications&email_token=AALDFJRVKRLBC3Y7UBWP6PTPXSXKXA5CNFSM4HCUSEQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWK5RSQ#issuecomment-496359626,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALDFJQ5VCSEFI3WNCYVBWDPXSXKXANCNFSM4HCUSEQQ
.

psavva on 28 May 2019

I like to extend my internal test for at least check msk_sbase and SKR V1.3 3 days more. Then I will make the PR

DrDitto on 29 May 2019

I really want to thank you jmz52 beacuse his work let me the kwoledge to make the research I use to make the changes and that I use to fix the mks_mini_12864 glitches and user the constrast feature. Without this bugfix there is no way I can write mine.

DrDitto on 29 May 2019

Sorry to have passed over the above fix for so long, but all attention has been on clearing PRs, which are arriving at a fast pace and leaving less time for issue scrubbing. That patch will be applied shortly.