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