cancel
Showing results for 
Search instead for 
Did you mean: 

BLE: intermittent connect, repeated disconnect reason 0x3E during connection attempts

BadreddineNebhen
Associate

 

Hi ST Community,

I’m working with STM32WBA (STM32WPAN / BlueNRG-style stack APIs). I’m using Extended Advertising on the peripheral (connectable + scannable, secondary PHY = Coded) and a STM32WBA central that scans and then calls aci_gap_create_connection().

Problem
Connection is intermittent: sometimes it connects, but often the peripheral prints multiple times:

HCI_DISCONNECTION_COMPLETE_EVT_CODE
- Connection Handle: 0x01
- Reason: 0x3E
(repeats 4–5 times)

The central does retries very often, so the peripheral sees repeated disconnect events before it finally connects.

Setup details

Peripheral (Extended Advertising)

  • Advertising set configured as connectable + scannable:

    • u16Property = HCI_ADV_EVENT_PROP_CONNECTABLE | HCI_ADV_EVENT_PROP_SCANNABLE;

  • Primary PHY = 1M, Secondary PHY = Coded (0x03):

    • aci_gap_adv_set_configuration(..., primaryPHY=0x00, secondaryPHY=0x03, ...)

  • Address type used in advertising set:

    • u8AddressType = GAP_STATIC_RANDOM_ADDR;

  • Advertising channels 37/38/39 enabled

  • TX power set via aci_hal_set_tx_power_level(1, CFG_TX_POWER)

Central (Extended Advertising enabled)

  • Scan finds target via HCI_LE_EXTENDED_ADVERTISING_REPORT_SUBEVT_CODE

  • Central then calls aci_gap_create_connection()

Here is the current connect code (simplified):

result = aci_gap_create_connection(
    SCAN_INT_MS(500), SCAN_WIN_MS(500),
    GAP_STATIC_RANDOM_ADDR,       // Peer_Address_Type  <-- (my current code)
    g_nSelection.pu8TargetAdr,
    CFG_BD_ADDRESS_TYPE,          // Own_Address_Type
    CONN_INT_MS(7.5), CONN_INT_MS(7.5),
    0,
    u16ConnSupTimeout,
    CONN_CE_LENGTH_MS(10), CONN_CE_LENGTH_MS(10)
);

I also tried less aggressive intervals (e.g. Min 30 ms, Max 250 ms) and it got “better”, but the repeated 0x3E disconnect still happens sometimes.

Questions

  1. For Extended Advertising connections, should the central use the peer address type from the advertising report (public/random) instead of constants like GAP_STATIC_RANDOM_ADDR?

    • My suspicion: I’m misusing Peer_Address_Type (should be 0=public / 1=random), and sometimes the stack interprets the peer address type incorrectly, leading to fast failure/disconnect reason 0x3E.

  2. Is there a recommended stable set of parameters for:

    • LE_Scan_Interval / LE_Scan_Window during connection establishment

    • Conn_Interval_Min / Max for LE Coded / extended advertising

    • Minimum_CE_Length / Maximum_CE_Length (should these be 0?)

  3. Any known issue/errata with STM32WBA + Extended Advertising + Coded PHY that can cause repeated disconnect reason 0x3E during initial connection?

Additional info

  • Peripheral prints repeated disconnect reason 0x3E before a successful connection happens.

  • Central is retrying connection frequently.

  • Addresses themselves look correct (I see the target address from scan and use it for connect).

Any guidance on correct use of aci_gap_create_connection() with Extended Advertising (especially peer address type handling) and recommended parameters would be greatly appreciated.

Thanks!

1 REPLY 1
_Joe_
ST Employee

Hi,
 

From what you describe, the repeated 0x3E (Connection Failed to be Established) on the peripheral side is most often related to a noisy RF environment.

  • Do you have the possibility to test in a quieter RF environment (e.g. shielded box, ...) to see if the 0x3E rate drops?
  • Do you have an approximate failure rate (e.g. “X times 0x3E over Y connection attempts”)? 
  • If you can capture an air trace, you will confirm that when problem occurs, the CONNECT_IND is sent, another packet from a different device is received in the same time window (for example, another advertiser being scanned), so the connection cannot be completed, and you end up with 0x3E.

I also notice you are using aci_gap_create_connection() rather than aci_gap_ext_create_connection(). If this is not intentional ? it may be worth checking.
 

By the way, there are reference examples you can rely on if needed:

Peripheral: BLE_p2pServer_Ext
https://github.com/STMicroelectronics/STM32CubeWBA/tree/main/Projects/NUCLEO-WBA65RI/Applications/BLE/BLE_p2pServer_Ext

Central: BLE_p2pClient_Ext
https://github.com/STMicroelectronics/STM32CubeWBA/tree/main/Projects/NUCLEO-WBA65RI/Applications/BLE/BLE_p2pClient_Ext

BR, Joé