Full graphic controller issues under Arduino >1.0.6

[BKayCode]

I have a Reprap discount full graphic smart controller connected to a K8200 (3DRag derivative).
U8glib is installed and #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER uncommented.

When compiling RC6 with Arduino 1.6.9 I get weird artefacts on the display:

Under 1.0.6 (version check in SanityCheck.h commented) it compiles with no errors and the display is working fine.

My configuration.h: http://pastebin.com/L0B7iak6

[jbrazio]

@Gaffalover could you try to remove you current U8glib and do the following command:

# Install: Monochrome Graphics Library for LCDs and OLEDs
arduino --install-library "U8glib"

Compile with 1.6.9 and check if the error is still there ? Yesterday night I compiled my Marlin with 1.6.9 without issues.

[BKayCode]

Thanks for your reply.
Just gave it another shot:
Uninstalled 1.0.6 and deleted the %USERPROFILE%/Documents/Arduino folder.
Installed 1.6.9 and did your command -> same result as shown in the picture.
Just 4 fun I reinstalled 1.0.6 without touching the library folder or Program (except commenting the version check in SanityCheck.h) an it works fine.

For me it looks like an issue with the IDE at versions >1.0.6.
I even tried installing U8glib 18.0.0 instead of 19.x and lcddisplay 1.0 but without success.
I couldn't find anything noticeable in the changelogs of the Arduino IDE.

[jbrazio]

Do you mind trying with 1.6.8 ?

[BKayCode]

I even tried it with 1.6.5 and still no improvement.
In another forum somebody had exactly the same issue: http://fpv-community.de/showthread.php?69744-Hilfe-bei-Marlin-Mega-2560-Ramps-1-4-Full-Graphic-Display/page3
He used RC2 and 1.5.x with the same artifacts.

[jbrazio]

And clicking on the encoder to go into the menu doesn't clear the error ?

[SwiftNick]

I have the same problem using Arduino 1.6.9 compiling Marlin 1.1.0-RC6
configured for the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

It seems to be caused by the compiler optimisation line in 'ultralcd_st7920_u8glib_rrd.h'
Change line 31
FROM:
#pragma GCC optimise (3)

TO:
//#pragma GCC optimize (3)

This will disable the optimisation and the LCD should display correctly.

NOTE: I haven't run full tests on this to see if printing is adversely affected but I suspect the later optimisation in Arduino 1.6.x has messed up the timing when sending data to the display.

[Roxy-3D]

@MarlinFirmware/general-maintainers Guys, this might be our chance to figure out what was going wrong with building Marlin with certain versions of Arduino. I may be wrong, but can't we remove that one line of code:

#pragma GCC optimise (3)

from the .h file and place it further and further down in the .cpp file until things work again? When things start working, we will know the location of the optimization failure and be able to figure out what keeps killing us????

This strategy is very crude, because if the LCD file has multiple failures, we may not get a good build until we have the #pragma line below them all. So if this strategy did produce results, we might want to change the code and start the search again to see if there are any other failures with the LCD file.

With that said... With this new information, we might be able to figure out what has been killing us.

@SwiftNick Thank You for the help! Do you have any comments on what I just suggested?

[Blue-Marlin]

Dear @Roxy-3DPrintBoard
We are not killed. With 5 ST7920 from different sources we do not having any problems here.

Using Arduino 1.6.9 we do not see any speed differences but compiling without #pragma GCC optimise (3) saves about 2k of progmem.
With earlier Arduino versions there used to be a good speed impovement. (Don't ask what versions - versions from about a year ago)

So for now we can comment the #pragma GCC optimise (3) because it does not find faster code (just biger). But as soon it will do that again we definitely want to use that!

Using the standard configuration with just added REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
and idelecounter patch (AnHardt@fd20acc)
System just booted and nothing to do.

//#pragma GCC optimize (3)

Der Sketch verwendet 83.886 Bytes (33%) des Programmspeicherplatzes. Das Maximum sind 253.952 Bytes.
Globale Variablen verwenden 3.842 Bytes (46%) des dynamischen Speichers, 4.350 Bytes für lokale Variablen verbleiben. Das Maximum sind 8.192 Bytes.

23:45:05.556 : echo:idles/second: 10499
23:45:06.559 : echo:idles/second: 10520
23:45:07.559 : echo:idles/second: 10509
23:45:08.558 : echo:idles/second: 10509
23:45:09.557 : echo:idles/second: 10509
23:45:10.556 : echo:idles/second: 10521
23:45:11.560 : echo:idles/second: 10509
23:45:12.559 : echo:idles/second: 10505
23:45:13.558 : echo:idles/second: 10521
23:45:14.557 : echo:idles/second: 10497


#pragma GCC optimize (3)

Der Sketch verwendet 85.922 Bytes (33%) des Programmspeicherplatzes. Das Maximum sind 253.952 Bytes.
Globale Variablen verwenden 3.842 Bytes (46%) des dynamischen Speichers, 4.350 Bytes für lokale Variablen verbleiben. Das Maximum sind 8.192 Bytes.

23:47:25.140 : echo:idles/second: 10517
23:47:26.139 : echo:idles/second: 10514
23:47:27.138 : echo:idles/second: 10515
23:47:28.138 : echo:idles/second: 10527
23:47:29.141 : echo:idles/second: 10515
23:47:30.140 : echo:idles/second: 10512
23:47:31.139 : echo:idles/second: 10527
23:47:32.138 : echo:idles/second: 10502
23:47:33.138 : echo:idles/second: 10527

[Roxy-3D]

So for now we can comment the #pragma GCC optimise (3) because it does not (generate) faster code (just big(g)er). But as soon it will do that again we definitely want to use that!

@Blue-Marlin Yes, but we have seen build problems on many versions of Arduino. And not all of those problem scenarios had graphics controllers. (In fact, as you know we are refusing to build with older versions of Arduino because we had too many weird problems that could not be explained.) Isn't this an opportunity to find out what code constructs are causing us problems? Maybe we have something declared wrong. Or maybe we are linking something wrong. Or maybe we have something else strange going on.

Even though we can get around this (for the moment) by commenting out the optimization, it bothers me we have to do that just because we have no idea why that is necessary.

[SwiftNick]

It may be worth investigating the changes in the optimisation algorithm in newer versions of gcc that are shipped with Arduino. I have known bugs in optimisers that do stupid things like take items out of loops to make them run faster! Something has definitely changed as compiling with older tools seems to work. 03 turns on all optimisations so if size is the main reason for the optimisation it may be worth tweaking the flag.

[Roxy-3D]

If we knew which function required the relaxed optimization, we can compile it both ways and see what is going on. It may be a bug in the optimization. But it is also possible we have something declared in a way that the optimizer makes a bad decision (which I guess is still a bug). If we understood what was going wrong, it may be that we can harden the code (every where... Not just in the Graphics Controller code) to keep this from happening in the future.

[epatel]

How about doing some binary search in the file in question using push/pop options? Easiest first test would be just to move the "optimize" to the middle of the file.

#pragma GCC push_options
#pragma GCC optimize (3)


#pragma GCC pop_options

I'd do it myself if I had my stuff setup and could see this happening
Ah I see @Roxy-3DPrintBoard basically recommended this earlier

[Roxy-3D]

Yeah, but I didn't know about push & pop. That is cool! If I had a graphics controller, I would be trying to isolate it. I would still need help to get it to generate and leave the .ii files around. Every time I need to look at the generated assembly code, I can never get the files to stick around. But I know jbrazio can do it because he was posting instruction cycle timing for various code constructs.

[jbrazio]

-O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options.

-funswitch-loops and -fpredictive-commoning will produce bigger code and apply some optimization that could break loops().

The only person who is able to test which exact function/piece of code breaks with -O3 is @Blue-Marlin which seems to have access to this specific LCD.

[Roxy-3D]

And... given what you just communicated... Once we identified the function with the optimization problem, we could even just turn on one more optimization at a time for the function until we find the one causing problems.

[jbrazio]

Yes we can either keep behavior of optimizing all and exclude that specific part, or has @Blue-Marlin suggested disable all the optimization has it seems not to have a positive effect with the latest gcc toolset.

Concerning this being the reason for other IDE issue we had.. I don't believe so and this only activates optimization for this file and I did a quick grep a no other #pragma were found.

[SwiftNick]

I've done the binary search and the optimisation fails for the first function in the file:
If you move the push just below and the pop at the end of the file, to exclude this function the display works just fine.

static void ST7920_SWSPI_SND_8BIT(uint8_t val) {
  uint8_t i;
  for (i = 0; i < 8; i++) {
    WRITE(ST7920_CLK_PIN,0);
    #if F_CPU == 20000000
      __asm__("nop\n\t");
    #endif
    WRITE(ST7920_DAT_PIN,val&0x80);
    val<<=1;
    WRITE(ST7920_CLK_PIN,1);
    #if F_CPU == 20000000
      __asm__("nop\n\t""nop\n\t");
    #endif
  }
}

[Roxy-3D]

Can you selectively turn on more of those flags for the first function and find out which one is causing the problem?

And then using that information we may need to look at the generated assembly code. But there is very little going on there. It might be a timing problem. Or maybe the GCC is optimizing away one of the writes to ST7920_CLK_PIN. (Don't have time to look at those macros right now. But will in the morning.)

[Blue-Marlin]

@SwiftNick
What board do you use?

[SwiftNick]

The 3drag with the ATMega2560 (shipped with the Velleman k8200)

[Blue-Marlin]

@SwiftNick
Please make a test with O3 but activated nop's.

[jbrazio]

I would bet on the WRITE(ST7920_CLK_PIN,0); and WRITE(ST7920_CLK_PIN,1); ending out of the cycle due to -fpredictive-commoning. But your suggestion is interesting.. you believe optimization is going "too fast" for bit banging so it requires the delay.

[Blue-Marlin]

@jbrazio
I suppose a bad display, to long cables, to much noise, not enough voltage or a wrong crystal on the board - a hardware problem what requires a relaxed timing.
If @Gaffalover and @SwiftNick have the same problem and both have a K8200, but "noone" else sees the problem, i suppose a systematic problem, like too long cables, with the K8200. Than a fix for K8200 is better then maybe slowing down all ST7920 displays.

In theory the impact of adding 3 nop's should be smaller than not unrolling the loop (about 5 nop's - increase i in a register, jump back, compare i). I'm just interested in how far off some K8200's are.

[SwiftNick]

I thought it was those too so I commented them out and the screen worked just fine.
The ATMega2560 has a 16Mhz clock so I guess they are disabled in my case anyway by the F_CPU definition.

[SwiftNick]

FYI have upgraded my controller to the 3DualDrag which has the same timing requirements as the 3DRag.

[VenHeelun]

Hi. I followd your post with interest because i have the same problem.
I did remove the "//" in the line "//#pragma GCC optimize (3)". That solved one problem. Now the screen shows no garbled artafacts anymore like in the photo from Gaffalover. The screen is now spaced out like it should.
However; the problem i have is that i ONLY get graphical content on my screen. It shows only the nozzle icon, heatbed icon, fan icon, X,Y,Z bar, SD-Card icon & progress-bar.
You can watch this to see what i mean: https://youtu.be/o_hSNFkWCd8.

I don't know a tiny little bit about programming. I did once made basic programs but c++ is out of my leage. The examples in this post i did try but with no result.

I am using a Velleman K8200 with the Reprap Discount Full Graphic Controller with Arduino 1.6.11 and Firmware Release Candidate -- Marlin 1.1.0-RC3 - 01 December 2015 from Github.

I don't think it's the flatcable because in Marlin 1.0.6 with the stock firmware 2.1.1 everyting is working fine accept the Auto bed leveling (wich is not implemented in versin 2.1.1). Even the Reprap Discount Full Graphic Controller is working fine.
The only reason of changing to the new firmware is the Auto Bed Leveling.
Til now it only gives me troubles so if ths could be solved i realy jump a hole in the air.

Thank you

[SwiftNick]

VenHeelun,
Try a later build.
There are fixes in RC7 already.
https://github.com/MarlinFirmware/Marlin/archive/RC.zip
It looks like the fonts are missing.

[VenHeelun]

Dear SwiftNick
Thank you, Thank you.
I uploaded the firmware and did get an error regarding the LCD_PROGRESS_BAR.
I put "//" before "#define LCD_PROGRESS_BAR" in the Configuration_adv.h file and everything finaly works.
Now i finaly can setup the rest of my printer.
I don't think i can be very helpfull in this discussion but i will follow it further.
Again thank you.

[FHeilmann]

Sorry for unburying this old thread, but I have some issues with my

Reprap Discount Full Graphic Controller on a MKS Base 1.4 with the latest RCBugFix.

With short cables everything works as intended, but as soon as I switch to a longer cable (about 60cm, even ordered a shielded ribbon cable that was ridiculously expensive, no dice) the display doesn't turn on anymore and only emits a "ticking" sound.
My guess is that the long cable somehow screws up the comunication. Will playing around with the Delays as possible through the configuration solve this problem?

Can I start with large delays and work my way down until it works?

[Blue-Marlin]

Try to change EXP1 with EXP2. A dark display is never caused by to short delays. The tick sound means the buzzer is connected to one of the SPI lines.

[FHeilmann]

Welp, turns out not one but both the ribbon cable orientations is flipped on either my board or my display. Bit the bullet and forced them in reversed and everything works flawlessly. Thanks for the hints.

[ksyz]

Hey, I just want to confirm this bug on Melzi (some spin-off by Malyan for M150, as some pins don't match) with some kind of "Reprap Discount Full Graphic Controller" display. Compiling with Arduino 1.6.4 (disabled sanity check) supplied by Fedora 25, U8glib 1.19.1.

I was not able to fix display fragments by NOP sequence 0,3,0 (nor 0,0,4, nor 1,2,0 - almost random pick-ups, trying to figure out the pattern), but 0,4,0 and 2,2,0 sequences work great (1,2,1 and 2,1,1 gave few random pixels). As if there have to be 4 NOPs before WRITE(ST7920_CLK_PIN, HIGH); , DELAY_1 doesn't matter at all, and none after. No idea why. Looking at the assembly, there are all four of NOP.

But for now, I have working firmware for Malyan M150 and 1.1.0-RC8. I will test it a bit, and then share example_configuration.

There is a source dump by vendor, that seems to be based on 1.0.2-2. Assuming they got it somehow (I did not) working with some past versions of Arduino, this issue may be related to newer versions of arduino. (as stated before).

Thanks!

[AnHardt]

See my comments in #4994 (comment)

[bolsoncerrado]

Hi @AnHardt @Gaffalover @FHeilmann @thinkyhead and the rest....

I just ended up here by googleing the same issues on the first screenshot of this thread.
Mine is a CR-10 Creation Reality printer, that comes with a Melzi variant where I burned the bootloader and upgraded Marlin 1.0 to Marlin 1.1.3

For that, I used Arduino 1.6.8, a MEGA256 (Genuino) and u8glib_arduino_v1.18.1.zip

Stock board, LCD and Marlin 1.0 had the LCD working fine.
Now, with 1.1.3 aboard, I have the issues pictured on the first thread (aka https://camo.githubusercontent.com/ae36cee75437f8ad2ca2cc709c04b52d9e1f34dd/687474703a2f2f696d616765732e7461706174616c6b2d63646e2e636f6d2f31352f31302f32372f39636431646139363238626533656130343366396137643037353938383765312e6a7067)

Mine are a bit more readable and once I move the knob and position on a Menu option, the font shows it clearly and readable. Once you move out to point to a new option, new option reads fine but the option before becomes unreadable again.

When compiling I had a warning I reported to u8glib and they only pointed out I could try with u8glib2.

Is this related or shall I seek somewhere else? I couldnt understand the problem since it's the very same hardware and wire that was working fine with 1.0 so it must be software related?

Thanks!

[webliya]

I had the same problem. It is a clock issue. Just changing the delays worked perfect.

in ultralcd_st7920_u8glib_rrd.h I found this and copied to configuration.h to the end of lcd definitions;

// If you want you can define your own set of delays in Configuration.h
//#define ST7920_DELAY_1 DELAY_0_NOP
//#define ST7920_DELAY_2 DELAY_0_NOP
//#define ST7920_DELAY_3 DELAY_0_NOP

and to give some delay I changed it to;

// If you want you can define your own set of delays in Configuration.h
//#define ST7920_DELAY_1 DELAY_0_NOP
//#define ST7920_DELAY_2 DELAY_3_NOP
//#define ST7920_DELAY_3 DELAY_0_NOP

And screen is clear and brilliant than ever.

This problem is using a reprapdiscount full graphic smart controller with Melzi board. I build a special cable with the instructions below;
https://www.thingiverse.com/thing:488884
which works perfect.

You can see the photos of all at;
https://www.dropbox.com/sh/34a0ebds318r3th/AABkLBRiUXoFWGCz7eVX-tkwa?dl=0

Thanks for the ideas here.

[stefi01]

i have an issue with the same lcd, i have 2 identical displays, one works fine but when i plug they other one in i get the same thing, some of the display shows, some is missing, swap it back to the 1st lcd gain and it works fine again

[Chompworks]

Just hit this with a Tevo Tornado with a MKS GEN L board, and RRD Full Graphic Smart Controller, trying to install Marlin 1.1.8 then 1.1.9. Going to try some of the steps further up the thread with disabling the optims and changing timing. Ive also got a replacement display coming soon to hopefully prove/disprove whether its hardware. If it is, would be happy to forward the faulty one on to someone if it helps to troubleshoot or come up with workarounds.

Edit 1: commenting out #pragma GCC optimize (3) doesn't have any notable effect.

Edit2: @webliya has the solution that worked for me.

Added the 3 delays to configuration.h and after a bit of trial and error with the numbers, getting a perfect screen now.

#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
#define ST7920_DELAY_1 DELAY_NS(0)
#define ST7920_DELAY_2 DELAY_NS(250)
#define ST7920_DELAY_3 DELAY_NS(250)

[CdRsKuLL]

Thanks for the solution Chompworks. This solved my issues going from 1.1.8 to 1.1.9. Running a bespoke Jgaurora Z603s motherboard. Can release an update now.

Steve

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

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

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

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