Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

Why 3 for the servos when I only have one?

Changes made to the config as shown.

This single error might explain the flakey behavior of your system. Let's dig in:

In Configuration.h you have the number of servo's defined as 1 in a statement like this:

#define NUM_SERVOS 1 // Servo index starts with 0 for M280 command

Let's check the data structures in Marlin_main.cpp. At roughly 400 line into the file you will see a declaration:

#if NUM_SERVOS > 0
  Servo servos[NUM_SERVOS];
#endif

This is where storage to manage the servo's happens. You allocated storage for 1 servo. Nothing more! But lets go look how this storage is used. It doesn't matter where you look, but let's check out the engage_z_probe() function as an example:

static void engage_z_probe() {
    // Engage Z Servo endstop if enabled
    #ifdef SERVO_ENDSTOPS
    if (servo_endstops[Z_AXIS] > -1) {
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
        servos[servo_endstops[Z_AXIS]].attach(0);
#endif
        servos[servo_endstops[Z_AXIS]].write(servo_endstop_angles[Z_AXIS * 2]);
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
        delay(PROBE_SERVO_DEACTIVATION_DELAY);
        servos[servo_endstops[Z_AXIS]].detach();
#endif
    }
    #endif
}

Check out the three lines in that function. You can trace them into the C++ code in servos.cpp if like but they write to and use the servos[] array (of size 1). But Z_AXIS is defined as 2 in Marlin.h:

enum AxisEnum {X_AXIS=0, Y_AXIS=1, Z_AXIS=2, E_AXIS=3};

        servos[servo_endstops[Z_AXIS]].attach(0);
        servos[servo_endstops[Z_AXIS]].write(servo_endstop_angles[Z_AXIS * 2]);
        servos[servo_endstops[Z_AXIS]].detach();

By doing this, you are writing (and reading) off the end of the array. This is a VERY bad thing to do because you are clobbering what ever memory is in the wrong spot. Here is the stuff right after the servos[] array:

bool CooldownNoWait = true;
bool target_direction;

This is super bad if this is being allocated next in memory. It is the next thing but it is declared as external so maybe you are not corrupting this. If this gets corrupted, all of the malloc() and free() of memory get sick and do bad things.

extern "C"{
  extern unsigned int __bss_end;
  extern unsigned int __heap_start;
  extern void *__brkval;

  int freeMemory()