esptool --chip esp32s3 -p /dev/cu.usbmodem1CDBD4A894401 write-flash 0x0 ./lunar/lunarcore-esp32s3.bin
esptool v5.1.0
Serial port /dev/cu.usbmodem1CDBD4A894401:
Connecting.............
A serial exception error occurred: Could not configure port: (6, 'Device not configured')
Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
esptool --chip esp32s3 -p /dev/cu.usbmodem1CDBD4A894401 write-flash 0x0 ./lunar/lunarcore-esp32s3.bin
esptool v5.1.0
Serial port /dev/cu.usbmodem1CDBD4A894401:
Connecting.............
A serial exception error occurred: Could not configure port: (6, 'Device not configured')
Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
<!-- github-sync-id:3908751014 -->
esptool.py --chip esp32s3 -p /dev/cu.usbmodem101 write_flash 0x0 ./lunar/lunarcore-esp32s3.bin
Warning: DEPRECATED: 'esptool.py' is deprecated. Please use 'esptool' instead. The '.py' suffix will be removed in a future major release.
Warning: Deprecated: Command 'write_flash' is deprecated. Use 'write-flash' instead.
esptool v5.1.0
Connected to ESP32-S3 on /dev/cu.usbmodem101:
Chip type: ESP32-S3 (QFN56) (revision v0.2)
Features: Wi-Fi, BT 5 (LE), Dual Core + LP Core, 240MHz, Embedded PSRAM 8MB (AP_3v3)
Crystal frequency: 40MHz
USB mode: USB-Serial/JTAG
MAC: 1c:db:d4:a8:94:40
Stub flasher running.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x003fffff...
Wrote 4194304 bytes (602717 compressed) at 0x00000000 in 15.0 seconds (2239.4 kbit/s).
Hash of data verified.
Hard resetting via RTS pin...
Tried it again ...
esptool.py --chip esp32s3 -p /dev/cu.usbmodem101 write_flash 0x0 ./lunar/lunarcore-esp32s3.bin
Warning: DEPRECATED: 'esptool.py' is deprecated. Please use 'esptool' instead. The '.py' suffix will be removed in a future major release.
Warning: Deprecated: Command 'write_flash' is deprecated. Use 'write-flash' instead.
esptool v5.1.0
Connected to ESP32-S3 on /dev/cu.usbmodem101:
Chip type: ESP32-S3 (QFN56) (revision v0.2)
Features: Wi-Fi, BT 5 (LE), Dual Core + LP Core, 240MHz, Embedded PSRAM 8MB (AP_3v3)
Crystal frequency: 40MHz
USB mode: USB-Serial/JTAG
MAC: 1c:db:d4:a8:94:40
Stub flasher running.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x003fffff...
Wrote 4194304 bytes (602717 compressed) at 0x00000000 in 15.0 seconds (2239.4 kbit/s).
Hash of data verified.
Hard resetting via RTS pin...
<!-- github-comment-id:3862956629 -->
rnodeconf /dev/cu.usbmodem101 --info
[00:03:08] Opening serial port /dev/cu.usbmodem101...
[00:03:12] Serial port opened, but RNode did not respond. Is a valid firmware installed?
Got invalid response while detecting device
rnodeconf /dev/cu.usbmodem101 --info
[00:03:08] Opening serial port /dev/cu.usbmodem101...
[00:03:12] Serial port opened, but RNode did not respond. Is a valid firmware installed?
Got invalid response while detecting device
<!-- github-comment-id:3862962994 -->
File "/Users/xx/.local/pipx/venvs/meshtastic/lib/python3.14/site-packages/meshtastic/mesh_interface.py", line 1111, in _waitConnected
raise MeshInterface.MeshInterfaceError(
"Timed out waiting for connection completion"
meshtastic --port /dev/cu.usbmodem101 --info
-->
File "/Users/xx/.local/pipx/venvs/meshtastic/lib/python3.14/site-packages/meshtastic/mesh_interface.py", line 1111, in _waitConnected
raise MeshInterface.MeshInterfaceError(
"Timed out waiting for connection completion"
<!-- github-comment-id:3862966735 -->
same here. with the same hardware.
I've flashed successfully but then stuck after booting.
Opening the serial after booting. I got this every 30 seconds Backtrace: 0x4205DF53:0x3FCA0C80 0x4037C7E9:0x3FCA0CB0 0x4037E85B:0x3FCCAFA0 0x4205D77D:0x3FCCAFC0 0x4038205B:0x3FCCAFE0.
same here. with the same hardware.
I've flashed successfully but then stuck after booting.
Opening the serial after booting. I got this every 30 seconds
`Backtrace: 0x4205DF53:0x3FCA0C80 0x4037C7E9:0x3FCA0CB0 0x4037E85B:0x3FCCAFA0 0x4205D77D:0x3FCCAFC0 0x4038205B:0x3FCCAFE0`.
<!-- github-comment-id:3864563277 -->
same here. with the same hardware. I've flashed successfully but then stuck after booting. Opening the serial after booting. I got this every 30 seconds Backtrace: 0x4205DF53:0x3FCA0C80 0x4037C7E9:0x3FCA0CB0 0x4037E85B:0x3FCCAFA0 0x4205D77D:0x3FCCAFC0 0x4038205B:0x3FCCAFE0.
that's the watchdog timeout. I'm going to doublecheck the pin configuration and init code now
> same here. with the same hardware. I've flashed successfully but then stuck after booting. Opening the serial after booting. I got this every 30 seconds `Backtrace: 0x4205DF53:0x3FCA0C80 0x4037C7E9:0x3FCA0CB0 0x4037E85B:0x3FCCAFA0 0x4205D77D:0x3FCCAFC0 0x4038205B:0x3FCCAFE0`.
that's the watchdog timeout. I'm going to doublecheck the pin configuration and init code now
<!-- github-comment-id:3865128029 -->
Here are the concrete pin changes for XIAO ESP32S3 + Wio-SX1262 (B2B kit) that should replace the current Heltec-style hardcoded mapping:
XIAO ESP32S3 SPI pins
SCK = GPIO7
MISO = GPIO8
MOSI = GPIO9
Wio-SX1262 (B2B) control pins
NSS/CS = GPIO41
DIO1 = GPIO39
RESET = GPIO42
BUSY = GPIO40
(optional) ANT_SW = GPIO38
The current firmware appears to assume a different board pinout (typical Heltec-style: NSS=8, SCK=9, MOSI=10, MISO=11, RST=12, BUSY=13, DIO1=14). On XIAO+Wio these lines are not wired that way, so early init can fail (lots of .unwrap()), or attaching DIO1 IRQ to the wrong/floating pin can cause an interrupt storm → watchdog reset, which looks like “doesn’t boot”.
Suggestion: add a board_xiao_wio profile/feature flag and move all pin mapping into a single pins module, plus avoid .unwrap() in early boot and only subscribe DIO1 IRQ after radio init succeeds.
Here are the concrete pin changes for **XIAO ESP32S3 + Wio-SX1262 (B2B kit)** that should replace the current Heltec-style hardcoded mapping:
### XIAO ESP32S3 SPI pins
- SCK = GPIO7
- MISO = GPIO8
- MOSI = GPIO9
### Wio-SX1262 (B2B) control pins
- NSS/CS = GPIO41
- DIO1 = GPIO39
- RESET = GPIO42
- BUSY = GPIO40
- (optional) ANT_SW = GPIO38
The current firmware appears to assume a different board pinout (typical Heltec-style: NSS=8, SCK=9, MOSI=10, MISO=11, RST=12, BUSY=13, DIO1=14). On XIAO+Wio these lines are not wired that way, so early init can fail (lots of `.unwrap()`), or attaching DIO1 IRQ to the wrong/floating pin can cause an interrupt storm → watchdog reset, which looks like “doesn’t boot”.
Suggestion: add a `board_xiao_wio` profile/feature flag and move all pin mapping into a single `pins` module, plus avoid `.unwrap()` in early boot and only subscribe DIO1 IRQ after radio init succeeds.
<!-- github-comment-id:3868781541 -->
Thank You very much for your detailed instructions. I ask myself: How exactly shall i do this bunch of changes? Shall i clone the repo and make changes there and built it afterwards?
Thank You very much for your detailed instructions. I ask myself: How exactly shall i do this bunch of changes? Shall i clone the repo and make changes there and built it afterwards?
<!-- github-comment-id:3885870313 -->
They are not confirmed, it's my assumption. Yes, I think you need to clone this repo, create a new branch, implement, compile. Once it works, you can do a PR.
They are not confirmed, it's my assumption. Yes, I think you need to clone this repo, create a new branch, implement, compile. Once it works, you can do a PR.
<!-- github-comment-id:3886053274 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
esptool --chip esp32s3 -p /dev/cu.usbmodem1CDBD4A894401 write-flash 0x0 ./lunar/lunarcore-esp32s3.bin
esptool v5.1.0
Serial port /dev/cu.usbmodem1CDBD4A894401:
Connecting.............
A serial exception error occurred: Could not configure port: (6, 'Device not configured')
Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Tried it again ...
esptool.py --chip esp32s3 -p /dev/cu.usbmodem101 write_flash 0x0 ./lunar/lunarcore-esp32s3.bin
Warning: DEPRECATED: 'esptool.py' is deprecated. Please use 'esptool' instead. The '.py' suffix will be removed in a future major release.
Warning: Deprecated: Command 'write_flash' is deprecated. Use 'write-flash' instead.
esptool v5.1.0
Connected to ESP32-S3 on /dev/cu.usbmodem101:
Chip type: ESP32-S3 (QFN56) (revision v0.2)
Features: Wi-Fi, BT 5 (LE), Dual Core + LP Core, 240MHz, Embedded PSRAM 8MB (AP_3v3)
Crystal frequency: 40MHz
USB mode: USB-Serial/JTAG
MAC: 1c:db:d4:a8:94:40
Stub flasher running.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x003fffff...
Wrote 4194304 bytes (602717 compressed) at 0x00000000 in 15.0 seconds (2239.4 kbit/s).
Hash of data verified.
Hard resetting via RTS pin...
rnodeconf /dev/cu.usbmodem101 --info
[00:03:08] Opening serial port /dev/cu.usbmodem101...
[00:03:12] Serial port opened, but RNode did not respond. Is a valid firmware installed?
Got invalid response while detecting device
meshtastic --port /dev/cu.usbmodem101 --info
-->
File "/Users/xx/.local/pipx/venvs/meshtastic/lib/python3.14/site-packages/meshtastic/mesh_interface.py", line 1111, in _waitConnected
raise MeshInterface.MeshInterfaceError(
"Timed out waiting for connection completion"
no connection with meshcore also
on it
same here. with the same hardware.
I've flashed successfully but then stuck after booting.
Opening the serial after booting. I got this every 30 seconds
Backtrace: 0x4205DF53:0x3FCA0C80 0x4037C7E9:0x3FCA0CB0 0x4037E85B:0x3FCCAFA0 0x4205D77D:0x3FCCAFC0 0x4038205B:0x3FCCAFE0.that's the watchdog timeout. I'm going to doublecheck the pin configuration and init code now
Here are the concrete pin changes for XIAO ESP32S3 + Wio-SX1262 (B2B kit) that should replace the current Heltec-style hardcoded mapping:
XIAO ESP32S3 SPI pins
Wio-SX1262 (B2B) control pins
The current firmware appears to assume a different board pinout (typical Heltec-style: NSS=8, SCK=9, MOSI=10, MISO=11, RST=12, BUSY=13, DIO1=14). On XIAO+Wio these lines are not wired that way, so early init can fail (lots of
.unwrap()), or attaching DIO1 IRQ to the wrong/floating pin can cause an interrupt storm → watchdog reset, which looks like “doesn’t boot”.Suggestion: add a
board_xiao_wioprofile/feature flag and move all pin mapping into a singlepinsmodule, plus avoid.unwrap()in early boot and only subscribe DIO1 IRQ after radio init succeeds.Thank You very much for your detailed instructions. I ask myself: How exactly shall i do this bunch of changes? Shall i clone the repo and make changes there and built it afterwards?
They are not confirmed, it's my assumption. Yes, I think you need to clone this repo, create a new branch, implement, compile. Once it works, you can do a PR.
Doesnt work with heltec v3 either. im giving up to fix the stuff...
I am using this XIAO ESP32S3 & Wio-SX1262 Kit kit https://thepihut.com/products/xiao-esp32s3-wio-sx1262-kit-for-meshtastic-lora?variant=53799857422721
And I get this output
Interestingly the meshcore.io firmware is also not working.
Edit: I was an idiot and connected the devices by the gpio rather than the grove port
With this kit it stalls on calling
app_main()https://thepihut.com/products/xiao-esp32s3-wio-sx1262-kit-for-meshtastic-lora?variant=53799857422721