this is esp32 s3 code for production steppers moto...

Completed and tested the corrected sketch:

Download the fixed ESP32-S3 stepper code

Review the changes as a diff

Main corrections

• Fixed the compile error in the mmPerStep calculation.
• Motor EN is now active only while moving or homing.
• EN switches off immediately after:
  • Reaching the target.
  • Reaching the home switch.
  • Completing startup homing.
  • A fault or safety stop.
  • Receiving a command for the current position.
• Shared OBJ/CAR EN pin remains enabled until both motors finish.
• Limit switches are checked:
  • Before starting MOVE, GOTO, or direct movement functions.
  • Continuously while moving toward home.
  • No additional step is generated when the switch is detected.
  • Moving away from a pressed switch remains allowed so the mechanism can release it.
• Added safer commands:
  • MOVE CAR +
  • MOVE CAR -
  • MOVE CAR + 25
  • MOVE CAR -7.5
  • GOTO CAR 40
• Both SLD and SDL are accepted.
• Each axis now has an independent DIR polarity setting:

cpp
static constexpr uint8_t CAM_POSITIVE_DIR_LEVEL = HIGH;
static constexpr uint8_t REL_POSITIVE_DIR_LEVEL = HIGH;
static constexpr uint8_t OBJ_POSITIVE_DIR_LEVEL = HIGH;
static constexpr uint8_t SLD_POSITIVE_DIR_LEVEL = HIGH;
static constexpr uint8_t CAR_POSITIVE_DIR_LEVEL = HIGH;

When one motor moves backward, change only that motor from HIGH to LOW.

The code passed syntax compilation and simulated tests for command parsing, opposite DIR levels, limit stopping, idle EN shutdown, startup behavior, and the shared OBJ/CAR enable.

Important production hardware warning

GPIO0 and GPIO46 are ESP32-S3 boot-strapping pins. Espressif documents GPIO0 with a default weak pull-up and GPIO46 with a default weak pull-down. Because CAM EN is active-low on GPIO46, the CAM driver could briefly become enabled during reset before firmware can disable it. Moving GPIO0 and GPIO46 signals to ordinary GPIOs is strongly recommended for production hardware. (Espressif Systems)

The remaining required check is physical: verify that MOVE <axis> + moves away from that axis’s home switch. If not, invert that axis’s *_POSITIVE_DIR_LEVEL constant.

Updated production version:

Download stepper_motors2_production.ino

View the changes

Corrections

• No motors move automatically after boot or serial-monitor reset.
• MOVE REL + and MOVE REL - now produce opposite electrical DIR levels:
  • MOVE REL + → DIR GPIO11=LOW
  • MOVE REL - → DIR GPIO11=HIGH
• Only the commanded motor moves.
• Added individual homing:
  • HOME REL homes REL only.
  • HOME CAR homes CAR only.
  • HOME ALL homes all motors.
• When a home switch is already pressed:
  1. Motor moves away until the switch opens.
  2. Motor continues another 3 mm.
  3. Motor reverses and approaches the switch again.
• REL and CAR direction polarity was reversed because the reported release faults showed those axes were using the wrong away-from-switch direction.
• EN remains active only during movement or homing and switches off when finished.
• Limit switches stop movement toward home immediately.
• Serial now shows the selected motor, movement direction, actual DIR GPIO level, starting position, and target position.
• Added safer fatal-error handling to avoid continuous watchdog resets.
• Motion timing was tested through micros() rollover for continuous operation.

Example output:

text
MOVE REL +10.000 mm | DIR GPIO11=LOW | from 50.000 to 60.000 mm
REL: target reached at 60.000 mm.

MOVE REL -10.000 mm | DIR GPIO11=HIGH | from 60.000 to 50.000 mm
REL: target reached at 50.000 mm.

The ESP-ROM boot lines are generated by the ESP32-S3 ROM and will still appear after a reset. The important change is that the firmware performs no automatic movement afterward.

On a fresh startup, use HOME REL before moving REL unless its limit switch is already pressed. If Serial reports GPIO11 changing between HIGH and LOW but the motor still physically turns in one direction, the remaining problem is the DIR wiring, driver DIR input, or driver configuration rather than the command parser.

The repeated banner is a real ESP32 reset, not normal command output. rst:0x1 (POWERON) is printed by the ESP32-S3 ROM before your sketch starts, so MOVE REL + is not intentionally calling setup() again. (Espressif Systems)

Updated code

Download stepper_motors2_production_v3.ino

View the V3 changes

Changes include:

• setup() now calls All_Steppers_Default().
• Startup homes all motors sequentially, not simultaneously.
• Only one motor EN is active during startup homing.
• Each motor EN switches off before the next motor starts.
• A 100 ms power-settling interval is used between axes.
• Driver enable settling increased from 1 ms to 5 ms.
• MOVE REL + still operates only REL.
• MOVE REL - uses the opposite DIR level.
• No ESP.restart(), software reset, abort, or watchdog-reset command exists in the sketch.
• The code passed syntax checking and a simulation verifying:
  • Startup calls All_Steppers_Default().
  • All axes home one by one.
  • MOVE REL + moves only REL.
  • MOVE REL - uses the opposite DIR signal.
  • REL EN switches off after movement.

Why it resets

Because startup homing is now required, every hardware reset will automatically start All_Steppers_Default() again. That is why it may look as though the MOVE command started all motors.

Use this test to identify the actual reset source:

Test 1: Serial auto-reset

Disconnect motor power completely but leave USB connected, then send:

text
MOVE REL +

If the ESP32 still resets, your serial program is probably closing/reopening the port or toggling DTR/RTS. ESP32 development boards commonly connect those control signals to GPIO0 and CHIP_PU/EN for automatic reset. Disable options such as:

text
Toggle DTR
Toggle RTS
Reset on connect
Reopen port after send
Auto reset

This is especially likely if the reset occurs before REL makes any sound. (Espressif Systems)

Test 2: REL driver/power problem

If it resets only with motor power connected:

1. Disconnect the REL motor-driver EN wire from GPIO13.
2. Send MOVE REL +.
3. If it no longer resets, enabling the REL driver is causing a power drop or electrical-noise problem.
4. Reconnect EN but disconnect the REL motor coils.
5. Test again.

If the driver or motor causes the reset, check:

• ESP32 and motor driver must have a reliable common ground.
• Do not power the stepper motor from the ESP32 5 V or 3.3 V rail.
• Prefer separate motor and controller supplies with a star-ground connection.
• Verify that no driver input is pulling an ESP32 GPIO above 3.3 V.
• Measure ESP32 3.3 V and CHIP_PU/EN while enabling REL.
• Add proper local decoupling and bulk capacitance near the ESP32 supply input.

Espressif specifies a 3.0–3.6 V operating range for ESP32-S3 supply rails and warns that sudden current demand can collapse the rail. Its hardware guidelines recommend local 0.1 µF decoupling and approximately 10 µF at the main 3.3 V power entrance. (Espressif Systems)

A useful practical distinction is:

• Reset before motor click: serial DTR/RTS or CHIP_PU wiring.
• Reset when motor clicks or EN activates: power supply, grounding, driver wiring, or motor noise.