Currently, I'm trying to allow users to switch the physical layer from wifi to ethernet, and vice versa.
So far so good, except when the emac task starts again, a stack overflow occurs.
We are on version 3.1 of the IDF.
Code: Select all
I (2714) COMMS: Sta Disconnected
comms eth
W (4774) COMMS: Restarting comms!
W (4775) COMMS: Disabling Ethernet...
I (4775) ETHERNET: Stopping
W (4786) JCFG: Key system.network.ethernet not found in KVP table system
W (4787) COMMS: Disabling Wifi...
I (4798) wifi: flush txq
I (4798) wifi: stop sw txq
I (4801) wifi: lmac stop hw txq
I (4802) wifi: Deinit lldesc rx mblock:10
I (4803) COMMS: Stopped Sta
I (6802) COMMS: Connecting with ethernet
I (6802) sys: free DRAM 175500 IRAM 240832
I (6803) sys: free DRAM 175256 IRAM 240588
I (6813) ETHERNET: Enabling DHCP
I (6814) ETHERNET: Initializing
I (6815) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (6827) emac: emac start !!!
I (6837***ERROR*** A stack overflow in task emacT has been detected.
abort() was called at PC 0x4008e14c on core 0
0x4008e14c: vApplicationStackOverflowHook at /home/rene/esp32/apps/my_project/esp-idf/components/esp32/panic.c:649
Backtrace: 0x4008e107:0x3ffcb0c0 0x4008e133:0x3ffcb0e0 0x4008e14c:0x3ffcb100 0x4008b4aa:0x3ffcb120 0x4008c93c:0x3ffcb150 0x4008c8f2:0x3ffcb460 0x400e3df6:0x3ffcb580 0x400e6f99:0x3ffcb890 0x400823ee:0x3ffcb8c0
0x4008e107: invoke_abort at /home/rene/esp32/apps/my_project/esp-idf/components/esp32/panic.c:649
0x4008e133: abort at /home/rene/esp32/apps/my_project/esp-idf/components/esp32/panic.c:649
0x4008e14c: vApplicationStackOverflowHook at /home/rene/esp32/apps/my_project/esp-idf/components/esp32/panic.c:649
0x4008b4aa: vTaskSwitchContext at /home/rene/esp32/apps/my_project/esp-idf/components/freertos/tasks.c:3564
0x4008c93c: _frxt_dispatch at /home/rene/esp32/apps/my_project/esp-idf/components/freertos/portasm.S:406
0x4008c8f2: _frxt_int_exit at /home/rene/esp32/apps/my_project/esp-idf/components/freertos/portasm.S:206
0x400e3df6: _vfprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:875
0x400e6f99: vprintf at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vprintf.c:39
0x400823ee: esp_log_write at /home/rene/esp32/apps/my_project/esp-idf/components/log/log.c:121
Wifi has been enabled before trying to switch the interface, and I'm using the CLI system as provided by one of the newer updates to set the interface, as you can see by 'comms eth'.
So far so good, wifi gets disabled, and if ethernet was enabled you'd see something along the lines of 'emac stop' in between Disabling Ethernet... and Disabling Wifi..., as such I can conclude ethernet has not been enabled or initialized.
Then you'll see how much RAM we have left on the system, which I think should be enough to allow the emac to do its business. Emac is starting, as is expected. But then the log promptly ends, and voila, a stack overflow occurs.
As you can tell by the time stamp, this is about 4 seconds in, so there's already quite a lot running alongside this task. It works perfectly fine most of the time at startup, though, but resetting the entire system to work around this is... not exactly in my best interests.
I realize switching the used interface half-way through everything may be somewhat unconventional, but I'd think it's a realistic use case scenario. Still, I'm not quite sure how to solve this one.
Is there anything I'm overlooking?