Marlin: Reboot after print selection via LCD or OctoPi

[cryptelli]

Hi Guys,

This isn't my first rodeo, as I've successfully flashed the firmware for my printer numerous times in the past starting with RC3 to RC6 and then RC8 to RCBugFix (1.0.1 branch) which is what I've been running for the last few weeks.

After seeing that Marlin 1.1.0 (great work team!) was released I decided to upgrade as it would no doubt have a bunch of stuff added since I updated, so after a quick migration of my config it was uploaded.

This is where things went downhill, after the first reboot from the upgrade and the second from the connection to OctoPi I selected a print, and was surprised to see the bot in a reboot loop. In an effort to troubleshoot the problem I decided to try printing from the SD card alone, same problem...

Went back into my configuration and checked everything was present and correct, realised I had a double entry for the hotend PID tuning, after commenting out the default for my own calibration i'd previously run I re-uploaded and checked, same problem.

Problem is non existent if I flash the printer back to my patched RCBugFix.

Advise?

[VanessaE]

I'm seeing the same problem here, and I don't have an LCD nor do I use Octo-anything (just Printrun).

[NiklasOlofsson]

Also having a "boot loop" with the latest RCBugFix when I am connected using Octoprint. Not connected, it stays on but as soon as I connect to the printer, the boot loop starts.

[bgort]

I'm seeing this problem also -- same here, when connected via serial (octoprint) it restarts. Will do some digging around shortly.

[cryptelli]

Didn't think I was mad! Thanks for adding your experiences people. Hopefully those whom know the workings better than I do will be able to get to the bottom of this issue.

[bgort]

241bdffe65ea4ef8c776bc68b75a77c07cb7e3bf works for me, while 2658cc707ad03600c364cafb7adbfa6261c3f577 does not. So our problem is in 2658cc707ad03600c364cafb7adbfa6261c3f577 or 1b2c7ec20a23af57da50dafa672283ff09bbaf51.

Unfortunately nothing stands out yet, but still looking.

[Neverther]

Same issue, worked on RCBUGFIX
Connecting via octoprint on bufix-1.1.x r8299:

Connecting to: /dev/ttyUSB0
Changing monitoring state from 'Offline' to 'Opening serial port'
Connected to: Serial(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: N0 M110 N0125
Recv: ok
Changing monitoring state from 'Connecting' to 'Operational'
Send: N0 M110 N0125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Marlin bugfix-1.1.x (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:CoreXY EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: ok
Send: M21
Recv: echo:SD init fail
Recv: ok
Send: M117 IP 192.168.0.101
Recv: ok
Send: M105
Recv: ok T:start
Send: M105
Recv: echo:Marlin bugfix-1.1.x
Recv:
Recv: echo: Last Updated: 2017-05-04 12:00 | Author: Never, CoreXY
Recv: Compiled: May 4 2017
Recv: echo: Free Memory: 3538 PlannerBufferBytes: 1232
Recv: echo:V37 stored settings retrieved (453 bytes)
Recv: echo: G21 ; Units in mm
Recv:
Recv:
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D3.00
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z2560.00 E500.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X300.00 Y300.00 Z2.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000 Y3000 Z100 E10000
Recv: echo:Acceleration (units/s2): P R T
Recv: echo: M204 P3000.00 R3000.00 T3000.00
Recv: echo:Advanced: S T B X Z E
Recv: echo: M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Auto Bed Leveling:
Recv: echo: M420 S0 Z0.00
Recv: echo:Material heatup parameters:
Recv: echo: M145 S0 H180 B70 F0
Recv: M145 S1 H240 B110 F0
Recv: echo:PID settings:
Recv: echo: M301 P22.20 I1.08 D114.00
Recv: echo:Z-Probe Offset (mm):
Recv: echo: M851 Z0.00
Recv: echo:SD init fail
Recv: ok T:start
Send: M105
Recv: echo:Marlin bugfix-1.1.x
Recv:
Recv: echo: Last Updated: 2017-05-04 12:00 | Author: Never, CoreXY
Recv: Compiled: May 4 2017
Recv: echo: Free Memory: 3538 PlannerBufferBytes: 1232
Recv: echo:V37 stored settings retrieved (453 bytes)
Recv: echo: G21 ; Units in mm
Recv:
Recv:
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D3.00
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z2560.00 E500.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X300.00 Y300.00 Z2.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000 Y3000 Z100 E10000
Recv: echo:Acceleration (units/s2): P R T
Recv: echo: M204 P3000.00 R3000.00 T3000.00
Recv: echo:Advanced: S T B X Z E
Recv: echo: M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Recv: echo:Auto Bed Leveling:
Recv: echo: M420 S0 Z0.00
Recv: echo:Material heatup parameters:
Recv: echo: M145 S0 H180 B70 F0
Recv: M145 S1 H240 B110 F0
Recv: echo:PID settings:
Recv: echo: M301 P22.20 I1.08 D114.00
Recv: echo:Z-Probe Offset (mm):
Recv: echo: M851 Z0.00
Recv: echo:SD init fail
Recv: ok T:start
Send: M105
Recv: echo:Marlin bugfix-1.1.x
Recv:
Recv: echo: Last Updated: 2017-05-04 12:00 | Author: Never, CoreXY
Recv: Compiled: May 4 2017
Recv: echo: Free Memory: 3538 PlannerBufferBytes: 1232
Recv: echo:V37 stored settings retrieved (453 bytes)
Recv: echo: G21 ; Units in mm
Recv:
Recv:
Recv: echo:Filament settings: Disabled
Recv: echo: M200 D3.00
Recv: echo: M200 D0
Recv: echo:Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z2560.00 E500.00
Recv: echo:Maximum feedrates (units/s):
Recv: echo: M203 X300.00 Y300.00 Z2.00 E25.00
Recv: echo:Maximum Acceleration (units/s2):
Recv: echo: M201 X3000 Y3000 Z100 E10000
Recv: echo:Acceleration (units/s2): P R T
Recv: echo: M204 P3000.00 R3000.00 T3000.00
Recv: echo:Advanced: S T B X Z E
Recv: echo: M205 S0.00 T0.00 B20000 X20.00 Y20.00 Z0.40 E5.00
Recv: echo:Home offset:
Recv: echo: M206 X0.00 Y0.00 Z0.00
Connection closed, closing down monitor
Changing monitoring state from 'Operational' to 'Offline'.

Condesed diff:

Configuration.h
-#define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes.
+#define STRING_CONFIG_H_AUTHOR "Never, CoreXY" // Who made the changes.

-#define BAUDRATE 250000
+#define BAUDRATE 115200

-//#define CUSTOM_MACHINE_NAME "3D Printer"
+#define CUSTOM_MACHINE_NAME "CoreXY"
-#define TEMP_SENSOR_BED 0
+#define TEMP_SENSOR_BED 1

-#define TEMP_RESIDENCY_TIME 10 // (seconds)
+#define TEMP_RESIDENCY_TIME 5 // (seconds)
-#define TEMP_WINDOW 1 // (degC) Window around target to start the residency timer x degC early.
+#define TEMP_WINDOW 6 // (degC) Window around target to start the residency timer x degC early.
-#define TEMP_BED_RESIDENCY_TIME 10 // (seconds)
+#define TEMP_BED_RESIDENCY_TIME 5 // (seconds)
-#define TEMP_BED_WINDOW 1 // (degC) Window around target to start the residency timer x degC early.
+#define TEMP_BED_WINDOW 6 // (degC) Window around target to start the residency timer x degC early.
-//#define COREXY
+#define COREXY
-#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 4000, 500 }
+#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 2560, 500 }
-#define DEFAULT_MAX_FEEDRATE { 300, 300, 5, 25 }
+#define DEFAULT_MAX_FEEDRATE { 300, 300, 2, 25 }
-//#define FIX_MOUNTED_PROBE
+#define FIX_MOUNTED_PROBE
-#define X_PROBE_OFFSET_FROM_EXTRUDER 10 // X offset: -left +right [of the nozzle]
-#define Y_PROBE_OFFSET_FROM_EXTRUDER 10 // Y offset: -front +behind [the nozzle]
+#define X_PROBE_OFFSET_FROM_EXTRUDER 0 // X offset: -left +right [of the nozzle]
+#define Y_PROBE_OFFSET_FROM_EXTRUDER 0 // Y offset: -front +behind [the nozzle]

-#define Z_CLEARANCE_DEPLOY_PROBE 10 // Z Clearance for Deploy/Stow
-#define Z_CLEARANCE_BETWEEN_PROBES 5 // Z Clearance between probe points
+#define Z_CLEARANCE_DEPLOY_PROBE 0 // Z Clearance for Deploy/Stow
+#define Z_CLEARANCE_BETWEEN_PROBES 4 // Z Clearance between probe points

-#define INVERT_X_DIR false
-#define INVERT_Y_DIR true
+#define INVERT_X_DIR true
+#define INVERT_Y_DIR false

-#define INVERT_E0_DIR false
+#define INVERT_E0_DIR true

-#define Y_MIN_POS 0
+#define Y_MIN_POS -58
-#define X_MAX_POS 200
+#define X_MAX_POS 290
-#define Z_MAX_POS 200
+#define Z_MAX_POS 230

-//#define AUTO_BED_LEVELING_BILINEAR
+#define AUTO_BED_LEVELING_BILINEAR

-#define LEFT_PROBE_BED_POSITION 15
-#define RIGHT_PROBE_BED_POSITION 170
-#define FRONT_PROBE_BED_POSITION 20
-#define BACK_PROBE_BED_POSITION 170
+#define LEFT_PROBE_BED_POSITION 5
+#define RIGHT_PROBE_BED_POSITION 235
+#define FRONT_PROBE_BED_POSITION 5
+#define BACK_PROBE_BED_POSITION 195

-//#define PROBE_Y_FIRST
+#define PROBE_Y_FIRST

-//#define EXTRAPOLATE_BEYOND_GRID
+#define EXTRAPOLATE_BEYOND_GRID

-//#define Z_SAFE_HOMING
+#define Z_SAFE_HOMING

-//#define EEPROM_SETTINGS
+#define EEPROM_SETTINGS

-//#define NOZZLE_PARK_FEATURE
+#define NOZZLE_PARK_FEATURE

-//#define ULTRA_LCD // Character based
+#define ULTRA_LCD // Character based

-//#define SDSUPPORT
+#define SDSUPPORT

-//#define SD_CHECK_AND_RETRY
+#define SD_CHECK_AND_RETRY

-//#define ENCODER_PULSES_PER_STEP 1
+#define ENCODER_PULSES_PER_STEP 4

-//#define ENCODER_STEPS_PER_MENU_ITEM 5
+#define ENCODER_STEPS_PER_MENU_ITEM 1

-//
-//#define REVERSE_ENCODER_DIRECTION
+#define REVERSE_ENCODER_DIRECTION
+

-//#define REVERSE_MENU_DIRECTION
+#define REVERSE_MENU_DIRECTION

-//#define INDIVIDUAL_AXIS_HOMING_MENU
+#define INDIVIDUAL_AXIS_HOMING_MENU

-//#define SPEAKER
+#define SPEAKER

-//#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100
+#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 50

-//#define REPRAP_DISCOUNT_SMART_CONTROLLER
+#define REPRAP_DISCOUNT_SMART_CONTROLLER

Configuration_adv.h:
-//#define BABYSTEPPING
+#define BABYSTEPPING

-//#define DOUBLECLICK_FOR_Z_BABYSTEPPING // Double-click on the Status Screen for Z Babystepping.
+#define DOUBLECLICK_FOR_Z_BABYSTEPPING // Double-click on the Status Screen for Z Babystepping.

-//#define FILAMENT_CHANGE_FEATURE
+#define FILAMENT_CHANGE_FEATURE

Put heated bed to heat up, tried connecting octoprint and during the marlin reboot the heatbed mosfet was put into half state and started cooking itself...nice.

[colinrgodsey]

Same issue. Worked with RCBUGFIX, not with 1.1.x. Not getting anything useful out of the serial logs...

MKS Base 1.4
Endstop interrupts
LIN_ADVANCE
BLTouch

[colinrgodsey]

Might be a long shot, but looking over the differences in the changes mentioned above:

https://github.com/MarlinFirmware/Marlin/compare/241bdffe65ea4ef8c776bc68b75a77c07cb7e3bf...2658cc707ad03600c364cafb7adbfa6261c3f577

There doesnt seem to be anything related to SD or whatnot, but there does seem be a shift from using floating point to ints in a few places. I know normally in C you'll get a NaN for divide by zero for floating point, but you'll get a segfault if you do an integer divide by 0.

Not that familiar with Arduino/Atmega... but it sounds like it could be a possibility. Going to fiddle around and see...

[bgort]

Yeah..nothing really stands out at all, but that could be it. Don't think this has anything to do with SD, as I don't even have SD support enabled.

I did find a few ampersands where they didn't belong (in the arguments to setTargetHotend and setTargetBed, particularly), and a few other little things, but fixing them didn't resolve the issue.

Have a few calls, an errand, etc., so am going to have to push this for a bit, unfortunately.

[bgort]

Saw a fair bit of implicit casting that might possibly be causing a problem, too, but haven't yet looked into that. Maybe something to consider as you fiddle.

[colinrgodsey]

@bgort cool, ill keep an eye out

[BillyBob54]

This, or at least a related issue, may go further back, see #6128; I have not had a chance to load up 1.1.0 and try.

[colinrgodsey]

Looks like m105 is causing the crash causes a crash:

Send: M105
Recv: ok T:start

You get "T:" then immediately just get the 'start' from the reboot.

[bgort]

Mine isn't getting that far:

Send: N0 M110 N0*125
Recv: start

EDIT: Actually, mine is doing that, sometimes:

2017-05-04 14:33:46,861 - Send: M105
2017-05-04 14:33:52,059 - Recv: ok T:

This is only showing up in the octoprint serial log..because I have M105 suppressed! This narrows things down considerably.

[Grogyan]

This may be due to the on board 5V regulator, or polyfuse, going into
thermal shutdown.
If you have a DMM, you can measure the 5V rail to see if it does drop out

[colinrgodsey]

found it! Ultimately I think the SERIAL_PROTOCOL_F function was not handling the new uint16_t values correctly. I switched some of the inline methods in temperatures.h back to float/int and things work fine. Going to clean things up a bit and narrow down the changes to just the core.

temperature.h

EDIT: Erm, the diff didnt copy-paste right.. just image theres ++ and -- in there

   static int16_t degHotend(uint8_t e) {
    static float degHotend(uint8_t e) {
      #if HOTENDS == 1
        UNUSED(e);
      #endif
      return current_temperature[HOTEND_INDEX];
    }
    static int16_t degBed() { return current_temperature_bed; }
    static float degBed() { return current_temperature_bed; }

    #if ENABLED(SHOW_TEMP_ADC_VALUES)
      static int16_t rawHotendTemp(uint8_t e) {
      static int rawHotendTemp(uint8_t e) {
        #if HOTENDS == 1
          UNUSED(e);
        #endif
        return current_temperature_raw[HOTEND_INDEX];
      }
      static int16_t rawBedTemp() { return current_temperature_bed_raw; }
      static int rawBedTemp() { return current_temperature_bed_raw; }
    #endif

    static int16_t degTargetHotend(uint8_t e) {
    static int degTargetHotend(uint8_t e) {
      #if HOTENDS == 1
        UNUSED(e);
      #endif
      return target_temperature[HOTEND_INDEX];
    }
    static int16_t degTargetBed() { return target_temperature_bed; }
    static int degTargetBed() { return target_temperature_bed; }

Changing monitoring state from 'Connecting' to 'Operational'
Send: N0 M110 N0*125
Recv: ok
Send: M105
Recv: ok T:19.5 /0 B:19.6 /0 @:0 B@:0
Send: M105

[bgort]

That's funny! Just realized that myself and compiling to test an int instead of uint16_t in the output....

[Roxy-3D]

There was a similar problem when char's where turned into int8_t types. The SERIAL_ECHO() macro passed them to myserial.serial() and the wrong thing happened. If I remember right, instead of printing characters, numbers came out.

[ghost]

@colinrgodsey's changes fixed the rebooting issue for me. Don't know if it has possible side-effects?

[colinrgodsey]

@Hertog99 well, technically can't be sure of the quality of the original build, couldnt run it ;) so not sure. buyer beware!

[Roxy-3D]

found it! Ultimately I think the SERIAL_PROTOCOL_F function was not handling the new uint16_t values correctly. I switched some of the inline methods in temperatures.h back to float/int and things work fine. Going to clean things up a bit and narrow down the changes to just the core.

The changes from float to int were made to help the migration to 32-bit processors. There was a problem found a few days ago where float operations done at interrupt time caused the processor to crash. double operations were allowed because they are done in software. But the float operations happen inside the floating point unit and nothing can touch that while servicing an interrupt.

It probably would be best to not switch back to float. Perhaps changing from SERIAL_PROTOCOL_F() to just SERIAL_PROTOCOL() would make sense?

[ghost]

Just tried a print, bed won't heath up when sending print via octoprint, also, I heard my BLTouch click, guess it did a reboot. (Jup, just checked, sending a print via Octoprint/Octopi causes the printer to reboot) Some more digging is needed.

[bgort]

Suspect we need to fix the actual underlying issue, likely in MarlinSerial::printNumber(), or thereabouts.

[Roxy-3D]

Suspect we need to fix the actual underlying issue, likely in MarlinSerial::printNumber()

Yeah... But for sure... It isn't valid to be calling as SERIAL_PROTOCOL_F((int),(int)). Won't changing to a SERIAL_PROTOCOL() be just fine? It will print an integer just fine....

[bgort]

Oh -- you're absolutely right. Trying that now.

[bgort]

Yep -- fixed it. Wonder where else that's done, though.

Will scour the changes and put together a PR momentarily.

[colinrgodsey]

@Roxy-3D wow, thats brutal about the interrupt space stuff lol

ill revert my stuff and just try switching some of the APIs over to SERIAL_PROTOCOL. See if I can find any other that explode

[colinrgodsey]

Is there some issue with the method overloads on MYSERIAL.print? Floats work fine, even tho theres only an overload for double, so not sure why uint_16t wouldnt be implicitly upcast to int.

This just some compiler oddity?

[bgort]

No, it's as simple as SERIAL_PROTOCOL_F being for floats, while SERIAL_PROTOCOL is for everything else. I totally missed that when I looked at the macro and associated function.

[Roxy-3D]

even tho there's only an overload for double, so not sure why uint_16t wouldnt be implicitly upcast to int.

Well... I bet we are missing the overloaded function definition for uint_16t. (But I haven't looked.)

[bgort]

We are, and I tried to add it, but the compiler wouldn't allow it. uint16_t = int, so it's not a valid overload.

[bgort]

Actually, I think what was happening is that because the first argument wasn't a float, it was calling print(int, 1) .. where 1 is the base of the number.... And obviously that isn't going to work.

[Roxy-3D]

uint16_t = int

Well... That doesn't make sense. The two are not the same. There must be something we are missing??? You must be able to have a declaration for

void func(int);
and
void func(unsigned);

That would only make sense?????

Actually, I think what was happening is that because the first argument wasn't a float, it was calling print(int, 1) .. where 1 is the base of the number.... And obviously that isn't going to work.

Ah!!!! Yes... You are right!

[bgort]

Sorry - I meant int16_t = int. I blame my fingers...

[colinrgodsey]

Getting a bit off topic here but... doesn't it kind of suck that we're not getting fractional temperatures now?

    static int16_t degHotend(uint8_t e) {
      #if HOTENDS == 1
        UNUSED(e);
      #endif
      return current_temperature[HOTEND_INDEX];
    }

current_temperature is a still a float, why are we removing the fractions? does this just effect the serial API?

EDIT: and aren't any cycle-saving efforts wasted by just having to convert the float to int16_t on every reference? my octoprint temperatures graph looks really boring now too.

[houseofbugs]

I tried the fix in here and that did not change anything. I am having this issue on a Melzi and MKS boards.

Replicated using SD and USB. Both caused a reset.

[bgort]

@houseofbugs: Did you pull down the latest bugfix-1.1.x? ae7c602

[VanessaE]

I haven't tried @bgort's / @Roxy-3D's changes yet, but if that works,

The patch works for me. I would highly recommend issuing a new "hotfix" release tagged 1.1.1 (or 1.1.0.1?) ASAP, unless there's more to do.

[cryptelli]

I can also confirm that the patch works, nice work team and I agree with @VanessaE, this seems to be a widespread issue which shouldn't be present in 1.1.0.

Also, the temperature graph isn't as granular like @colinrgodsey pointed out, any idea if that is going to be how it is moving forward or can we can back to having fractional numbers?