Limit switches not working

[ecdlguy]

Hi, a simple limit switch does nothing. When triggering the switch using 'll=3' gives:

[DEBUG] Limit switch 's1oben' has been triggered (IO pin statGuru Meditation Error: Core  1 panic'ed (Interrupt wdt timeout on CPU1). 

Core  1 register dump:
PC      : 0x40091eb2  PS      : 0x00060035  A0      : 0x80090b56  A1      : 0x3ffbee3c  
A2      : 0x3ffb9068  A3      : 0x3ffdd710  A4      : 0x00000004  A5      : 0x00060023  
A6      : 0x00060023  A7      : 0x00000001  A8      : 0x3ffdd710  A9      : 0x00000017  
A10     : 0x3ffdd710  A11     : 0x00000017  A12     : 0x3ffc4c64  A13     : 0x00060023  
A14     : 0x007bf518  A15     : 0x003fffff  SAR     : 0x00000013  EXCCAUSE: 0x00000006  
EXCVADDR: 0x00000000  LBEG    : 0x4008bd41  LEND    : 0x4008bd51  LCOUNT  : 0xfffffff0  
Core  1 was running in ISR context:
EPC1    : 0x4010303f  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x00000000

Backtrace: 0x40091eaf:0x3ffbee3c |<-CORRUPTED

  #0  0x40091eaf:0x3ffbee3c in vListInsert at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf public/components/freertos/list.c:183

Core  0 register dump:
PC      : 0x40092047  PS      : 0x00060035  A0      : 0x80090778  A1      : 0x3ffbec3c  
A2      : 0x3ffbf518  A3      : 0x00000001  A4      : 0xe67fc000  A5      : 0x00060023  
A6      : 0x00060021  A7      : 0x0000cdcd  A8      : 0x0000ab63  A9      : 0xffffffff  
A10     : 0x00000000  A11     : 0x00000001  A12     : 0x667fc000  A13     : 0x00000007  
A14     : 0x007bf518  A15     : 0x003fffff  SAR     : 0x0000001a  EXCCAUSE: 0x00000006  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0xe67fc000  LCOUNT  : 0x3f40b296  

Backtrace: 0x40092044:0x3ffbec3c |<-CORRUPTED

  #0  0x40092044:0x3ffbec3c in esp_ptr_external_ram at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/soc/include/soc/soc_memory_types.h:97
      (inlined by) spinlock_acquire at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_hw_support/include/soc/spinlock.h:99
      (inlined by) xPortEnterCriticalTimeout at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/freertos/port/xtensa/port.c:288

Here is the config:

{
  "serverConfiguration": {
    "port": 80,
    "wififMode": 2,
    "wifiSsid": "wifissid",
    "wifiPassword": "*****",
    "apName": "����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������?���������������������������������������������,[�?���������������������������������_\b@�<\b@0",
    "apPassword": "*****",
    "motionControllerCpuCore": 0
  },
  "stepperConfigurations": [
    {
      "id": 0,
      "name": "motor1",
      "stepPin": 23,
      "directionPin": 22,
      "stepsPerRev": 200,
      "stepsPerMM": 0,
      "microsteppingDivisor": 8,
      "rpmLimit": 1200,
      "breakPin": 255,
      "breakPinActiveState": 1,
      "breakEngageDelay": 0,
      "breakReleaseDelay": -1
    }
  ],
  "switchConfigurations": [
    {
      "id": 0,
      "name": "s1oben",
      "ioPin": 19,
      "stepperIndex": 0,
      "switchType": 6,
      "switchPosition": -1
    }
  ],
  "rotaryEncoderConfigurations": []
}

I also noticed every time after reboot and after motor movement I get the following line: E (1441) gpio: gpio_set_level(226): GPIO output gpio_num error

The motor is working, though.

[ecdlguy]

These are the libs and version used:

Resolving denky32 dependencies... Platform espressif32 @ 6.0.1 (required: espressif32) ├── framework-arduinoespressif32 @ 3.20006.221224 (required: platformio/framework-arduinoespressif32 @ ~3.20006.0) ├── tool-cmake @ 3.16.4 (required: platformio/tool-cmake @ ~3.16.0) ├── tool-esptoolpy @ 1.40400.0 (required: platformio/tool-esptoolpy @ ~1.40400.0) ├── tool-mkfatfs @ 2.0.1 (required: platformio/tool-mkfatfs @ ~2.0.0) ├── tool-mklittlefs @ 1.203.210628 (required: platformio/tool-mklittlefs @ ~1.203.0) ├── tool-mkspiffs @ 2.230.0 (required: platformio/tool-mkspiffs @ ~2.230.0) ├── tool-ninja @ 1.7.1 (required: platformio/tool-ninja @ ^1.7.0) └── toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5 (required: espressif/toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5)

Libraries ├── ESP Async WebServer @ 1.2.3+sha.f71e3d4 (required: git+https://github.com/me-no-dev/ESPAsyncWebServer.git) │ ├── AsyncTCP @ 1.1.1 (required: me-no-dev/AsyncTCP @ ^1.1.1) │ └── ESPAsyncTCP @ 1.2.2 (required: me-no-dev/ESPAsyncTCP @ ^1.2.2) └── ESP-StepperMotor-Server @ 0.4.8 (required: ESP-StepperMotor-Server) │ ├── ArduinoJson @ 6.19.2 (required: ArduinoJSON @ 6.19.2) │ └── ESP-FlexyStepper @ 1.4.5 (required: ESP-FlexyStepper @ 1.4.5)

[pkerspe]

Please post you code from main.cpp as well. Also change your apName, looks rather corrupt.

What do you mean by 'll=3'?

[ecdlguy]

Thanks for your promt reply!

regarding "ll=3": loglevel [ll]*: set or get the current log level for serial output.

Here is content of main.cpp:

#include <ESPStepperMotorServer.h>

ESPStepperMotorServer *stepperMotorServer;

const char *wifiName= "FMW WiFi"; // enter the SSID of the wifi network to connect to
const char *wifiSecret = "****"; // enter the password of the the existing wifi network here

void setup() 
{
  Serial.begin(115200);
  stepperMotorServer = new ESPStepperMotorServer(ESPServerRestApiEnabled | ESPServerWebserverEnabled | ESPServerSerialEnabled);
  stepperMotorServer->setWifiCredentials(wifiName, wifiSecret);
  stepperMotorServer->setWifiMode(ESPServerWifiModeClient); //start the server as a wifi client (DHCP client of an existing wifi network)
  stepperMotorServer->start();
}

void loop() 
{
}

platformio.ini:

[env:denky32]
platform = espressif32
board = denky32
framework = arduino
lib_deps = 
    ESP-StepperMotor-Server ;
    https://github.com/me-no-dev/ESPAsyncWebServer.git ;
monitor_speed = 115200 ;
monitor_filters = esp32_exception_decoder, default, colorize ;
build_type = debug ;

I have no idea why the AP name looks like this, after first boot it didn't.

[ecdlguy]

Hi Paul,

I think the reason for the crash is that the handling of the interrupt takes too long with "ll=3". This would also explain why the crash doesn't happen with debug logging disabled.

However, I still have the problem that the switch does not interrupt the movement. I found that it is only a problem if moving using the "left" direction arrow. Using the "right" direction, the switch works as expected! (Of course I changed the switch setup accordingly)

This is what I found:

homing switch "begin/left/bottom, active high":

{"settings":{"positionSwitchCounterLimit":10,"statusRegisterCounter":2},"switchStatusRegister":[{"statusRegisterIndex":0,"status":"00000000"},{"statusRegisterIndex":1,"status":"00000000"}],"positionSwitches":[{"id":0,"name":"s1oben","ioPin":19,"position":-1,"stepperId":0,"active":0,"type":{"pinMode":"Active High","switchType":"Homing switch (start-position)"}}]}

-> does not stop movement in either direction (left or right)

homing switch "end/right/top, active high"

{"settings":{"positionSwitchCounterLimit":10,"statusRegisterCounter":2},"switchStatusRegister":[{"statusRegisterIndex":0,"status":"00000000"},{"statusRegisterIndex":1,"status":"00000000"}],"positionSwitches":[{"id":0,"name":"s1oben","ioPin":19,"position":-1,"stepperId":0,"active":0,"type":{"pinMode":"Active High","switchType":"Homing switch (end-position)"}}]}

-> does stop movement in "right" direction

Thanks for looking into this.

cheers, Thorsten

[pkerspe]

Ok, thanks for the update. Yes, the logging is the cause. The error states "(Interrupt wdt timeout on CPU1). ". The Watchdog timeout is triggered, because logging in an interrupt routine is a bad idea :-) I will remove that log statement from there Newest release v0.4.10 should fix this issue with the Kernel Panic

[pkerspe]

will check on the direction switch interaction problem in a bit.

[ecdlguy]

I also have a question or maybe found a bug regarding the Web UI, should I just open a new issue there or just aks here?

[pkerspe]

please open a new issue ticket for UI stuff

[tjhgit]

Same issue here regarding the direction switch interaction problem. @pkerspe : Can you comment when you can fix this?

[pkerspe]

@tjhgit can you please provide the version of ESP-FlexyStepper and ESP-StepperMotor-Server you are using? I checked the logic and variable types should be fine, I currently to not have a test setup available, thus the theoretical approach. I will try to setup a physical test rack by the end of this week and give an update. But please check you are running the latest versions of both libraries. You should be using version 1.4.6 (or newer once available) of the ESP-FlexyStepper Library

[mrtally]

I've also observed the failure of begin/left/bottom having tested both high and low.

Built in PlatformIO with the following dependency graph.

ESP-StepperMotor-Server @ 0.4.10 (required: ESP-StepperMotor-Server) │ ├── ArduinoJson @ 6.19.4 (required: ArduinoJSON @ 6.19.4) │ └── ESP-FlexyStepper @ 1.4.6 (required: ESP-FlexyStepper @ 1.4.6)

[pkerspe]

might be actually a problem of the definition of ESP_FlexyStepper::LIMIT_SWITCH_BEGIN: static const byte LIMIT_SWITCH_BEGIN = -1; probably not a good idea to use a negative value here since in arduino byte resolves to typedef uint8_t byte;. I will try to get my development evironment setup again, currently I did not work on the library for a while and seems some libs are outdated so I got compile errors. But for everyone getting these errors try changing line static const byte LIMIT_SWITCH_BEGIN = -1; in ESP_FlexyStepper.h to: static const byte LIMIT_SWITCH_BEGIN = 3; or static const signed char LIMIT_SWITCH_BEGIN = -1;

[pkerspe]

@tjhgit @mrtally did the suggested fix in my previous comment help you guys? Please kindly confirm.

[mrtally]

SUCCESS! @pkerspe changing LIMIT_SWITCH_BEGIN from -1 to 3 does fix the problem. I'll try the signed char type approach next.

update: static const signed char LIMIT_SWITCH_BEGIN = -1; works as well.

[pkerspe]

ok, I update the ESP-FlexyStepper library, version 1.4.8 or above certainly contains the fix