Title: SoftDevice Controller: 100% connection establishment failure (HCI 0x3E) with SKY66112-11 PA active
Hi Everyone,
I am working on the following development project for production. We are using the Fanstel USB840X dongle for long-range
communication. However, when we activate the PA, we are unable to establish a connect to the our BT device. Scanning works
fine but the connection fails on every attempt. The details are described below.
Hardware/software:
- nRF52840 (Fanstel USB840X dongle) as BLE central, USB-connected to an NVIDIA Jetson Orin Nano running BlueZ 5.72
- Skyworks SKY66112-11 FEM (PA/LNA), 2-pin Simple GPIO FEM implementation
- nRF Connect SDK v2.7.0, board target nrf52840dongle_nrf52840, application based on the hci_usb sample
- CONFIG_BT_LL_SOFTDEVICE=y (SoftDevice Controller), CONFIG_MPSL_FEM=y, CONFIG_MPSL_FEM_SIMPLE_GPIO=y, CONFIG_BT_CTLR_TX_PWR_0=y (SoC radio capped to 0 dBm, all gain from the FEM), CONFIG_BT_CTLR_PHY_CODED=y, CONFIG_BT_CTLR_ADV_EXT=y
- Peripheral: a TI CC2652P BLE5-Stack device, co-located with the central (no distance/range factor in any test below)
Symptom:
With the FEM's PA path active, every BLE connection attempt fails, 100% of the time, across many independent test runs (40+ attempts total). The sequence is always: LE Extended Create Connection succeeds, LE Enhanced Connection Complete reports Status: Success, and then consistently ~250–252 ms later — 5 connection events at a 50 ms interval, standard deviation under 1 ms across dozens of trials — the controller issues Disconnect Complete, Reason: Connection Failed to be Established (0x3E). No ACL data, ATT traffic, or LE Read Remote Used Features Complete event is ever received in any failed attempt.
Isolation testing (peripheral co-located with the central in every test, so distance/link-margin is not a factor):
- USB840X, PA active (CONFIG_MPSL_FEM=y): 10/10 connection attempts fail with 0x3E, every time. RSSI to the peripheral has ranged -44 to -91 dBm across different runs — always a strong, healthy signal, never marginal.
- USB840X, PA bypassed (CONFIG_MPSL_FEM=n): connects successfully on the first attempt, with full GATT discovery, MTU exchange, and DLE negotiation completing normally.
- Native nRF52840 hci_usb build with no FEM at all: connects successfully against the same peripheral, in the same location.
- Native Jetson onboard BLE radio (Realtek, unrelated hardware entirely): also connects successfully against the same peripheral, in the same location.
Since the failure is identical across a wide RSSI range, occurs on essentially every attempt regardless of distance, and disappears entirely with the FEM/PA path disabled, this points to a Link Layer synchronization failure specific to the FEM-active path, not a link-margin or peripheral-side issue.
What's already been ruled out, with direct evidence for each:
1. RF link margin / distance: RSSI -44 to -91 dBm across all tests, no correlation with failure; native radios connect fine at the same or worse RSSI.
2. Malformed Initiating PHYs (dual 1M+2M) request: tested with Initiating PHYs forced to 0x01 (1M only) — failure unchanged.
3. CONFIG_MPSL_FEM not compiled in: confirmed CONFIG_MPSL=y, CONFIG_MPSL_FEM=y, CONFIG_MPSL_FEM_SIMPLE_GPIO=y are explicitly set and present in the resolved .config.
4. ctx-settle-time-us / crx-settle-time-us too short: confirmed Nordic's stock defaults (23 us / 5 us) are compiled in unmodified, then tested at 2x (46 us / 10 us) — failure timing and rate were completely unchanged (same 251-252 ms disconnect, same 100% failure rate), which argues against a settle-time margin shortfall as the limiting factor.
5. CPS/CHL left floating: our board's schematic (from the module vendor) shows CPS and CHL routed to nRF52840 GPIOs (P0.06 and P0.08) rather than hardwired, but the 2-pin Simple GPIO FEM implementation only drives CTX/CRX. We added explicit csd-gpios/cps-gpios/chl-gpios properties to the FEM devicetree node (confirmed compiled in via devicetree_generated.h, correct pins and polarity) to hold CPS low and CHL high per the SKY66112-11's mode control table — failure was completely unchanged.
6. CSD strapping: hardwired high via a 10 kOhm pull-up on the board; against the datasheet's 1 uA max control-pin leakage this is guaranteed to sit at a valid logic high regardless of component tolerance, so ruled out analytically.
Given all of the above, the remaining variable we can't inspect or test further from our side is the SoftDevice Controller's own internal Link Layer scheduling of the FEM around connection establishment specifically (as opposed to steady-state TX/RX, which appears to work — PA-bypass and non-FEM builds both connect and stream data without issue).
/*
* USB840X / BT840X module — SKY66112-11 PA/LNA devicetree overlay
* NCS v2.7.0 / Zephyr 3.6.99
*
* Label: nrf_radio_fem ← this is what &radio references
* PA → nRF52840 P0.17 (APP_PA_PIN / CTX)
* LNA → nRF52840 P0.19 (APP_LNA_PIN / CRX)
*
* Configuration enables the PA
*/
/ {
nrf_radio_fem: sky66112_fem {
compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
ctx-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
crx-gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
cps-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
chl-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
ctx-settle-time-us = <46>; /* 2x Nordic's default of 23 */
crx-settle-time-us = <10>; /* 2x Nordic's default of 5 */
};
};
&radio {
fem = <&nrf_radio_fem>;
};
# Nordic SoftDevice Controller (production quality, replaces experimental Zephyr LL) CONFIG_BT_LL_SOFTDEVICE=y # Coded PHY (LE Long Range S=8) — supported natively by SoftDevice Controller CONFIG_BT_CTLR_PHY_CODED=y CONFIG_BT_CTLR_ADV_EXT=y # Disable MPSL FEM support for SKY66112-11 PA/LNA (Disable for Lab Testing) #CONFIG_MPSL_FEM=n # MPSL FEM support for SKY66112-11 PA/LNA (Enable for Field/Production) CONFIG_MPSL=y CONFIG_MPSL_FEM=y CONFIG_MPSL_FEM_SIMPLE_GPIO=y # Cap nRF52840 SoC Internal Radio Power to 0 dBm to prevent PA saturation CONFIG_BT_CTLR_TX_PWR_0=y # Data Length Extension — 251-octet LL PDU (BLE > 5.0 ) CONFIG_BT_CTLR_DATA_LENGTH_MAX=251 CONFIG_BT_BUF_ACL_TX_SIZE=255 CONFIG_BT_BUF_ACL_RX_SIZE=255
My Questions:
1. Is there a known interaction between CONFIG_MPSL_FEM_SIMPLE_GPIO and the SoftDevice Controller's connection-establishment timing specifically (as distinct from steady-state connection operation), on nRF Connect SDK v2.7.0?
2. Is the connection-establishment timeout that produces 0x3E (distinct from the negotiated supervision timeout) affected by FEM ramp-up/ramp-down scheduling in a way that isn't captured by the ctx-settle-time-us / crx-settle-time-us devicetree properties?
3. Are there known SoftDevice Controller versions/errata relevant to FEM + connection establishment that might explain a 100%, RSSI-independent failure rate that disappears entirely with the FEM disabled?
Happy to share full btmon captures for both the failing and working configurations, our devicetree/Kconfig files, or reproduce with any additional instrumentation you'd suggest.
Thanks, and I appreciate your assistance.