XIAO nRF54LM20A: BLE advertising reports success but is never detected by a real scanner

[lboue]

Summary

BLE advertising reports success at every software layer (host stack bt_enable(), bt_le_adv_start(), and the Zephyr shell's bt advertise on), but the device is never actually detected by a real BLE scanner, even at close range and with a scanner independently confirmed to be working (it finds ~27 other nearby BLE devices in the same scan).

Hardware / setup

• Board: Seeed XIAO nRF54LM20A
• Built against upstream zephyrproject-rtos/zephyr main (this board isn't in any tagged Zephyr release or in nrfconnect/sdk-zephyr yet)
• Flashed via west flash (OpenOCD/CMSIS-DAP), with the RRAM write-buffer fix from boards: xiao_nrf54lm20a: commit RRAM write-buffer after flash load #59 applied locally (otherwise flashing itself is unreliable -- see that issue)

Reproduction

Two independent apps show the same symptom:

1. ESPHome's zephyr_ble_server component (a thin wrapper around bt_enable() + bt_le_adv_start()):

[I][zephyr_ble_server:050]: Advertising successfully started
[C][zephyr_ble_server:291]: ble server:
  connected: NO
  name: xiao-nrf54lm20a-test
  appearance: 0
  ready: YES

2. Zephyr's own tests/bluetooth/shell sample, built directly (bypassing ESPHome entirely) with:

west build -b xiao_nrf54lm20a/nrf54lm20a/cpuapp tests/bluetooth/shell -- \
  -DCONFIG_BT_CTLR_DTM_HCI=y \
  -DCONFIG_CLOCK_CONTROL_NRF_HFINT_CALIBRATION=y \
  -DCONFIG_BT_CTLR_ASSERT_OPTIMIZE_FOR_SIZE=n

Shell session:

uart:~$ bt id-show
*0: DF:04:FB:9B:C9:2F (random)
uart:~$ bt advertise on
Advertising started
uart:~$ bt test_tx 0 ff 0 1
test_tx...
uart:~$ bt test_end
num_rx= 0.

No crash, no ASSERTION FAIL (ruling out the historical GRTC/DTM timing bug fixed by zephyrproject-rtos/zephyr#100819 for bt test_tx specifically).

Scan side: a USB BLE dongle (hci0, confirmed working -- bluetoothctl scan on found ~27 real nearby devices including named ones) never shows the board's own address (DF:04:FB:9B:C9:2F) or name (xiao-nrf54lm20a-test / the shell's default test shell), across multiple 12-15s scans, with advertising confirmed still running (bt advertise on a second time returns err -120 = EALREADY, i.e. it never stopped).

Also tried with the board placed ~5 cm from the dongle (point-blank range) -- still zero detection, re-confirming advertising was still active at the time. This close-range result is why hardware defect is starting to look more likely than a driver/scheduling bug: even a badly mismatched antenna would typically still leak some signal detectable at 5 cm.

What's been ruled out

Checked the generated .config for the DTM shell build -- nothing looks misconfigured:

• CONFIG_BT_CTLR_TX_PWR_0=y, CONFIG_BT_CTLR_TX_PWR_DBM=0 -- normal, not attenuated
• CONFIG_BT_LL_SW_SPLIT=y, CONFIG_BT_LLL_VENDOR_NORDIC=y -- correct open-source Nordic LL controller selected
• CONFIG_DT_HAS_NORDIC_NRF54L_HFXO_ENABLED=y -- matches the board's own devicetree (&hfxo { status = "okay"; ... })
• No clock/radio warnings or errors anywhere in the boot log

Open question

Two possibilities I can't distinguish between without a spectrum analyzer or a second BLE-capable device:

1. A radio-scheduling bug specific to real advertising (distinct from bt test_tx's DTM path, which completes without crashing but can't be independently confirmed to radiate either -- DTM bursts aren't valid advertising PDUs so a scanner wouldn't show them regardless).
2. A hardware defect on this specific unit (e.g. an antenna/RF-trace issue) -- everything that doesn't touch the RF front-end (IMU over I2C, GPIO/LED, USB serial console, the DTM command executing without error) works fine, which is exactly what you'd expect if the antenna path itself were the problem rather than the software stack.

Posting here first since this is the board support repo and others with a second unit (or a spectrum analyzer) may be able to tell quickly which of the two it is. Happy to provide more logs/builds on request.

[lboue]

Update: connected the antenna I'd missed earlier, but BLE advertising is still not detected by the scanner (re-verified: scanner confirmed working with 28 other real nearby devices found in the same scan window; the board's address confirmed still actively advertising via err -120/EALREADY).

However, I separately validated OpenThread on this same board -- joins a real Thread network as an MTD child, gets mesh-local/on-mesh/link-local IPv6 addresses, SRP/mDNS registers successfully. OpenThread (802.15.4) uses the exact same physical radio and antenna path as BLE on this SoC, and it clearly works end-to-end (joining a mesh network requires real bidirectional RF, not just a local success log).

That's a strong signal this is not an antenna/RF hardware problem after all, and points back toward a BLE-stack-specific software bug (radio scheduling/timing, or similar) instead. Antenna hypothesis effectively ruled out.

[cumin777]

Thanks for the detailed report. We tested the Zephyr Bluetooth shell on a known-good Seeed Studio XIAO nRF54LM20A and could not reproduce the missing-advertising behavior.
Test environment:

• Board: Seeed Studio XIAO nRF54LM20A (xiao_nrf54lm20a/nrf54lm20a/cpuapp)
• Zephyr: v4.4.0, from our framework-zephyr-nrf54lm20 release package (3.40400.260428)
• Application: Zephyr tests/bluetooth/shell
• Bluetooth controller: Zephyr open-source Nordic LL controller, not SoftDevice Controller
• Generated controller configuration:

CONFIG_BT_LL_SW_SPLIT=y
CONFIG_BT_LLL_VENDOR_NORDIC=y
CONFIG_BT_CTLR_NRF_GRTC=y
CONFIG_BT_CTLR_DTM=y
CONFIG_CLOCK_CONTROL_NRF_HFINT_CALIBRATION=y
CONFIG_BT_CTLR_TX_PWR_0=y
CONFIG_BT_CTLR_TX_PWR_DBM=0

• Additional build options:

CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_CLOCK_CONTROL_NRF_HFINT_CALIBRATION=y
CONFIG_BT_CTLR_ASSERT_OPTIMIZE_FOR_SIZE=n

The test sequence was:

bt init
bt id-show
bt advertise on

The board reported:

The advertising device was detected by a phone scanner and a BLE connection completed successfully.

Based on this result, we are unable to reproduce the reported behavior in the Zephyr environment.
You also mentioned that OpenThread was validated on the same hardware, which suggests that the radio hardware and antenna path should be functional. Could you please provide the OpenThread application, its complete configuration files (prj.conf, overlays, generated .config, and zephyr.dts), and the exact test procedure/logs? This will help us verify the configuration and compare the two radio paths.
If possible, please also repeat the same Bluetooth shell test on another XIAO nRF54LM20A unit.