Environment
- SDK: DW3_QM33_SDK 1.1.1 (FreeRTOS), custom app forked from the CLI
example - Hardware: DWM3001CDK (nRF52833 + DW3110), several boards
- Coexistence: SoftDevice s113 7.2.0 active (BLE peripheral,
advertising; wedge occurs with and without an active BLE connection;
not yet tested with the SoftDevice fully disabled) - UWB config: FiRa DS-TWR, one-to-many, channel 9, block 200 ms,
round 12 slots, round hopping ON, SP0, one controller (initiator)
session per “tag” device against responder devices running multiple
concurrent responder sessions (the SDK’s experimental multisession)
Symptom
A controller session that has been ranging normally (SUCCESS results at
5 Hz) stops producing ranging rounds silently:
- Last
SESSION_INFO_NTFis a healthy SUCCESS measurement; then nothing. - No
SESSION_STATUS_NTF— no state change, no reason code is ever
delivered. - The device is otherwise fully healthy: CLI responsive, all FreeRTOS
tasks alive (includingllhw_mcpsand bothqworkqueuetasks — see
THREAD dump below), heap ~50% free, no fault, no reset. - Responder-side view confirms the controller genuinely stops
transmitting (all its blocks time out from that moment). - Responder (multisession) devices have never exhibited the wedge —
controllers only.
Task snapshot taken while wedged (CLI THREAD):
THREAD NAME Stack usage
Control 1992/2048
usbpump 276/1024
IDLE 100/516
Default 3212/4304
Flush 204/512
Tmr Svc 140/516
qworkqueue 1996/3072
llhw_mcps 1032/2052
BLE 416/4096
qworkqueue 172/3072
Total HEAP 51200
Current HEAP used 24792
Max HEAP used 26232
Frequency / statistics (overnight scripted bench, deaths.csv attached)
Two boards, identical firmware, ~1 m from the responder, supervised by a
script that detects console silence (45 s), captures the state above,
then recovers and restarts (times below are session uptime at wedge):
| Board | Wedge intervals observed | Approx. MTBF |
|---|---|---|
| Board A (older, heavily used) | 251 s, 330 s, 346 s, 441 s, 467 s, 1616 s (+2 pre-bench) | 5–27 min |
| Board B | 514 s, 3808 s, 14203 s | ~1–4 h |
The dramatic board-to-board skew on identical firmware suggests a
hardware-marginal unit amplifying a rare race, but the failure also
occurs (rarely) on the healthy board.
Ruled out by experiment
- Out of range / retry exhaustion — occurs 1 m from the responder,
and a retry-limit stop would deliver aSESSION_STATUS_NTF. - BLE connection activity — occurs with no central connected.
- Session ID / “slot” specificity — boards were swapped between
session IDs; the failure follows the board, not the session. - Two-controller airtime collisions — occurs with a single
controller session running solo (started solo, no other controller
powered). - Timer wrap periodicity — intervals show no 512 s (RTC 24-bit @
32 kHz) or other periodic structure.
Workaround (verified in firmware against a live wedge)
Full session teardown and restart is 100% effective — 10/10 recoveries
(9 via an external script issuing stop/re-provision over the console,
1 via the in-firmware watchdog described below catching a live wedge).
Notably, uwbmac_stop / fira_helper_stop_session /
fira_helper_deinit_session / fira_helper_close /
fira_uwb_mcps_deinit all return success on the wedged session — the
stack does not know it is wedged.
Production mitigation now deployed: an application watchdog monitors the
ranging-results callback (which fires on every block, including all-miss
blocks, so out-of-range does not trigger it). If it goes silent for 15 s
while the session should be active, the app terminates and restarts the
session. Measured end-to-end against a real wedge: detection at 15.6 s,
session INIT→IDLE→ACTIVE and ranging resumed <1 s later (~16 s total
outage). This makes the defect survivable, but the underlying
controller stall remains and the silent nature (no SESSION_STATUS_NTF)
makes it invisible to any application not running such a watchdog.
Questions
- Is this a known issue in the R12.x MAC (controller-side ranging-round
scheduling stopping without a session state change)? - Is there a diagnostic we can enable/read at wedge time
(uwbmac/llhw state dump) that would localize this further for you? - Is a newer uwbstack drop available for SDK 1.1.1 that addresses
controller stalls?
I have attachments I can share (the external supervisor script I used and session logs) but I’m too new of a user to upload anything I guess.