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.

Sign up for GitHub

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

Jump to bottom

WT32-ETH01 does not work via wired ethernet connection #1079

Closed
bartbutenaers opened this issue Apr 5, 2023 · 7 comments
Closed

WT32-ETH01 does not work via wired ethernet connection #1079

bartbutenaers opened this issue Apr 5, 2023 · 7 comments

Comments

@bartbutenaers
Copy link

Build environment: Linux
Target device: WT32-ETH01

Description
Some time ago @andycarle has been so kind to add support for the WT32-ETH01 board. And it works fine when I use WIFI.
When I skip the WIFI password and SSID (in the sidebar for Node-RED), then I see in the xsbug-log output that it keeps polling for an ethernet connection:

image

But when I plug my CAT cable into the WT32-ETH01, it just keeps polling and nothing happens.
Would be nice if you could give me some pointers of things I could try...

If you need extra information from me, please let me know where I can find that info!!

Kind regards,
Bart
@phoddie
Copy link
Collaborator

phoddie commented Apr 5, 2023

@bartbutenaers – The fact that it is disconnecting and reconnecting to xsbug-log suggests that the WT32-ETH01 is rebooting. If it was failing with a JavaScript exception, the exception would appear in the log. That implies the restart is caused by a crash in native code. But that's a lot of speculation. ;)

I've definitely seem Ethernet work on the WT32-ETH01 but I don't use one every day. Either @andycarle or I will take a look.

@bartbutenaers
Copy link
Author

@phoddie,
But if there was a Javascript exception, then I should see it in my xsbug-log?

  1. I start listening after Ralph's sidebar has generated this command:

    > IDF_PYTHON_ENV_PATH: /home/pi/.espressif/python_env/idf4.4_py3.9_env
>> mcconfig -d -x localhost:5004 -l -m -p esp32/wt32_eth01 -t xsbug
/home/pi/esp-idf/tools/idf.py
# starting xsbug
#xsbug-log listening on port 5002. ^C to exit.

  2. I power off/on the WT32-ETH01

  3. But the only thing I see in my log is the reconnecting.

Shouldn' I see a stacktrace in my xsbug-log if I power off/on the board while listening to it? Similar to how I saw stacktraces last week, when my Sensor node couldn't read my proximity sensor.

BTW is there a way to increase the log level perhaps, while being serial connected? I mean that the MCU sends e.g. trace level logging.

@phoddie
Copy link
Collaborator

phoddie commented Apr 5, 2023

But if there was a Javascript exception, then I should see it in my xsbug-log?

Correct.

The "disconnected" messages mean that the debugger connection was lost. The "connected" messages mean that it was re-established, which happens when a new virtual machine is created -- which is what happens immediately after reboot.

Shouldn' I see a stacktrace in my xsbug-log if I power off/on the board while listening to it? Similar to how I saw stacktraces last week, when my Sensor node couldn't read my proximity sensor.

xsbug is a JavaScript debugger. It cannot see crashes in native code (that would require gdb, which is really different adventure). Your Sensor node experience last week was generating JavaScript exceptions, so xsbug was able to see them.

@phoddie
Copy link
Collaborator

phoddie commented Apr 6, 2023

To make sure the Ethernet support for the WT32-eth01 board is working, I ran the httpget example:

cd $MODDABLE/examples/network/http/httpget
mcconfig -d -m -p esp32/wt32_eth01 -l

The output is as expected:

# starting xsbug
#xsbug-log listening on port 5002. ^C to exit.
#xsbug-log connected to "main"
Waiting for Ethernet link.
No Wi-Fi SSID
IP address 192.168.2.2
MAC address: C4:DE:E2:B2:43:37
<!doctype html>
<html>
...

If I run a Node-RED flow from the command line using mcconfig, I see the same result as you:

#xsbug-log listening on port 5002. ^C to exit.
#xsbug-log connected to "main"
Waiting for Ethernet link.
#xsbug-log disconnected from "main"
#xsbug-log connected to "main"
Waiting for Ethernet link.
...

Running an instrumented build (passing -I to mcconfig in place of -d) shows where it is failing:

...
I (109) cpu_start: Starting scheduler on PRO CPU.
I (instruments key: Pixels drawn,Frames drawn,Network bytes read,Network bytes written,Network sockets,Timers,Files,Poco display list used,Piu command List used,SPI flash erases,Turns,System bytes free,CPU 0,CPU 1,Chunk used,Chunk available,Slot used,Slot available,Stack used,Stack available,Garbage collections,Keys used,Modules loaded,Parser used,Floating Point
I (201) system_api: Base MAC address is not set
I (201) system_api: read default base MAC address from EFUSE
I (222) esp_eth.netif.netif_glue: c4:de:e2:b2:43:37
I (222) esp_eth.netif.netif_glue: ethernet attached to netif
Waiting for Ethernet link.

abort() was called at PC 0x400d5e3d on core 1
0x400d5e3d: initWiFi at ~/Projects/moddable/modules/network/wifi/esp32/xs6wifi.c:513 (discriminator 1)

Backtrace: 0x40081862:0x3ffbf540 0x4008a4c5:0x3ffbf560 0x4009075a:0x3ffbf580 0x400d5e3d:0x3ffbf5f0 0x400d5f25:0x3ffbf6e0 0x4010be66:0x3ffbf700 0x400edba5:0x3ffbf770 0x400d4b91:0x3ffbf790 0x400d3e93:0x3ffbf920
0x40081862: panic_abort at ~/esp32/esp-idf/components/esp_system/panic.c:402
0x4008a4c5: esp_system_abort at ~/esp32/esp-idf/components/esp_system/esp_system.c:128
0x4009075a: abort at ~/esp32/esp-idf/components/newlib/abort.c:46
0x400d5e3d: initWiFi at ~/Projects/moddable/modules/network/wifi/esp32/xs6wifi.c:513 (discriminator 1)
0x400d5f25: xs_wifi_set_mode at ~/Projects/moddable/modules/network/wifi/esp32/xs6wifi.c:56
0x4010be66: fxRunID at ~/Projects/moddable/xs/sources/xsRun.c:851
0x400edba5: fxRunCount at ~/Projects/moddable/xs/sources/xsAPI.c:1201
0x400d4b91: modRunMachineSetup at ~/Projects/moddable/xs/platforms/mc/xsHosts.c:581
0x400d3e93: loop_task at ~/Projects/moddable/build/tmp/esp32/wt32_eth01/instrument/node-red-mcu/xsProj-esp32/main/main.c:128

ELF file SHA256: b299a0cfe445e490

Entering gdb stub now.

It is a little late to debug that tonight, but I should be able to track it down tomorrow. The Node-RED MCU Edition runtime overrides the default setup/network module that initializes Wi-Fi. That maybe conflicting with the Ethernet support.

mkellner pushed a commit that referenced this issue Apr 7, 2023
@phoddie
Wi-Fi / Ethernet co-existence for ESP32 #1079
1fb06af
@phoddie
Copy link
Collaborator

phoddie commented Apr 7, 2023

This should be working now. 🤞 You just need to update your Moddable SDK.

In all of our projects, we enable either Wi-Fi or Ethernet, never both. The Node-RED MCU Edition runtime enabled both (even though you didn't configure a Wi-Fi SSID, it still initializes the Wi-Fi stack.... as a workaround for a bug in the ESP-IDF....). Having them both enabled is unexpected, but shouldn't crash. That's now fixed (no changes to the Node-RED MCU runtime).

In theory, it is possible now to run with both Ethernet and Wi-Fi connected (I did!). But, that requires some additional set-up code, that's not currently enabled.

@bartbutenaers
Copy link
Author

@phoddie,

Kids have holidays, so me having 100% me-time during breakfast. SDK updated and done the test. Everything works fine!
Again a small step for Moddable, a giant leap for Bart ;-)
Off to the daily job again...

Thanks a lot!!!!!

@phoddie
Copy link
Collaborator

phoddie commented Apr 7, 2023

@bartbutenaers – thank you for using your free time to verify the fix. Glad to have this fixed in the Moddable SDK.

mkellner pushed a commit that referenced this issue Aug 11, 2023
@phoddie @mkellner
Wi-Fi / Ethernet co-existence for ESP32 #1079
772c735
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@phoddie @bartbutenaers