[BUG] RADDS v1.5 LCD 2004 Initialization problem

[ShadowOfTheDamn]

Bug Description

Dear experts
When the printer is turned on the 2004 LCD (rep-rap smart controller) seems to be late to initialize and draws 2 lines of blocks, but if you reset the printer it will initialize and every thing works ok.

My Configurations

Configuration.zip

Steps to Reproduce

Just turn on the printer.
If you reset the printer with the reset switch the screen will initialize.
but if you turn off the printer and turn it on again it wont help.

Expected behavior: I expect the LCD work correctly in the first boot.

Actual behavior: The printer need a reset so the LCD could get to work.

Additional Information

A video of the screen is provided:

Video.zip

Edit (23/06/2020) :

1-checked all the wiring and connectivity
2-checked cable length (20cm, 30cm, 60cm, 1m)
3-double checked the pin numbering in marlin
the issue is not solved.
I thought it is clear in the video that the LCD initialization lag behind the system.
If the motherboard lose power I need to reset to see the LCD but if I switch off the system for as short period of time, just before it lose the power completely (when LEDs are fading on the MB) I power on the system the LCD initialize. so this seems connected on how things get powered on and initialized (i Think). It is noteworthy again to add I didn't have the problem while using an older version of marlin before and got stock with this after upgrading, unfortunately does not have my old configuration nor the source so I cannot revert)

[sjasonsmith]

Is anyone else able to reproduce this issue?

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[ShadowOfTheDamn]

please open it again:
Edit (23/06/2020) :
1-checked all the wiring and connectivity
2-checked cable length (20cm, 30cm, 60cm, 1m)
3-double checked the pin numbering in marlin
the issue is not solved.
I thought it is clear in the video that the LCD initialization lag behind the system.
If the motherboard lose power I need to reset to see the LCD but if I switch off the system for as short period of time, just before it lose the power completely (when LEDs are fading on the MB) I power on the system the LCD initialize. so this seems connected on how things get powered on and initialized (i Think). It is noteworthy again to add I didn't have the problem while using an older version of marlin before and got stock with this after upgrading, unfortunately does not have my old configuration nor the source so I cannot revert)

[ShadowOfTheDamn]

today I check the new bugfix and the problem is still there.
anyone have any idea?

[thinkyhead]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

Also enable PINS_DEBUGGING so you can send M43 and make sure all the pins look correct.

[ShadowOfTheDamn]

Thank you Scott, Used the latest Bugfix two days ago but unfortunately it wasn't fixed. Used M43 and all the pins were ok.
here is the M43 output:

M43
SENDING:M43
PIN: 00 RXD0 Input = 1
PIN: 01 TXD0 Input = 0
PIN: 02 Z_STEP_PIN protected
PIN: 03 Z_DIR_PIN protected
PIN: 04 SDSS Output = 1
. SS_PIN Output = 1
PIN: 05 SERVO0_PIN Output = 0
PIN: 06 SERVO1_PIN Input = 1
PIN: 07 HEATER_BED_PIN protected
PIN: 08 E0_AUTO_FAN_PIN protected
. FAN1_PIN protected
PIN: 09 FAN_PIN protected
PIN: 10 LCD_SDSS Output = 1
PIN: 11 HEATER_2_PIN Output = 0
PIN: 12 HEATER_1_PIN Output = 0
PIN: 13 HEATER_0_PIN protected
PIN: 14 SD_DETECT_PIN Input = 0
PIN: 15 Z_ENABLE_PIN protected
PIN: 16 Y_DIR_PIN protected
PIN: 17 Y_STEP_PIN protected
PIN: 18 TXD1 Input = 1
PIN: 19 RXD1 Input = 0
PIN: 20 <unused/unknown> Input = 1
PIN: 21 <unused/unknown> Input = 1
PIN: 22 Y_ENABLE_PIN protected
PIN: 23 X_DIR_PIN protected
PIN: 24 X_STEP_PIN protected
PIN: 25 X_CS_PIN protected
PIN: 26 X_ENABLE_PIN protected
PIN: 27 Y_CS_PIN protected
PIN: 28 X_MIN_PIN protected
. X_STOP_PIN protected
PIN: 29 Z_CS_PIN protected
PIN: 30 <unused/unknown> Input = 1
PIN: 31 E0_CS_PIN protected
PIN: 32 Z_MIN_PIN protected
. Z_STOP_PIN protected
PIN: 33 E1_CS_PIN protected
. Z2_CS_PIN protected
PIN: 34 <unused/unknown> Input = 1
PIN: 35 E2_CS_PIN Input = 1
PIN: 36 Y_MAX_PIN protected
. Y_STOP_PIN protected
PIN: 37 <unused/unknown> Input = 1
PIN: 38 FIL_RUNOUT_PIN Input = 1
PIN: 39 SERVO2_PIN Input = 1
PIN: 40 SERVO3_PIN Input = 1
PIN: 41 BEEPER_PIN Output = 0
PIN: 42 LCD_PINS_RS Output = 1
PIN: 43 LCD_PINS_ENABLE Output = 0
PIN: 44 LCD_PINS_D4 Output = 0
PIN: 45 LCD_PINS_D5 Output = 0
PIN: 46 LCD_PINS_D6 Output = 0
PIN: 47 LCD_PINS_D7 Output = 0
PIN: 48 BTN_ENC Input = 1
PIN: 49 E2_ENABLE_PIN Output = 0
. MAX6675_SS_PIN Output = 0
PIN: 50 BTN_EN1 Input = 1
PIN: 51 E2_STEP_PIN Input = 1
PIN: 52 BTN_EN2 Input = 1
PIN: 53 E2_DIR_PIN Output = 0
PIN: 54 (A 0) TEMP_0_PIN protected
PIN: 55 (A 1) TEMP_1_PIN Analog in = 1023
PIN: 56 (A 2) TEMP_2_PIN Analog in = 1023
PIN: 57 (A 3) TEMP_3_PIN Analog in = 1023
PIN: 58 (A 4) TEMP_BED_PIN protected
PIN: 59 (A 5) TEMP_4_PIN Analog in = 866
PIN: 60 (A 6) E0_DIR_PIN protected
PIN: 61 (A 7) E0_STEP_PIN protected
PIN: 62 (A 8) E0_ENABLE_PIN protected
PIN: 63 (A 9) E1_DIR_PIN protected
. Z2_DIR_PIN protected
PIN: 64 (A10) E1_STEP_PIN protected
. Z2_STEP_PIN protected
PIN: 65 (A11) E1_ENABLE_PIN protected
. Z2_ENABLE_PIN protected
PIN: 66 (A12) <unused/unknown> Input = 1
PIN: 67 (A13) <unused/unknown> Input = 1
PIN: 68 (A14) <unused/unknown> Input = 1
PIN: 69 (A15) <unused/unknown> Input = 1
PIN: 70 (A16) <unused/unknown> Input = 1
PIN: 71 (A17) <unused/unknown> Input = 1
PIN: 72 (A18) <unused/unknown> Input = 1
PIN: 73 (A19) <unused/unknown> Input = 1
PIN: 74 (A20) MISO_PIN Input = 1
PIN: 75 (A21) MOSI_PIN Input = 1
PIN: 76 (A22) SCK_PIN Input = 1
PIN: 77 (A23) <unused/unknown> Input = 1
PIN: 78 (A24) <unused/unknown> Input = 1

[sjasonsmith]

Hi @ShadowOfTheDamn. A change was merged a few days ago which fixed startup delays for some LCD screens. I do not know whether or not it impacts the character LCD you are using.
#19271

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[ShadowOfTheDamn]

I tried the latest bugfix. the issue is still there with my character LCD.
thanks for the information though.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[ShadowOfTheDamn]

The issue is still there with todays bugfix, don't close the issue

[thisiskeithb]

Stale Bot gives you a week to comment on the issue before it's closed after 30 days of inactivity, so please confirm that it's not resolved before then.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[ej0rge]

I think this might be related to the issue i reported some time ago: #13555

I think if you check some unused pins with a volt meter before pressing the reset or connecting via usb, you will find that the pins are high (3.3v) indicating that marlin has not booted yet.

I spent a long time not using my radds controller (or the printer it belongs to) and got back to troubleshooting it today.

I'm using a home-made cable strictly following the schematic of the radds2lcd board, including the 1k resistors.

I hadn't noticed before that the emergency stop (kill) button on the RRD full graphic is now a reset button.

You didn't say whether you're using a radds2lcd board or used your own cable. I should note that the radds2lcd schematic leaves the "kill" wire floating since it has no obvious corresponding pin on the original radds lcd.

So i am wondering if this is a hardware problem or what.

Today i converted to a fysetc mini 12864 v1.2 (no rgb led) and it behaves exactly the same way. I'm using the same cable, just added another section to my pins file.

[ShadowOfTheDamn]

I use a custom PCB. I will send the schematics.
It was working completely ok but then the initialization error occurred and you know the story from then in this thread.

[ej0rge]

Followup to my previous comments.

While digging around for clues with google i came across a post on the repetier forums about the same issue, where one of the repetier devs stated that it's usually a problem of a "wrong size capacitor" or something on clone Arduino DUE boards that doesn't seem to occur on the genuino made-in-italy boards. Something about the clone boards booting too quickly after initial power-up and then immediately crashing.

So i acquired a genuine DUE.

I no longer have to reset my RADDS to get it to boot up properly.

Glancing at the boards, the clone board from china has some open pads that contain components on the genuino board.

[ShadowOfTheDamn]

I dont understand when I did not changed my HW what this could do with my issue. You mean the hardware become faulty?
I will change my board and tell you the results.

[ShadowOfTheDamn]

Adding info, the place you are showing is a place for freq generator not a cap. also the original board is completely different with clones. that is not relevant as I said before. with an original board the results are the same.

[ShadowOfTheDamn]

RESONATOR_EPSON_FC_145
Cristalli
32,768Khz_SMD

https://content.arduino.cc/assets/DUE-reference.zip

[ShadowOfTheDamn]

https://forum.arduino.cc/index.php?topic=256771.msg2512504#msg2512504
answer number 43 explained it. at some time rtarded software developers decided to change the bootloader so the board will boot into bootloader instead of the active program. they have fixed it on the new boards with a 10K resistor and that's why your new board is functioning OK. I am soldering the resistor and will reply soon.

[ej0rge]

Very interesting. My chinese clone Due seems to be the earlier design.

I Wonder what effect the missing crystal has.

The other Due derivative i have here is a Udoo Quad and so far i haven't done anything with it except try to figure out which build of armbian has working network drivers for it.

[sjasonsmith]

So has this turned out to be an issue with some DUE boards missing parts, and not an issue inside Marlin?

[ShadowOfTheDamn]

nope, the issue is due to some ******** bootloader developers of DUE decided to change the bootloader globally regardless of their faulty HW and without considering any difference between the new and old HW revisions. And when you uploaded the marlin firmware the new bootloader is also flashed at that time hence the story you know.

[ShadowOfTheDamn]

Added the SMD 0603 10Kohm resistor and now the system boots correctly in the first time you turn the machine on. no reboot required.
Closing the issue.

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