[BUG] AZSMZ_12864 after cold start does not initialize

[kpishere]

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

Yes, and the problem still exists.

Bug Description

Screen is garbled, often with lines or full black but sometimes clear too. Must press reset pin for screen to initialize properly.

Bug Timeline

December 2020

Expected behavior

I'd expect the screen to be initialized from cold start just as it is from a warm start.

Actual behavior

From cold start, the screen is often garbled and requires a press of the reset button on the panel for it to initialize properly.

Steps to Reproduce

Turn on machine after being off.

Version of Marlin Firmware

FIRMWARE_NAME:Marlin bugfix-2.0.x (Mar 31 2021 00:07:27) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Itopie 400+ EXTRUDER_COUNT:1 UUID:41B1EDA1-B268-466E-8B01-C6458C23FFF2

Printer model

iTopie400+

Electronics

SMART RAMPS with MEGA2560 and TMC2209 drivers

Add-ons

No response

Your Slicer

Cura

Host Software

SD Card (headless)

Printer acts as one would expect even when screen is garbled -- can see at sharp angle in screen, the indented image a bit and by serial port behaviour.

Youtube showing screen behaviour

Archive.zip

[thisiskeithb]

Display timings were updated in #21518, so please download bugfix-2.0.x to test with the latest code and let us know if you're still having this issue.

If that doesn't work, there's also a PR to rework U8glib initialization: #21496

[kpishere]

@thisiskeithb The update #21518 does not fix it. Trying the other one. I think I notice that screen flashing once now but the black background comes back. Still needs reset. Will try the referenced PR.

[kpishere]

@thisiskeithb Sadly, tried the #21496 PR and still, no change. Must press reset in order for screen to initialize correctly. From cold start, it is usually black.

Note: A while back, I did check the quality of the power supply on startup and it is a steady rise in 50ms.

I've also pushed the latest version of my repo with the PR applied to the repo referenced in this ticket.

[descipher]

With a Mega2560 and this PR Default DELAY_NS to round up. #21546, things should work. Please try again.

[kpishere]

@descipher I gave it a try. Nope, still issue. Think gonna have to bust out the logic analyzer tonight. Will record the on-start and reset messages and get back to you on that.

[descipher]

Looks like the AZSMZ 12864 Display uses the ST756x series of controllers. That code does not use the DELAY_NS() macro which #21546 addresses.
I can look at that driver code but cannot test it, question:
Did you update the avr-gcc tool chain or something else in platformio?

[kpishere]

@descipher Nope. I've been using the Arduino IDE and it's build-chain. It is at version 8.1.13 for the IDE and both libraries U8g2 version 2.28.10 and U8glib version 1.19.1 are installed.

[descipher]

Since it functions after a reset, we can surmise that the ST756x driver is ok, It sounds like the display init is happening before the display is ready after power up.
You could try a delay in the init sequence in ..\src\lcd\dogm\u8g_dev_st7565_64128n_HAL.cpp

static const uint8_t u8g_dev_st7565_64128n_HAL_init_seq[] PROGMEM = {
U8G_ESC_CS(0), // disable chip
U8G_ESC_ADR(0), // instruction mode
U8G_ESC_CS(1), // enable chip
U8G_ESC_RST(15), // do reset low pulse with (1516)+2 milliseconds (=maximum delay)/
U8G_ESC_DLY(100), // Wait 100ms
ST7565_BIAS_MODE(0), // 0xA2: LCD bias 1/9 (according to Displaytech 64128N datasheet)
ST7565_ADC_REVERSE(0), // Normal ADC Select (according to Displaytech 64128N datasheet)

[FanDjango]

@descipher I actually get this kind of "glitch" on my REPRAP_DISCOUNT display, for whose controller we very recently tweaked the delays. It only happens maybe once every 100 printer power-on, and if it happens I just press reset for the printer. So there is certainly a good idea to "globally" check this.

[descipher]

Yes, we should take note of what any change touches and monitor it. I have a list of what DELAY_NS() touched around the ST7920 which is fairly narrow. With power on init instances the scope widens a little.

[FanDjango]

Maybe there is not even a delay there, but the entire sequence is being issued to soon, has also happened in the past.

Power on sequences were modified a short time ago too, for other reasons.

The thing is, one might want to split the LCD init into parts, because some of the delays required could be used to initialize or to wait for other peripherals inits too. For example, really only to indicate the principe, you init the BLTouch, which needs a (say) 500ms delay somewhere in the process, which would be enough to init other stuff too.
So in the init code, I would

init lcd part 1
init bltouch part 1
delay 1000ms
finish lcd init part 2
finish bltouch init part 2

Currently we are hanging all the inits we have (if DEFINED...) behind each other. Some of them don't need a delay, but some do and the delays accumulate. On the other hand, some need to be finished BEFORE other inits even begin, but certainly not all.

Some day one could envision an init "architecture" that allows you to "insert" a peripheral into the power-on sequence based on its priorities, and also interleaving its possible delay stages with those of the same prio.

Edit: Maybe a bit OT, but any delays in init add to the overall delay and many suffer when the total init time gets longer and longer.

[descipher]

Nothing should be allowed to init until power is stable on all devices as a rule. With all the variable boards/arch's Marlin supports it becomes a real challenge on how to reach that one principle.

[kpishere]

Ok, so I am seeing some subtile differences.

Here is overview of a cold start. Notice the spike on all signal lines at the beginning.

Here is an overview after a reset.

Looking at those spikes for the cold start, looks a little indeterminat, perhaps my power-up is too slow? Maybe Arduino isn't asserting reset line or there should be a pulldown on reset line for display?

As chip select comes high after a cold start, it looks quite different than for after a reset. Here is after cold start

Here is what happens after reset around time of chip select

Here are the first bytes transmitted after reset

And here are the first bytes transmitted after a cold start -- they are not the same. The display is flickering but mostly black, I bet it is glitching.

So, I donno, there are probably hardware fixes that can be made. But are there software approaches to work around this?

[descipher]

I suspect it is a power issue. From a software perspective it is working, if you want to verify you can add a large delay in marlincore.cpp in the setup section. Brown out detection could also work but that may create other complications.

void setup() {

delay(1000); //Wait 1 second for power stability.

tmc_standby_setup(); // TMC Low Power Standby pins must be set early or they're not usable

[kpishere]

@descipher Yes, think this is so. Close ticket? Or maybe there is software solution? I've added sensing of 5V power on the display, here are some samples of that. If ticket is closed, this topic is more for EEVBlog or RepRap forums.

Here is overall initial power to CS going high. Notice the time here, it is already 1 second before CS comes high, I'm thinking adding more startup delay won't help. I should add reset line to this picture too and see what that is doing.

This is a common AliExpress power supply as one would get for 3D printers, it is a 24V one. That first spike on all lines, is really odd. Currently, I have the power switch disconnecting both lines from the power supply. I'm wondering a) perhaps I should only disconnect one line, there could be a static discharge with both lines disconnected and then reconnected. b) a slight load resistor along the 24V output of the power supply could help discharge any capacitance in power supply. I'd noticed it does seem to store quite a bit as it takes a few seconds for electronics to stop after mains is turned off.

A close up of that initial spike.

A closeup of when the power comes up - the brownout stage.

[kpishere]

@descipher Yah, ok, the reset also looks bad in that initial spike. I'm pretty sure this is a problem with what I'm doing with power supply. I'm gonna try the above to steps independently, keep one of mains lines connected for grounding/Neutral purposes, add a load resistor to discharge any capacitors because MEGA2560 on it's own isn't enough of a load to keep capacitors discharged.

Here is another shot, when the reset line comes high. It looks like garbage! This is a MEGA 2560 clone, that may explain it (haven't checked a genuine Arduino, could be just as bad). But still, if this is the source of the problem, then this issue will be more common with Marlin users.

[descipher]

This is most likely the SMART RAMPS regulator with the initial surge, does it do this with USB only supply? Those regulators are kicked hard with 24v and are frequently damaged by it. I do agree that its not a code issue.

[kpishere]

@descipher The short answer is yes, it works when powered from USB. To do that, I have a second MEGA2560 (clone from same supplier as the other). I program it and run the MEGA2560 with the same display (pulled from the printer). It has nothing connected to it but USB and display (and logic probe).

The results aren't drastically different. Thought I'd provide here for the complete picture of what works vs what does not work with the same tool and process.

Overview from USB plug-in:

A similar spike on all lines when plugged into USB:

Time profile form power on to reset high:

At point where chip select goes high :

And the first bytes of data :

Maybe the measurements look a little less noisy but there is no ahhah! I'm gonna try other stuff like ferrites on the cables etc.. Anyhow, that seems like the full picture of what works vs. what doesn't work. Gotta pay close attention to the time scale, they are all different and if I were to do again, would have been more careful about making sure they were all similar.

[descipher]

Thanks for the analyzer detail. It is definitely power related, 5v to the clone regulator and it's working is telling.

[thisiskeithb]

topic is more for EEVBlog or RepRap forums

Agreed. Here are some other resources:

• Marlin Documentation hosted on MarlinFW.org
• Marlin Forum hosted on RepRap.org
• Marlin Firmware Facebook Group
• Marlin Firmware for 3D Printers Facebook Group
• Marlin Configuration on YouTube
• Marlin Firmware Discord server

[nicolasLh07]

Hijos de perra dejen de mandarme correos y déjenme borra mi cuenta me tienen hasta la madre Obtener Outlook para iOS<https://aka.ms/o0ukef>

…

________________________________ De: Keith Bennett ***@***.***> Enviado: Thursday, April 8, 2021 5:23:55 PM Para: MarlinFirmware/Marlin ***@***.***> Cc: Subscribed ***@***.***> Asunto: Re: [MarlinFirmware/Marlin] [BUG] AZSMZ_12864 after cold start does not initialize (#21522) topic is more for EEVBlog or RepRap forums Agreed. Here are some other resources: * Marlin Documentation<https://marlinfw.org> hosted on MarlinFW.org * Marlin Forum<https://forums.reprap.org/list.php?415> hosted on RepRap.org * Marlin Firmware<https://www.facebook.com/groups/1049718498464482/> Facebook Group * Marlin Firmware for 3D Printers<https://www.facebook.com/groups/3Dtechtalk/> Facebook Group * Marlin Configuration<https://www.youtube.com/results?search_query=marlin+configuration> on YouTube * Marlin Firmware<https://discord.gg/n5NJ59y> Discord server — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#21522 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATASAMPSX3EKO6ZHJ52PNCDTHYUHXANCNFSM42JPGFLA>.

[thisiskeithb]

@nicolasLh07: You can unsubscribe from this thread using the link in your email or by clicking the unsubscribe button to the right or bottom of this issue on GitHub.com.

if you want to delete your account, that can be done through GitHub.com.

[kpishere]

FYI: Problem was solved with a 4.7uF capacitor between the ground pin and the reset pin on the display. Important that it is on the display side as the installed ribbon cables go by power supply and pick up noise, inductance, etc. A ferrite core on that same ribbon didn't help.

[descipher]

The power supply noise problem still exists, that is definitely a good workaround and solves the LCD symptom.

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