BLE Crash
Port, board and/or hardware
esp32, esp32-s3
MicroPython version
MPY version : v1.26.0 on 2025-08-09
IDF version : v5.4.2
Machine : Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
Reproduction
- Install micropython 1.24 or 1.26
- Install octopuslab helpers for bluetooth, so you do not need to write whole bluetooth stack from scratch
- https://github.com/octopuslab-cz/esp32_micropython_framework/blob/main/lib/blesync_uart/server.py
- install example https://github.com/octopuslab-cz/esp32_s3_robotics/blob/main/iot/test_ble_led.py
run it
bluetooth device will appear, connect there from Blefruit Connect app
Try for to send something. Micropython will crash..
do not know which version was last where it works. probably around 1.18 or something
Expected behaviour
Working UART bluetooth/ble service and not crashing micropython.
Or at least some useful error message if helper code needs to be updated.
Observed behaviour
Stack trace
~/.e/t/x/e/x/bin> ./xtensa-esp32s3-elf-addr2line -pfiaC -e ~/down/ESP32_GENERIC_S3-SPIRAM_OCT-20250809-v1.26.0.elf 0x4202a18a:0x3fcb4670 0x42034943:0x3fcb4690 0x40379e81:0x3fcb46f0 0x4202c8ff:0x3fcb4790 0x42034291:0x3fcb4800 0x42034319:0x3fcb4820 0x42034fd8:0x3fcb4850 0x42035225:0x3fcb48d0 0x42024685:0x3fcb4900 0x42044491:0x3fcb4920 0x42044d9f:0x3fcb4940 0x42024220:0x3fcb4980
0x4202a18a: mp_obj_get_type at /home/micropython/micropython-autobuild/py/obj.c:69
(inlined by) mp_obj_len_maybe at /home/micropython/micropython-autobuild/py/obj.c:563
0x42034943: mp_call_prepare_args_n_kw_var at /home/micropython/micropython-autobuild/py/runtime.c:777
(inlined by) mp_call_method_n_kw_var at /home/micropython/micropython-autobuild/py/runtime.c:951
0x40379e81: mp_execute_bytecode at /home/micropython/micropython-autobuild/py/vm.c:1030
0x4202c8ff: fun_bc_call at /home/micropython/micropython-autobuild/py/objfun.c:295
0x42034291: mp_call_function_n_kw at /home/micropython/micropython-autobuild/py/runtime.c:727
0x42034319: mp_call_function_1 at /home/micropython/micropython-autobuild/py/runtime.c:705
0x42034fd8: mp_call_function_1_protected at /home/micropython/micropython-autobuild/py/runtime_utils.c:33
0x42035225: mp_sched_run_pending at /home/micropython/micropython-autobuild/py/scheduler.c:115
(inlined by) mp_handle_pending at /home/micropython/micropython-autobuild/py/scheduler.c:250
0x42024685: mp_hal_stdin_rx_chr at /home/micropython/micropython-autobuild/ports/esp32/mphalport.c:141
0x42044491: readline at /home/micropython/micropython-autobuild/shared/readline/readline.c:560
0x42044d9f: pyexec_friendly_repl at /home/micropython/micropython-autobuild/shared/runtime/pyexec.c:606 (discriminator 1)
0x42024220: mp_task at /home/micropython/micropython-autobuild/ports/esp32/main.c:166
Code
import ble_led
---> BLE - led
This is simple Micropython example | ESP32 & octopusLAB
BLE ESP32 device name: octopus-led-68d50
@blesync_server.on_connect
A fatal error occurred. The crash dump printed below may be used to help
determine what caused it. If you are not already running the most recent
version of MicroPython, consider upgrading. New versions often fix bugs.
To learn more about how to debug and/or report this crash visit the wiki
page at: https://github.com/micropython/micropython/wiki/ESP32-debugging
MPY version : v1.26.0 on 2025-08-09
IDF version : v5.4.2
Machine : Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x4202a18d PS : 0x00060730 A0 : 0x82034946 A1 : 0x3fcb4670
A2 : 0x3fcd39a0 A3 : 0x3fcb47a4 A4 : 0x00000004 A5 : 0x00000000
A6 : 0x3fcb6b30 A7 : 0x00000001 A8 : 0x3c160154 A9 : 0x8206c3f0
A10 : 0x3fcbcae0 A11 : 0x3fcd39a0 A12 : 0x00000000 A13 : 0x3fcb74a4
A14 : 0x3fcbc3b0 A15 : 0x3fcb4b08 SAR : 0x00000013 EXCCAUSE: 0x0000001c
EXCVADDR: 0x8206c3fb LBEG : 0x42034ca1 LEND : 0x42034caa LCOUNT : 0x00000000
Backtrace: 0x4202a18a:0x3fcb4670 0x42034943:0x3fcb4690 0x40379e81:0x3fcb46f0 0x4202c8ff:0x3fcb4790 0x42034291:0x3fcb4800 0x42034319:0x3fcb4820
0x42034fd8:0x3fcb4850 0x42035225:0x3fcb48d0 0x42024685:0x3fcb4900 0x42044491:0x3fcb4920 0x42044d9f:0x3fcb4940 0x42024220:0x3fcb4980
ELF file SHA256: 33ce41e10
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
ESP32: Ctrl-C from examples/bluetooth/ble_uart_repl.py does not interrupt user code; only the BLE REPL loop stops
Port, board and/or hardware
esp32 port, tested on ESP32C3 ESP32C6 and ESP32
MicroPython version
MicroPython v1.25.0 on 2025-04-15; ESP32C6 module with ESP32C6 but problem persist in older versions
Summary
When using the official examples/bluetooth/ble_uart_repl.py on ESP32, sending Ctrl-C (0x03) over BLE does not raise KeyboardInterrupt in a running user program. Instead, the BLE REPL itself stops or returns to the prompt while the user code keeps running. The same Ctrl-C works as expected over USB serial REPL.
Environment
- Firmware: MicroPython v1.25.0 (build date 2025-04-15)
- Boards tested: ESP32-C3 SuperMini, ESP32-C6 SuperMini and ESP32 Dev Board
- Host: Windows 10 Chrome (Web Bluetooth), Android Adafruit Bluefruit LE Connect
Reproduction
Copy the three example files to the ESP32.
change:
self._payload = advertising_payload(name=name, appearance=_ADV_APPEARANCE_GENERIC_COMPUTER)
to
self._payload = advertising_payload(name=name, services=[_UART_UUID])
in ble_uart_peripheral.py because online terminals not working without NUS characteristics
Start BLE REPL:
import ble_uart_repl
ble_uart_repl.start()
Now you can connect to device. For example using https://repl.siliconwitchery.com/
Paste simple code into terminal
import utime
i = 0
for i in range(1, 1000):
utime.sleep_ms(0)
print(i)
utime.sleep_ms(10)
And try to stop code by sending CTRL+C, sometimes code stop correctly, but sometimes BLE Code stop working and numbers still counting.
Expected behaviour
KeyboardInterrupt is raised in the running user loop and execution stops, matching USB serial REPL behavior.
Observed behaviour
The BLE REPL appears to stop working but the user loop continues printing. Ctrl-C does not interrupt the user program. A hard reset is required to stop it.
Additional Information
What we tried
- Verified that USB serial REPL on the same firmware raises KeyboardInterrupt as expected.
- Verified the central does send a single 0x03 byte to the RX characteristic.
Technicaly same code without one line of code works much better, why ?
import utime
i = 0
for i in range(1, 1000):
print(i)
utime.sleep_ms(10)
utime.sleep_ms(0) before print making a huge difference but code is still not 100% reliable
Code of Conduct
Yes, I agree