fix(core): do not wait for nRF to come up in emulator
What the developer wrote
Authored by matejcik
fix(core): do not wait for nRF to come up in emulator
What changed, and why it matters
This is a tiny developer-experience fix for the Trezor hardware wallet emulator (a software simulator used for testing). It stops the emulator from waiting up to 5 seconds for the Bluetooth chip to report it is ready, because the emulator has no real Bluetooth chip. There is no security issue here.
No security action needed. Treat as a normal development/testing fix.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In core/src/ble.py, the startup loop waits up to 5 seconds for ble.is_started() to become true. In the emulator, there is no nRF Bluetooth controller, so the loop would always wait the full timeout. The patch adds utils.EMULATOR to the condition so the loop exits immediately when running under the emulator. This is a build/test-only change with no effect on real device firmware or cryptographic operations.
Changed components
core/src/ble.pyInspect captured patch +2 / −2
diff --git a/core/src/ble.py b/core/src/ble.py
index 053036df9..d9a0c7e22 100644
--- a/core/src/ble.py
+++ b/core/src/ble.py
@@ -5,7 +5,7 @@ import utime
import storage.device
import trezorble as ble
-from trezor import log
+from trezor import log, utils
try:
ble.start_comm()
@@ -13,7 +13,7 @@ try:
start_ms = utime.ticks_ms()
while utime.ticks_diff(utime.ticks_ms(), start_ms) < 5000:
- if ble.is_started():
+ if utils.EMULATOR or ble.is_started():
break
# allow connections from bonded peers if any
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.