Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: ESP32 crashes while I add motor1 section for any axe #630

Closed
3 tasks
ereenke opened this issue Sep 25, 2022 · 7 comments
Closed
3 tasks

Problem: ESP32 crashes while I add motor1 section for any axe #630

ereenke opened this issue Sep 25, 2022 · 7 comments

Comments

@ereenke
Copy link

ereenke commented Sep 25, 2022

Controller Board

Grbl ESP32 MPCNC Controller

Help From Board Vendor

  • Yes
  • No
  • Not Applicable

Machine Description

Input Circuits

No response

Configuration file

name: "MPCNC"
board: "GRBL ESP32 Controller"

kinematics:
  Cartesian:

stepping:
  engine: RMT
  idle_ms: 255
  pulse_us: 4
  dir_delay_us: 0
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: gpio.13
  x:
    steps_per_mm: 100
    max_rate_mm_per_min: 5000
    acceleration_mm_per_sec2: 400
    max_travel_mm: 800
    soft_limits: false
    homing:
      cycle: 2
      positive_direction: false
      mpos_mm: 0
      feed_mm_per_min: 400
      seek_mm_per_min: 2000
    motor0:
      limit_all_pin: gpio.15:low
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        direction_pin: gpio.26
        step_pin: gpio.12
    motor1:
      limit_all_pin: gpio.36:low
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        direction_pin: gpio.7
        step_pin: gpio.22
  y:
    steps_per_mm: 100
    max_rate_mm_per_min: 5000
    acceleration_mm_per_sec2: 400
    max_travel_mm: 500
    soft_limits: false
    homing:
      cycle: 2
      mpos_mm: 0
      positive_direction: false
      feed_mm_per_min: 400
      seek_mm_per_min: 2000
    motor0:
      limit_all_pin: gpio.4:low:pu
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        direction_pin: gpio.25
        step_pin: gpio.14
    motor1:
      null_motor:
      limit_all_pin: gpio.17:low:pu
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        direction_pin: gpio.8
        step_pin: gpio.21
  z:
    steps_per_mm: 800
    max_rate_mm_per_min: 3000
    acceleration_mm_per_sec2: 100
    max_travel_mm: 80
    homing:
      cycle: 1
      mpos_mm: 0
      positive_direction: true
      feed_mm_per_min: 300
      seek_mm_per_min: 600
    motor0:
      limit_all_pin: gpio.16:low
      hard_limits: false
      pulloff_mm: 2.000
      stepstick:
        direction_pin: gpio.33:low
        step_pin: gpio.27
    motor1:
      null_motor:

spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18

sdcard:
  cs_pin: gpio.5
  card_detect_pin: NO_PIN

coolant:
  flood_pin: NO_PIN
  mist_pin: NO_PIN
  delay_ms: 0
        
probe:
  pin: NO_PIN

control:
  reset_pin: gpio.39:low

  macro0_pin: gpio.35:low
  macro1_pin: gpio.34:low

macros:
  macro0: $SD/Run=/3345-04.g
  macro1: $Home

relay:
  output_pin: gpio.2
  enable_pin: NO_PIN
  direction_pin: NO_PIN
  disable_with_s0: false
  s0_with_disable: true
  spinup_ms: 0
  spindown_ms: 0
  tool_num: 0
  speed_map: 0=0% 1=100%
  
start:
  must_home: false

Startup Messages

[MSG:INFO: FluidNC v3.6.1]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.1-1-gb8050b365e]
[MSG:INFO: Local filesystem type is SPIFFS]
[MSG:INFO: Configuration file:config.yaml]
[MSG:WARN: Ignored key direction_pin]
[MSG:WARN: Ignored key step_pin]
[MSG:INFO: Machine MPCNC]
[MSG:INFO: Board GRBL ESP32 Controller]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN]
[MSG:INFO: Stepping:RMT Pulse:4us Dsbl Delay:0us Dir Delay:0us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Shared stepper disable gpio.13]
[MSG:INFO: Axis X (0.000,800.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:gpio.12 Dir:gpio.26 Disable:NO_PIN]
[MSG:INFO:  X All Limit gpio.15:low]
[MSG:INFO:   Motor1]
ets Jun  8 2016 00:22:57

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:12812
load:0x40080400,len:3032
entry 0x400805e4

User Interface Software

No response

What happened?

ESP32 crashes while I add motor1 section in config. One has only to write null_motor: in this section, and everything starts working.

I tried version v3.6.1 and v3.6.0. In version 3.4.5 the same config file works well.

Other Information

No response

@MitchBradley
Copy link
Collaborator

The problem is the use of gpio.7 as a direction pin. That pin is already used for accessing the module's SPI FLASH. When you configure it, FluidNC changes the setup of that pin and then the system cannot access its code in FLASH, causing a crash.

Please consult the ESP32 pin reference to learn which pins can and cannot be used.

I will try to improve the error message for this condition.

MitchBradley added a commit that referenced this issue Sep 25, 2022
Also improved the readability of the associated error message by
reducing verbosity, and eliminated the backtrace on assertion
failures.  It is rarely possible to decode the backtrace in common
usage, and not particularly useful even when it can be decoded.
@ereenke
Copy link
Author

ereenke commented Sep 26, 2022

That pin is already used for accessing the module's SPI FLASH.

Can't I use these pins for my needs? This is bad because the board I'm using won't work.

@MitchBradley
Copy link
Collaborator

No, you cannot use them. That is why the pin reference says they are not usable.
image

@ereenke
Copy link
Author

ereenke commented Sep 26, 2022

But in earlier versions FluidNC, these pins could be successfully used to connect to motor drivers. I just want to find out specifically why they can't be freely used now.

Is this a temporary solution and will it be fixed later? Or will I have to make another board to use the new firmware versions?

@MitchBradley
Copy link
Collaborator

But in earlier versions FluidNC, these pins could be successfully used to connect to motor drivers.

I do not think it is possible that earlier versions could use those pins. GPIO7 is connected inside the ESP32 metal can to the D0 (main data) line of the SPI FLASH chip. If you interfere with that line in any way, the ESP32 will be unable to fetch code from that FLASH and it will crash.

This is not specific to FluidNC. There are references all over the Internet that say the same thing - you cannot use those pins because they are already used for the critical purpose of communication between the microprocessor and the FLASH that stores the program code. Here is one such reference

In order for me to believe that earlier versions of FluidNC could use those pins, you would have to show the schematic for your board, identify the specific version of FluidNC where it worked, show us the config file that worked with that version, and show a video of it working.

@MitchBradley
Copy link
Collaborator

Here is the Espressif manual for the old ESP32-WROOM-32D module: It clearly states that those pins are used for SPI FLASH

image

Here is a the Espressif manual for a more current ESP32-WROOM-32E module It says that, in the current versions of the module, those pins are not even connected to the outside of the module

image

MitchBradley added a commit that referenced this issue Sep 26, 2022
Handle reserved GPIOs without crashing - #630
@ereenke
Copy link
Author

ereenke commented Sep 26, 2022

Thanks for the detailed answer.

When I began to understand and looked at the electrical circuit of the control board, I remembered what was the matter. On my board, the DIR pins of two motors of the same axis are connected to the same pin of the ESP32. A year ago, I asked how to make FluidNC work in such a situation, because if specify the same pins or do not specify them, it would cause an error. You advised me to configure some unused direction_pin for the second motors. Well, I randomly chose just these reserved pins for SPI FLASH =)

But probably, after the version of the framework was updated, this trick stopped acting.

Now I just specified NO_PIN (apparently during this time such an opportunity was added to the firmware) and everything worked.

MitchBradley added a commit that referenced this issue Sep 29, 2022
Also improved the readability of the associated error message by
reducing verbosity, and eliminated the backtrace on assertion
failures.  It is rarely possible to decode the backtrace in common
usage, and not particularly useful even when it can be decoded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants