Build image not working about esp32 HOT 21 CLOSED

I am not able to replicate this, please add the zip file with the generated firmware to a comment so I can decode the backtrace.

from esp32.

The problem seems to be with the Y_AUTO_SQUARE=1, if I dissable that it's fine

from esp32.

Here is the firmware I test with and which does not crash:

firmware.zip

If it fails for you try erasing the flash before reflashing it.

from esp32.

I managed to do some test last night and compile my own version. From the test that I have done it looks like it's hapening once I have WIFI enabled in the FW. If I configure to connect to my AP the automatic reporting seems to be the problem trigering the xTimers.

If I erase the wifi config and don't configure wifi, I have no problem when i'm connected via serial

from esp32.

Post your $I output and settings except $74/$75 and I'll try with that.

from esp32.

Here is my Platformio.ini:
; PlatformIO Project Configuration File
[platformio]
src_dir = main
include_dir = main

[wifi_networking]
build_flags =

[env:ESP32]
platform = espressif32 @ ~4.0.0
framework = espidf
board = esp32dev
board_build.partitions = partitions.csv
#board_build.cmake_extra_args = %cmake_flags%
board_build.embed_files =
main/embedded/favicon.ico
main/embedded/ap_login.html
main/embedded/index.html.gz
build_flags =
#See Inc/my_machine.h for options
-Wimplicit-fallthrough=1
-Wno-missing-field-initializers
-Wno-maybe-uninitialized
-Wno-stringop-truncation
-D BOARD_MKS_TINYBEE_V1=1
-D N_AXIS=3
-D Y_AUTO_SQUARE=1
-D BLUETOOTH_ENABLE=0
-D WIFI_ENABLE=1
-D TELNET_ENABLE=0
-D WIFI_SOFTAP=0
-D MDNS_ENABLE=0
-D WEBSOCKET_ENABLE=1
-D MODBUS_ENABLE=1
-D MODBUS_BAUDRATE=3
-D SDCARD_ENABLE=1
-D N_SPINDLE=2
-D SPINDLE0_ENABLE=12
-D SPINDLE1_ENABLE=1
-D PROBE_ENABLE=1
-D SAFETY_DOOR_ENABLE=0
-D KEYPAD_ENABLE=0

lib_compat_mode = off

monitor_speed=115200

$I
[VER:1.1f.20240127:]
[OPT:VNMSL2,100,1024,3,0]
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,REBOOT,SED,RTC,WIFI,SD]
[FIRMWARE:grblHAL]
[SIGNALS:RHS]
[NVS STORAGE:*FLASH]
[FREE MEMORY:148K]
[DRIVER:ESP32]
[DRIVER VERSION:240127]
[DRIVER OPTIONS:4.3.2]
[BOARD:MKS Tinybee V1.0]
[AUX IO:1,1,0,0]
[WIFI MAC:d8:bc:38:57:0d:4c]
[IP:0.0.0.0]
[PLUGIN:MODBUS v0.15]
[PLUGIN:HUANYANG VFD v0.11]
[PLUGIN:SDCARD v1.13]
[PLUGIN:FS macro plugin v0.07]
[SPINDLE:PWM]

%
; grblHAL
; 1.1f.20231005
; [OPT:VNMSL,35,1024,3,0]
; [NEWOPT:ENUMS,RT+,REBOOT,SED,RTC,WIFI,SD]
; [FIRMWARE:grblHAL]
; [NVS STORAGE:*FLASH]
; [FREE MEMORY:137K]
; [DRIVER:ESP32]
; [DRIVER VERSION:230927]
; [DRIVER OPTIONS:4.3.1]
; [BOARD:MKS Tinybee V1.0]
; [WIFI MAC:54:43:b2:8f:8e:10]
; [IP:192.168.5.1]
; [PLUGIN:MODBUS v0.15]
; [PLUGIN:HUANYANG VFD v0.11]
; [PLUGIN:HUANYANG P2A VFD v0.10]
; [PLUGIN:Durapulse VFD GS20 v0.05]
; [PLUGIN:Yalang VFD YL620A v0.02]
; [PLUGIN:MODVFD v0.03]
; [PLUGIN:H-100 VFD v0.03]
; [SPINDLE:Huanyang v1]
; [PLUGIN:SDCARD v1.10]
; [PLUGIN:FS macro plugin v0.06]
;
$N0=
$N1=
; 0 - Step pulse time
$0=10.0
; 1 - Step idle delay
$1=25
; 2 - Step pulse invert
$2=0
; 3 - Step direction invert
$3=4
; 4 - Invert stepper enable pin(s)
$4=7
; 5 - Invert limit pins
$5=7
; 6 - Invert probe pin
$6=1
; 9 - PWM Spindle
$9=1
; 10 - Status report options
$10=511
; 11 - Junction deviation
$11=0.010
; 12 - Arc tolerance
$12=0.002
; 13 - Report in inches
$13=0
; 14 - Invert control pins
$14=4
; 15 - Invert coolant pins
$15=0
; 16 - Invert spindle signals
$16=0
; 17 - Pullup disable control pins
$17=0
; 18 - Pullup disable limit pins
$18=0
; 19 - Pullup disable probe pin
$19=0
; 20 - Soft limits enable
$20=0
; 21 - Hard limits enable
$21=0
; 22 - Homing cycle
$22=0
; 23 - Homing direction invert
$23=0
; 24 - Homing locate feed rate
$24=25.0
; 25 - Homing search seek rate
$25=500.0
; 26 - Homing switch debounce delay
$26=250
; 27 - Homing switch pull-off distance
$27=1.000
; 28 - G73 Retract distance
$28=0.100
; 29 - Pulse delay
$29=0.0
; 30 - Maximum spindle speed
$30=24000.000
; 31 - Minimum spindle speed
$31=6000.000
; 32 - Mode of operation
$32=0
; 33 - Spindle PWM frequency
$33=5000
; 34 - Spindle PWM off value
$34=0.0
; 35 - Spindle PWM min value
$35=0.0
; 36 - Spindle PWM max value
$36=100.0
; 37 - Steppers deenergize
$37=4
; 39 - Enable legacy RT commands
$39=1
; 40 - Limit jog commands
$40=0
; 43 - Homing passes
$43=1
; 44 - Axes homing, first pass
$44=4
; 45 - Axes homing, second pass
$45=3
; 46 - Axes homing, third pass
$46=0
; 62 - Sleep enable
$62=0
; 63 - Feed hold actions
$63=3
; 64 - Force init alarm
$64=0
; 65 - Probing feed override
$65=0
; 70 - Network Services
$70=3
; 73 - WiFi Mode
$73=2
; 74 - WiFi Station (STA) SSID
$74=
; 75 - WiFi Station (STA) Password
$75=
; 76 - WiFi Access Point (AP) SSID
$76=grblHAL_AP
; 77 - WiFi Access Point (AP) Password
$77=grblHALpwd
; 78 - WiFi Country Code
$78=CA
; 79 - WiFi Channel (AP)
$79=1
; 100 - X-axis travel resolution
$100=320.000
; 101 - Y-axis travel resolution
$101=320.000
; 102 - Z-axis travel resolution
$102=640.000
; 110 - X-axis maximum rate
$110=7500.000
; 111 - Y-axis maximum rate
$111=7500.000
; 112 - Z-axis maximum rate
$112=7500.000
; 120 - X-axis acceleration
$120=400.000
; 121 - Y-axis acceleration
$121=400.000
; 122 - Z-axis acceleration
$122=400.000
; 130 - X-axis maximum travel
$130=200.000
; 131 - Y-axis maximum travel
$131=200.000
; 132 - Z-axis maximum travel
$132=200.000
; 310 - Hostname (AP)
$310=grblHAL_AP
; 312 - IP Address (AP)
$312=192.168.5.1
; 313 - Gateway (AP)
$313=192.168.5.1
; 314 - Netmask (AP)
$314=255.255.255.0
; 320 - Hostname
$320=grblHAL
; 322 - IP Address
$322=192.168.5.1
; 323 - Gateway
$323=192.168.5.1
; 324 - Netmask
$324=255.255.255.0
; 325 - Telnet port
$325=23
; 327 - Websocket port
$327=80
; 337 - WiFi Access Point (AP) BSSID
$337=
; 340 - Spindle at speed tolerance
$340=0.0
; 341 - Tool change mode
$341=0
; 342 - Tool change probing distance
$342=30.0
; 343 - Tool change locate feed rate
$343=25.0
; 344 - Tool change search seek rate
$344=200.0
; 345 - Tool change probe pull-off rate
$345=200.0
; 346 - Restore position after M6
$346=1
; 374 - ModBus baud rate
$374=2
; 375 - ModBus RX timeout
$375=50
; 384 - Disable G92 persistence
$384=0
; 394 - Spindle on delay
$394=12.0
; 395 - Default spindle
$395=1
; 398 - Planner buffer blocks
$398=35
; 476 - Spindle 0 ModBus address
$476=1
; 481 - Autoreport interval
$481=0
; 486 - Lock coordinate systems
$486=0
; 511 - Spindle 1
$511=7
; 512 - Spindle 2
$512=7
; 513 - Spindle 3
$513=7
; 520 - Spindle 0 tool number start
$520=65535
%

from esp32.

Thanks, I am still not able to replicate. Do you get the same assert message as you initally posted?
It could be due to assert failing if a 0 ms delay is with a callback, I will change this code to:

        if(ms) {
            xDelayTimer = xTimerCreate("msDelay", pdMS_TO_TICKS(ms), pdFALSE, callback, vTimerCallback);
            xTimerStartFromISR(xDelayTimer, &xHigherPriorityTaskWoken);
            if(xHigherPriorityTaskWoken)
                portYIELD_FROM_ISR();
        } else
            callback();

to make sure it will never happen from there. You may try this change if you wish.

What would help is beeing able to decode the stack trace to see where the offending call was made from. You can do that?
BTW did you try the firmware I posted above? Same assert message?

from esp32.

Sorry for the delays, I was away. I tried your FW posted above and I have the same issue. The MCU was formatted prior to uploading.

Here is a new test FW I just compiled using:

; PlatformIO Project Configuration File

[platformio]
src_dir = main
include_dir = main

[wifi_networking]
build_flags =

[env:ESP32]
platform = espressif32 @ ~4.0.0
framework = espidf
board = esp32dev
board_build.partitions = partitions.csv
#board_build.cmake_extra_args = %cmake_flags%
board_build.embed_files =
main/embedded/favicon.ico
main/embedded/ap_login.html
main/embedded/index.html.gz
build_flags =
#See Inc/my_machine.h for options
-Wimplicit-fallthrough=1
-Wno-missing-field-initializers
-Wno-maybe-uninitialized
-Wno-stringop-truncation
-D BOARD_MKS_TINYBEE_V1=1
-D N_AXIS=3
-D Y_AUTO_SQUARE=1
-D BLUETOOTH_ENABLE=0
-D WIFI_SOFTAP=0
-D WIFI_ENABLE=1
-D MDNS_ENABLE=0
-D TELNET_ENABLE=1
-D WEBSOCKET_ENABLE=1
-D MODBUS_ENABLE=1
-D MODBUS_BAUDRATE=3
-D SDCARD_ENABLE=1
-D N_SPINDLE=2
-D SPINDLE0_ENABLE=12
-D SPINDLE1_ENABLE=1
-D PROBE_ENABLE=1
-D SAFETY_DOOR_ENABLE=0
-D KEYPAD_ENABLE=0

lib_compat_mode = off

monitor_speed=115200
TestFW.zip

from esp32.

What would help is beeing able to decode the stack trace to see where the offending call was made from. You can do that?

I do not know how to do that :(

from esp32.

I just tried a simple esp32doit-devkit-v1 with the web builder only enabling wifi in STA mode, uploaded the code and everything works until I configure WIFI and then I have the same issue. I did noticed that it throws an error on reset if I connect with a terminal. I'm not sure if this is related, I tried to locating where this could be coming from but I was not able to find. This is happening on both the devkit and the MKS tinybee.

E (20) gpio: GPIO_PIN mask error

Resetting MCU
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_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:13220
ho 0 tail 12 room 4
load:0x40080400,len:3028
entry 0x400805e4
I (346) cpu_start: Pro cpu up.
I (346) cpu_start: Starting app cpu, entry point is 0x40085a90
I (0) cpu_start: App cpu up.
I (361) cpu_start: Pro cpu start user code
I (361) cpu_start: cpu freq: 160000000
I (361) cpu_start: Application information:
I (365) cpu_start: Project name: grbl
I (370) cpu_start: App version: 3935fbd-dirty
I (375) cpu_start: Compile time: Feb 21 2024 11:59:22
I (382) cpu_start: ELF file SHA256: 9483d731b8de6195...
I (387) cpu_start: ESP-IDF: 4.3.2
I (393) heap_init: Initializing. RAM available for dynamic allocation:
I (400) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (406) heap_init: At 3FFBC928 len 000236D8 (141 KiB): DRAM
I (412) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (418) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (425) heap_init: At 40099FA0 len 00006060 (24 KiB): IRAM
I (432) spi_flash: detected chip: winbond
I (436) spi_flash: flash io: dio
I (441) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
E (20) gpio: GPIO_PIN mask error

E (163047) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (163047) task_wdt: - IDLE (CPU 1)
E (163047) task_wdt: Tasks currently running:
E (163047) task_wdt: CPU 0: IDLE
E (163047) task_wdt: CPU 1: tiT
E (163047) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x40172707:0x3FFB1150 0x4008673D:0x3FFB1170 0x40175B73:0x3FFC0010 0x40172247:0x3FFC0030 0x4008E5D5:0x3FFC0050 0x40090431:0x3FFC0070

E (163047) task_wdt: Print CPU 1 backtrace

Backtrace:0x4008AF55:0x3FFB1750 0x4008673D:0x3FFB1770 0x4010E32F:0x3FFC8640 0x40106587:0x3FFC8660 0x40106663:0x3FFC8680 0x40090431:0x3FFC86B0

from esp32.

Zip the firmware.elf file that generated the backtrace so I can check where it fails.
Or open the ESP IDF shell, navigate to the build folder and run xtensa-esp32-elf-addr2line -pfiaC -e build/firmware.elf <address> where <address> is picked from the backtrace, e.g 0x40172707.

from esp32.

The web builder seems ok now, I just tried it again and the generated FW has no issue but i'M still not ble to build a valid FW for this board.

Is it possible to see or get a copy of what the Web builder is using for a platformIo for this board?

from esp32.

Is it possible to see or get a copy of what the Web builder is using for a platformIo for this board?

Add /?dev=1 to the Web Builder URL.

from esp32.

ok that worked, I compared the 2 .ini file. They were very similar but the config file is still not generating a valid FW on my side. I even tried it on a fresh install of Window and VSCode with just PlatformIO.

I don't see any errors in the build but the .bin file are larger for the bootloader.bin (web is 18kb, local is 26kb) and firmware.bin (web is 853kb, local 961kb)

This is the list of buildtolls it automaticly downloaded:

• Executing task: platformio run --environment test

Processing test (platform: espressif32 @ ~4.0.0; framework: espidf; board: esp32dev)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (4.0.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:

• framework-espidf @ 3.40302.0 (4.3.2)
• tool-cmake @ 3.16.4
• tool-esptoolpy @ 1.30100.210531 (3.1.0)
• tool-ninja @ 1.9.0
• toolchain-esp32ulp @ 1.22851.191205 (2.28.51)
• toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch2

from esp32.

I am seeing this in the build log now:
main/grbl/protocol.c: In function 'protocol_enqueue_rt_command':
main/grbl/protocol.c:1051:45: warning: cast between incompatible function types from 'on_execute_realtime_ptr' {aka 'void ()(unsigned int)'} to 'void ()(void *)' [-Wcast-function-type]
return protocol_enqueue_foreground_task((foreground_task_ptr)fn, (void *)&dummy_data);

from esp32.

If you could decode the backtrace for at least 0x40172707 I may get a clue where and thus why it is failing.

The cast warning is not the cause, anyway I have changed the code in order to shut up the compiler. BTW the ESP32 compiler is the only one that is configured to complain about it...

from esp32.

I reinstalled VSCode and PlatformIO, recompiled from a fresh git clone. Here is the new dump.

git clone --recurse-submodules https://github.com/grblHAL/ESP32.git

firmware.elf.zip
platformio.ini.zip

Processing esp32dev (platform: espressif32 @ ~4.0.0; framework: espidf; board: esp32dev)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (4.0.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:

• framework-espidf @ 3.40302.0 (4.3.2)
• tool-cmake @ 3.16.4
• tool-esptoolpy @ 1.30100.210531 (3.1.0)
• tool-mkfatfs @ 2.0.1
• tool-mklittlefs @ 1.203.210628 (2.3)
• tool-mkspiffs @ 2.230.0 (2.30)
• tool-ninja @ 1.9.0
• toolchain-esp32ulp @ 1.22851.191205 (2.28.51)
• toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch2
  Reading CMake configuration...
  LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
  LDF Modes: Finder ~ chain, Compatibility ~ off
  Found 0 compatible libraries
  Scanning dependencies...

␛[0;32mI (1062) system_api: Base MAC address is not set␛[0m
␛[0;32mI (1062) system_api: read default base MAC address from EFUSE␛[0m
I (1072) wifi:wifi firmware version: eb52264
I (1072) wifi:wifi certification version: v7.0
I (1072) wifi:config NVS flash: enabled
I (1082) wifi:config nano formating: disabled

I (1082) wifi:Init data frame dynamic rx buffer num: 32
I (1082) wifi:Init management frame dynamic rx buffer num: 32
I (1092) wifi:Init management short buffer num: 32
I (1092) wifi:Init dynamic tx buffer num: 32
I (1102) wifi:Init static rx buffer size: 1600
I (1102) wifi:Init static rx buffer num: 10
I (1112) wifi:Init dynamic rx buffer num: 32
␛[0;32mI (1112) wifi_init: rx ba win: 6␛[0m
␛[0;32mI (1112) wifi_init: tcpip mbox: 32␛[0m
␛[0;32mI (1122) wifi_init: udp mbox: 6␛[0m
␛[0;32mI (1122) wifi_init: tcp mbox: 6␛[0m
␛[0;32mI (1132) wifi_init: tcp tx win: 5744␛[0m
␛[0;32mI (1132) wifi_init: tcp rx win: 5744␛[0m
␛[0;32mI (1132) wifi_init: tcp mss: 1440␛[0m
␛[0;32mI (1142) wifi_init: WiFi IRAM OP enabled␛[0m
␛[0;32mI (1142) wifi_init: WiFi RX IRAM OP enabled␛[0m
I (1152) wifi:Set ps type: 0

␛[0;32mI (1152) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07␛[0m
I (1252) wifi:mode : sta (d8:bc:38:aa:ab:cc)
I (1252) wifi:enable tsf
␛[0;32mI (1262) gpio: GPIO[39]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 ␛[0m
␛[0;32mI (1262) gpio: GPIO[22]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 ␛[0m
I (1272) wifi:␛[0;32mI (1272) gpio: GPIO[12]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 ␛[0m
new:<1,1>, old:<1,0>, ap:<255,255>, sta:<1,1>, prof:1␛[0;32mI (1282) gpio: GPIO[32]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 ␛[0m

␛[0;32mI (1292) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 ␛[0m
␛[0;32mI (1302) gpio: GPIO[35]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 ␛[0m
␛[0;32mI (1312) gpio: GPIO[36]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:1 ␛[0m
GrblHAL 1.1f ['$' or '$HELP' for help]
I (2042) wifi:state: init -> auth (b0)
I (2052) wifi:state: auth -> assoc (0)
I (2062) wifi:state: assoc -> run (10)
I (2092) wifi:connected with CNC, aid = 1, channel 1, 40U, bssid = aa:a2:f4:4f:c8:c4
I (2092) wifi:security: WPA2-PSK, phy: bgn, rssi: -75
I (2092) wifi:pm start, type: 0

W (2102) wifi:idx:0 (ifx:0, aa:a2:f4:4f:c8:c4), tid:7, ssn:0, winSize:64
I (2452) wifi:AP's beacon interval = 102400 us, DTIM period = 1
␛[0;32mI (3052) esp_netif_handlers: sta ip: x.1.10.227, mask: 255.255.255.0, gw: x.1.10.1␛[0m
␛[0;31mE (6272) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:␛[0m
␛[0;31mE (6272) task_wdt: - IDLE (CPU 1)␛[0m
␛[0;31mE (6272) task_wdt: Tasks currently running:␛[0m
␛[0;31mE (6272) task_wdt: CPU 0: IDLE␛[0m
␛[0;31mE (6272) task_wdt: CPU 1: tiT␛[0m
␛[0;31mE (6272) task_wdt: Print CPU 0 (current core) backtrace␛[0m

Backtrace:0x4017271B:0x3FFB1150 0x400867B9:0x3FFB1170 0x40175B87:0x3FFC0010 0x4017225B:0x3FFC0030 0x4008E651:0x3FFC0050 0x400904AD:0x3FFC0070

␛[0;31mE (6272) task_wdt: Print CPU 1 backtrace␛[0m

Backtrace:0x4008AFD1:0x3FFB1750 0x400867B9:0x3FFB1770 0x4000BFED:0x3FFCF4F0 0x4009071A:0x3FFCF500 0x4008DE7A:0x3FFCF520 0x401187EF:0x3FFCF560 0x401065C0:0x3FFCF590 0x40106677:0x3FFCF5B0 0x400904AD:0x3FFCF5E0

0x4017271b: task_wdt_isr at /Users/charettec/.platformio/packages/framework-espidf/components/esp_common/src/task_wdt.c:189
0x400867b9: _xt_lowint1 at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/port/xtensa/xtensa_vectors.S:1105
0x40175b87: cpu_ll_waiti at /Users/charettec/.platformio/packages/framework-espidf/components/hal/esp32/include/hal/cpu_ll.h:183
(inlined by) esp_pm_impl_waiti at /Users/charettec/.platformio/packages/framework-espidf/components/esp_pm/pm_impl.c:827
0x4017225b: esp_vApplicationIdleHook at /Users/charettec/.platformio/packages/framework-espidf/components/esp_common/src/freertos_hooks.c:63
0x4008e651: prvIdleTask at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/tasks.c:3846 (discriminator 1)
0x400904ad: vPortTaskWrapper at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/port/xtensa/port.c:168

0x400867b9: _xt_lowint1 at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/port/xtensa/xtensa_vectors.S:1105
0x4000bfed: ?? ??:0
0x4009071a: vPortExitCritical at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/port/xtensa/port.c:473
0x4008de7a: xQueueReceive at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/queue.c:1368
0x401187ef: sys_arch_mbox_fetch at /Users/charettec/.platformio/packages/framework-espidf/components/lwip/port/esp32/freertos/sys_arch.c:325
0x401065c0: tcpip_timeouts_mbox_fetch at /Users/charettec/.platformio/packages/framework-espidf/components/lwip/lwip/src/api/tcpip.c:110
0x40106677: tcpip_thread at /Users/charettec/.platformio/packages/framework-espidf/components/lwip/lwip/src/api/tcpip.c:148
0x400904ad: vPortTaskWrapper at /Users/charettec/.platformio/packages/framework-espidf/components/freertos/port/xtensa/port.c:168

/Users/charettec/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-addr2line -pfiaC -e /Users/charettec/firmware.elf 0x4009071A

from esp32.

The stack trace above is all from the OS...
A possible explanation is that your build does not use the provided sdkconfig file - and that may explain why your build is larger.
Here is the boot output and $I from my build:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_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:2
load:0x3fff0030,len:1184
load:0x40078000,len:12928
load:0x40080400,len:3036
entry 0x400805e4
[MSG:Warning: Failed to initialize SD card]

GrblHAL 1.1f ['$' or '$HELP' for help]
[MSG:Warning: Failed to initialize SD card]
[MSG:WIFI STA ACTIVE, IP=10.0.0.72]
[MSG:WIFI AP SCAN COMPLETED]
[VER:1.1f.20240222:]
[OPT:VNMSL2,100,1024,3,0]
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT+,NOPROBE,REBOOT,SED,RTC,WIFI,FTP,SD]
[FIRMWARE:grblHAL]
[SIGNALS:RHS]
[NVS STORAGE:*FLASH]
[FREE MEMORY:172K]
[DRIVER:ESP32]
[DRIVER VERSION:240223]
[DRIVER OPTIONS:v4.4.6-dirty]
[BOARD:MKS Tinybee V1.0]
[AUX IO:0,1,0,0]
[WIFI MAC:3c:71:bf:4c:98:78]
[IP:10.0.0.72]
[PLUGIN:MODBUS v0.15]
[PLUGIN:HUANYANG VFD v0.11]
[PLUGIN:SDCARD v1.13]
[PLUGIN:FS macro plugin v0.07]
[SPINDLE:PWM]
ok

There is a lot less details output during startup - and that is controlled by the sdkconfig.

from esp32.

How do you specify to use a sdkconfig? Is it outside of the platformIO config? I just noticed a new sdkconfig.esp32dev gets created in the root folder next to the sdkconfig file.

from esp32.

It is possible to specify which sdkconfig to use - I found it earlier when searching the internet. IIRC CMakeLists.txt has to be changed - but not sure which one.

I just noticed a new sdkconfig.esp32dev gets created in the root folder next to the sdkconfig file.

Perhaps the easy way is to just copy the contents from sdkconfig to sdkconfig.esp32dev? Or delete the new one and rename the original? And then complain to the VS code maintainers about silently messing with the project?

BTW I have just committed a new build of grblHAL.

from esp32.

Ah great thank you!!!! Simply copying the content over from sdkconfig to sdkconfig.esp32dev fixed my problem. I can compile now and have no issue uploading and turning on the WIFI.

The new build of grblHAL also seems to be ok!

from esp32.