search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.23k stars 19.22k forks source link

Development branch corrupts bootloader and SD. #2483

Closed JTrantow closed 9 years ago

JTrantow commented 9 years ago

Yesterday, I decided to upgrade my printer with dual Y drives. I grabbed the latest Development branch and made the following changes to match my printer.

Configuration.h

#define STRING_CONFIG_H_AUTHOR "(JJT, MakerSlide Cube)" // Who made the changes.
#define CUSTOM_MACHINE_NAME "JJT MakerSlide"
#define TEMP_SENSOR_1 -1
#define DISABLE_MAX_ENDSTOPS
#define DISABLE_MIN_ENDSTOPS
#define DISABLE_Z_PROBE_ENDSTOP
#define DISABLE_X true
#define DISABLE_Y true
#define DISABLE_Z true
#define X_MAX_POS 112
#define Y_MAX_POS 257
#define DEFAULT_AXIS_STEPS_PER_UNIT   {87.15,87.73,800.0,100.0} 
#define DEFAULT_MAX_FEEDRATE          {300, 300, 100, 25}    // (mm/sec)
#define DEFAULT_MAX_ACCELERATION      {100,100,100,1000}   
#define REPRAP_DISCOUNT_SMART_CONTROLLER

Configuration_adv.h

#define Y_DUAL_STEPPER_DRIVERS

I compiled and uploaded several times as I carried values over from my old configuration. I think the last changes were the DISABLEs? Unfortunately the change causes Marlin to trash the bootloader. I'm not sure how and note I had done several builds without problem before getting AVRDude errors. After checking all the usual suspects I tried loading the LED blink sketch which gave the same error. So I pulled out another Mega and did a successful load of the LED blink followed by an unsuccessful load of Marlin which trashed the bootloader and LED blink no longer loads. So now I have two Megas with corrupt bootloaders. I will break out my Dragon and restore the bootloader, but something is definitely hosed with the Development branch with this configuration. I'm betting on the DISABLE area??? I have a screw on my Z so I don't mind turning it off. I was going to evaluate the changes between XY disabled or not when

I still have the last successful load of Marlin running on the printer. I thought I could get by with this, but I have experienced several lockups midway through printing. Two of the stop printing failures were from the SD card and the second failure also corrupted the SD card. Windows couldn't figure out the reformat size so I needed to run the SanDisk SDFormat utility.

pdbogen commented 9 years ago

When you build with the indicated configuration, what's the ultimate code size?

JTrantow commented 9 years ago

I believe this hex file is the one that corrupted the loader.

Sketch uses 94,828 bytes (37%) of program storage space. Maximum is 253,952 bytes. Global variables use 4,343 bytes (53%) of dynamic memory, leaving 3,849 bytes for local variables. Maximum is 8,192 bytes. D:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CD:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega2560 -cwiring -PCOM11 -b115200 -D -Uflash:w:C:\Users\Jerry\AppData\Local\Temp\build2854557477579937906.tmp/Marlin.cpp.hex:i

Marlin.cpp.hex (266,750 bytes)

On Tue, Jul 21, 2015 at 11:18 AM, Patrick Bogen notifications@github.com wrote:

When you build with the indicated configuration, what's the ultimate code size?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2483#issuecomment-123390257 .

pdbogen commented 9 years ago

Can you attach the .hex file here? A 266kb Intel hex file could conceivably contain 260kb of data bytes, which would overflow the flash on the AVR and thus blow away the bootloader (as I understand these things.) That should be unlikely, though, so I'd like to verify.

Otherwise, there are only three possibilities I'm aware of:

It's also possible that what you think is a wrecked bootloader is actually something else. Some possibilities:

JTrantow commented 9 years ago

What's the best way to attach the .hex? GitHub stripped the file from previous email response.

I don't think this is a FTDI driver issue, Mega still shows up as COM port in Device Manager. It just won't Upload anymore. (even with LED sketch).

I don't think the .hex file is too big. .hex is saved as ascii with two bytes per byte of data plus overhead. Sketch output says only 37% program and 53% dynamic.

The fact that the same hex file corrupted two megas back to back points to a software problem with the specific options. One corruption was a full printer, the other was a bare mega powered via usb.

I will try to reflash the bootloader tonight, but I'm also crammed with real work.

pdbogen commented 9 years ago

Ah yeah, forgot to halve it on my math. There's some cruft, but it's as little as 6 bytes per 255 bytes of data, but that still only works out to worst-case around 130k.

Since the .hex is ASCII, perhaps upload it to pastebin; you're right that it's unlikely to be the cause, but I might try flashing it to a mega2560 at home to see if I can reproduce the issue.

It might be useful if you can figure out exactly which config option is causing the corruption; it would be laborious, but you could disable them one at a time, flash, and observe if the bootloader is/isn't broken.

JTrantow commented 9 years ago

Yes, I will do that when I find time to dig out the programmer. What's burned in has the DUAL_Y and endstops working, so I'm pretty sure it crashed when I started disabling motors between moves.

On Tue, Jul 21, 2015 at 2:39 PM, Patrick Bogen notifications@github.com wrote:

Ah yeah, forgot to halve it on my math. There's some cruft, but it's as little as 6 bytes per 255 bytes of data, but that still only works out to worst-case around 130k.

Since the .hex is ASCII, perhaps upload it to pastebin; you're right that it's unlikely to be the cause, but I might try flashing it to a mega2560 at home to see if I can reproduce the issue.

It might be useful if you can figure out exactly which config option is causing the corruption; it would be laborious, but you could disable them one at a time, flash, and observe if the bootloader is/isn't broken.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2483#issuecomment-123456905 .

pdbogen commented 9 years ago

Do you have a custom #define MOTHERBOARD? How about any of the _IS_TMC or _IS_L6470? (i.e., Y2_IS_TMC, Y2_IS_L6470)?

JTrantow commented 9 years ago

I did not explicitly define MOTHERBOARD which should default to

define MOTHERBOARD BOARD_RAMPS_13_EFB

I did define:

define REPRAP_DISCOUNT_SMART_CONTROLLER

Board Manager selection is "Arduino Mega or Mega 2560"

I found my Dragon and used Atmel Studio to reprogram the 2560 bootloader which restored proper operation.

I used the Arduino IDE to upload Marlin dev branch with (DISABLE_X Y Z false) with no problems. (full printer connected) Then for grins, I set the DISABLEs true and corrupted the bootloader again. So this is a software problem in at least the development branch when motors are disabled.

On Tue, Jul 21, 2015 at 4:43 PM, Patrick Bogen notifications@github.com wrote:

Do you have a custom #define MOTHERBOARD? How about any of the _IS_TMC or _IS_L6470? (i.e., Y2_IS_TMC, Y2_IS_L6470)?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2483#issuecomment-123485693 .

JTrantow commented 9 years ago

I reverted back to the dev branch and added my changes one at a time. I made it back to the version I was sure would corrupt the loader without any problems??? This was on a bare Mega2560 connected only to USB.

I also loaded this onto the full printer without any problems.

Not sure what to conclude, with minimal Configuration.h and Configuration_adv.h I corrupted the Mega2560 three times on two different days. Corrupted meaning the Arduino IDE would no longer communicate to load any sketch. This could be a corrupted boot loader or Marlin not resetting into the bootloader? Wiping the flash and reprogramming the bootloader restored proper operation.

Using But "same" code (verified by diff) is now working so I will close this.

github-actions[bot] commented 2 years ago

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.