Strange behavior after UGS connection

[mvackel]

Hello,
I'm trying the RAMPS 1.4 graphic display fork (here) and got a very strange behavior.
I generated the config files for RAMPS 1.4/Mega using all other defaults and some details (can not set to use "Support for RepRap Full Graphic Display" and must comment the generated line "#undef ENABLE_MAIN_LOOP_MODULES" in cnc_hal_overrides.h).
The display and uCNC seems to work, but after you connect it to UGS (Universal G-code Sender), the display stops working. It freezes in the initial "uCNC" display and never gets to the initial status page.
It doesn't help to upload uCNC again.
After replacing the Mega, it started working again, going to the status page after the usual 4 seconds delay, but after connecting to UGS the display freezes again in the "uCNC". And keeps responding to commands from UGS!
I've tried going back to the Arduino IDE and uploading a simple sketch and everything works fine. Uploading again uCNC keeps the display frozen... now in two Mega boards.

So, maybe there are some information that is beyond the uploaded uCNC memory that are being kept. Any ideas on how to solve this?

[Paciente8159]

I need to investigate the issue. Usually programs like UGS send a soft reset on connect and this is causing some sort of issue.
Thanks for the report.
As soon as I have anything about the issue I'll get back at you.

[Paciente8159]

I'm assuming it's a problem with the files generated by the web build config.
I've used that branch without any override files and UGS and the display work just fine together. I was able to move the controller from both the display and UGS.

Can you send me your config.json file with your settings in the web build?

[mvackel]

Hello,
I've attached the json file - had to change the extension to .txt to upload.
It was build directly by the web build config, just changing the board to "Arduino MEGA/RAMPS 1.4" and keeping all other fields in all pages at the default. After downloading the files (.h and .json) I just commented line 613 (#undef ENABLE_MAIN_LOOP_MODULES) because the compilation issued a warning saying:
"Main loop extensions are not enabled. Graphic display card will not work."

There is another warning when compiling, but I did nothing about it (seems to need attention...):
"External/extension settings storing is disabled"

ucnc_build.txt

[Paciente8159]

If the only change you made was the board, there is no need to use the the generated web builder override files.

You can select the board to compile to by either just selected it from platformIO board select option or in arduino IDE change the board in cnc_config.h

Note that the example branch I provided had all the necessary modifications done by hand. No need to include the override files.

The web build generated files will undo all changes and re-apply the ones based on the interface config... that is the reason you had to comment line 613 (#undef ENABLE_MAIN_LOOP_MODULES).

The web builder as some issues that I'm still trying to resolve. I fixed some issues I've bumped into now.
Check with this file
ucnc_build.txt
Note that I enabled the options for the main loop callbacks (ENABLE_MAIN_LOOP_MODULES) and added the option to load the graphic module.

Download the files like instructed in the last tab of the web builder. You will still need to manually uncomment the u8g2 lib in the platformIO.ini file and comment this line on uCNC/src/hal/boards/avr/avr.ini, since u8g2 depends on these arduino libraries.

[Paciente8159]

One last thing.
The "External/extension settings storing is disabled" warning is just that. A warning. It means you did not enabled ENABLE_SETTINGS_MODULES.

This enables custom modules extensions (some modules have them) and also (in the case of the sd card module) allow for the machine settings to be stored in the flash card that you may have (or not) in the card reader of the smart graphic adapter.

Each module generates warnings if some feature is disabled that may cause the whole or part of the module not to function properlly.

[mvackel]

I tried the new config .json you sent, but I don't know if it's working or not because both Mega boards I have are stuck in the "uCNC" initial logo as before. It seems that something is recorded on the EEPROM or somewhere.
I tried the config using the fork you sent before and also downloaded and built all again from the Github master zip file. Same results: stuck in the "uCNC" logo. Do you think I can revert this by uploading again the bootloader? It's the only part or the memory I know that could hold something that a new script upload doesn't overwrite.
Just to remind, the first Mega was working (going to the status page after ~4 secs), I connected to UGS and it got stuck in the "uCNC" logo. Changed the board to the second Mega and made the upload of the same code and it worked (status page ok). Connected 2nd Mega to UGS and it also got frozen to the "uCNC" logo.
After that both boards never returned to display the status page. No matter what uCNC build is uploaded. Both boards boot and stop on the "uCNC" logo.

[mvackel]

An observation that, maybe, can help: before the issue, the boot time from cold boot to "uCNC" logo display took about 2 seconds. After the problem, it takes about 8 seconds.
Also, I just uploaded a big firmware (Marlin 2.0.9.4) and it worked normally. Uploaded again the uCNC fork that worked before the UGS issue and got the same frozen logo.

[Paciente8159]

Did you tried the precompiled firmware (hex file) I sent you?

[mvackel]

Just tested now. Same thing: it uploads without any error, resets, the display shows "uCNC" "v1.7.4" and freezes.
The command line I used:
avrdude -Cavrdude.conf -v -e -patmega2560 -cwiring "-PCOM6" -b115200 -D "-Uflash:w:C:\tmp4\firmware.hex:i"

[mvackel]

I burned the bootloader again and now the display is working again, passing from the initial logo to the status page (I've flashed the hex file you sent). I will continue the tests tomorrow if I get some time.
Very strange that UGS has changed something in the bootloader area, don't you think? I'll do more tests now that I can recover the Mega.

[Paciente8159]

So the second time you flashed it started working? That is odd.
You can try using XLoader to write the firmware.

XLoader.zip

[mvackel]

I was not able to duplicate what happened in my two Mega boards that was causing the issue. Anyway, I'm making some progress.

I followed the script below and it seems to be working (This is just for reference for some other user):
(I have other issues about limit switches, but will open another question)

• Unzip uCNC-master.zip

• Copy graphic module (last version: 1.7.0 (from Paciente8159/uCNC-modules) (folder name: graphic_display)
  to the folder uCNC/src/modules

• Comment line 14 - file: uCNC/src/hal/boards/avr/avr.ini:
  lib_ignore = EEPROM, SPI, Wire

• Open main folder in VSCODE (that contains file platformio.ini)

• Uncomment line 36 - file platformio.ini:
  ; lib_deps = olikraus/U8g2

• Modify Platformio default Environment: (This is important! Or it will make MANY downloads)
  click in the inferior barr, where there is the env: "Default (uCNC-1.7.4-Gr)" (or something similar)
  and SELECT:
  env.ramps14

• COPY the files built using web config:
  boardmap_overrides.h
  cnc_hal_overrides.h

• Compile and upload

[Paciente8159]

I will try to modify the source code and web builder to also take the graphic display case in consideration.
Thanks