First BLE connection fails after reboot phone/bluetooth (works only after scanning with another app) — nRF52840 + Zephyr vs ArduinoBLE

[Paolo S.]

Hello everyone,

I’m currently developing firmware on our custom board based on the nRF52840, using nRF Connect SDK v3.0.0 and Visual Studio Code.

The board is designed to communicate over BLE/GATT with our proprietary Android app (tested on Android 13 and 14).

The problem I’m facing is the following:
The first time I try to connect from our Android app — typically right after a phone reboot or after toggling Bluetooth off and on — the connection does not succeed (the app just stays in a waiting state).

However, if I then launch another app that scans for BLE devices (without even connecting), such as the nRF Connect app, and then close it, from that moment on our app can connect and reconnect without issues.

This issue does not happen when I flash our "old" firmware, which was developed in the Arduino environment using ArduinoBLE and mbed.
In that case, the app is able to connect immediately, under all conditions.

We are currently porting our firmware from Arduino to nRF Connect, so understanding this difference is critical.

I’ve tried multiple approaches but haven’t been able to resolve the issue.

Some observations:

• The firmware using nRF Connect advertises a MAC address: EA:5A:98:E2:7A:32 (random static)

• The firmware using ArduinoBLE advertises a MAC address: 6A:5A:98:E2:7A:32 (public)

• Using Wireshark, the ADV_IND packets differ mainly because of this

I’m attaching the prj.conf file.

# Abilita il logging di Zephyr
CONFIG_LOG=n
# Imposta il livello di log di default (3 per DBG, 2 for INF, 1 for WRN, 0 for ERR)
CONFIG_LOG_DEFAULT_LEVEL=3
# Usa il backend UART per i log (se vuoi visualizzarli su console seriale)
CONFIG_LOG_BACKEND_UART=n
# Se preferisci usare il console standard, puoi anche abilitare:
CONFIG_STDOUT_CONSOLE=n

CONFIG_GPIO=y

# Abilita printk
CONFIG_PRINTK=y

# abilita console
CONFIG_CONSOLE=y

# Abilita la console UART
CONFIG_UART_CONSOLE=y
CONFIG_STDOUT_CONSOLE=n

# Abilita console RTT
CONFIG_USE_SEGGER_RTT=n
CONFIG_LOG_BACKEND_RTT=n

# Configura la seriale
CONFIG_SERIAL=y

# Abilita il logging per il sottosistema Bluetooth
CONFIG_BT_LOG_LEVEL_WRN=n

CONFIG_MAIN_STACK_SIZE=4096

# Floating Point Unit
CONFIG_FPU=y


################################################################################
# Bluetooth LE
################################################################################
CONFIG_BT=y
CONFIG_BT_SMP=y
CONFIG_BT_BONDABLE=n
CONFIG_BT_CENTRAL=n
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_FIXED_PASSKEY=n
CONFIG_BT_FILTER_ACCEPT_LIST=n
CONFIG_SETTINGS=n
CONFIG_BT_PRIVACY=n
CONFIG_BT_ID_MAX=1
# Numero massimo di connessioni: per periferica, solitamente 1
CONFIG_BT_MAX_CONN=1
# Increase stack size for the main thread and System Workqueue
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_MAIN_STACK_SIZE=2048

# Configure your preferred connection parameters
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=20
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=35
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
# Timeout in milliseconds (un valore basso favorisce la rapidità di connessione ma potrebbe renderla instabile in ambienti rumorosi,
# quindi tra 100 (rapida) e 500 (stabile) (il default sarebbe 42) (non deve essere inferiore a (1 + latency) * max_int * 2))
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=75
#CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

# Update Data Length and MTU
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=247

# BT nome dispositivo
CONFIG_BT_DEVICE_NAME="LACS-DEVICE C.U."
CONFIG_BT_DEVICE_NAME_DYNAMIC=y

# Enable PHY updates.
CONFIG_BT_USER_PHY_UPDATE=y

# enable adv extended
CONFIG_BT_EXT_ADV=n


#################################################################################

# Use the c++ compiler
CONFIG_CPP=y

# Abilita il supporto per l'ADC
CONFIG_ADC=y

# Abilita il supporto per il driver ADC specifico della piattaforma (nRF SAADC per nRF52840)
CONFIG_ADC_NRFX_SAADC=y
CONFIG_NRFX_SAADC=y

# gestione NFC
CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_REBOOT=y
CONFIG_DK_LIBRARY=y
CONFIG_NFC_T2T_NRFXLIB=y
CONFIG_NFC_NDEF=y
CONFIG_NFC_NDEF_MSG=y
CONFIG_NFC_NDEF_RECORD=y
CONFIG_NFC_NDEF_TEXT_RECORD=y

# Abilitare ASSERT solo in modalità debug. Queste aumentano dimensioni e consumo di energia. in modalità release, non sono necessarie.
CONFIG_ASSERT=n

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_COUNTER=y

# TIMER 1 per gestione timer di scansione pin sensori per ricezione IR (il timer 0 non funziona probabilmente già usato da altro)
CONFIG_NRFX_TIMER3=y   

# --- build outputs ---
CONFIG_BUILD_OUTPUT_BIN=y
CONFIG_KERNEL_BIN_NAME="micro_nrfc_cu"  # opzionale: cambia nome file finale


#################################################################################

# Enable FOTA over Bluetooth LE
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

Feel free to ask for any additional details about the firmware, advertising structure, or Wireshark trace.

Thanks in advance!

Best regards,

Paolo

[Edvin]

Hello,

the connection does not succeed (the app just stays in a waiting state).

What app? The application running on the nRF52840, or the one running on your phone?

This sounds like an issue where a wireshark trace from the nRF Sniffer for Bluetooth LE might be useful. Can you please upload a .pcapng file from when the connection doesn't work (the app just stays in a waiting state), and one where the connection succeeds? 

Also, if you try the nRF Connect for Android/iOS, are you then able to reconnect after a phone reboot/toggling off->on the Bluetooth?

Best regards,

Edvin

[Paolo S.]

Hi Edvin,

I believe I’ve found a solution.
I was about to update the ticket when I saw your reply.

The app is our own application, running on an Android device (developed using Android Studio/Java).

After each Bluetooth restart on the Android device (either by rebooting the phone or restarting Bluetooth), the app wouldn’t connect to the nRF52840.

Unless we launched the nRF Connect app first or any other app that performs BLE device discovery.

The solution I found was to add, in our nRF52840 firmware
a call to the function bt_ctlr_set_public_addr(mac_addr) just before calling bt_enable(bt_ready),

with mac_addr[] set to the MAC address read from the NRF_FICR->DEVICEADDR registers.

....
...
mac_addr[0] = (NRF_FICR->DEVICEADDR[0] >> 0) & 0xFF;
mac_addr[1] = (NRF_FICR->DEVICEADDR[0] >> 8) & 0xFF;
mac_addr[2] = (NRF_FICR->DEVICEADDR[0] >> 16) & 0xFF;
mac_addr[3] = (NRF_FICR->DEVICEADDR[0] >> 24) & 0xFF;
mac_addr[4] = (NRF_FICR->DEVICEADDR[1] >> 0) & 0xFF;
mac_addr[5] = (NRF_FICR->DEVICEADDR[1] >> 8) & 0xFF;
...
..
bt_ctlr_set_public_addr(mac_addr);

err = bt_enable(bt_ready);
if (err)
{
...

With that call in place, Wireshark now shows the ADV_IND message with a PUBLIC MAC address instead of a STATIC RANDOM one.

Our Android app now connects successfully both the first time and on subsequent attempts.

While I'm at it, I’d like to ask: are there any implications or potential issues in forcing the MAC address from STATIC RANDOM to PUBLIC?

Thank you for your support,

best regards
Paolo

[Edvin]

Paolo S. said:

While I'm at it, I’d like to ask: are there any implications or potential issues in forcing the MAC address from STATIC RANDOM to PUBLIC?

One difference is that a public MAC address should never change during the lifetime of the device. This is according to the Bluetooth specification. 

Another thing is that in order to use a public MAC address, you need to purchase a public address pool from IEEE. If you don't, you are not allowed to use public MAC addresses (That applies for Arduino as well).

It still isn't clear to me why you were not able to connect to the device without using a public address. But I don't know what sort of devices your app was looking for. An advertising name? A particular advertising address? An UUID?

Was the peripheral at all advertising before you set the address to a public address?

Best regards,

Edvin

[Paolo S.]

Hi Edvin,
one of our Android apps was unable to connect on the first attempt (after a BLE stack reset) to our custom nRF52840 board running firmware based on nRF Connect / Zephyr.

When we flashed the Arduino-based firmware on the same board, the issue did not occur.

The only difference between the two ADV_IND packets was the MAC address type: PUBLIC (Arduino) vs. STATIC RANDOM (Zephyr).
By forcing the Zephyr version to use a PUBLIC address, the connection now works as well.

The app attempts to connect directly using the MAC address.

"Was the peripheral at all advertising before you set the address to a public address?"

No, the peripheral always starts advertising only after calling bt_enable().

Unfortunately, the exact cause is still unclear — it might be something on the Android app side, but I plan to investigate further later on.
For now, it’s working.

Thanks, Edvin.
Best regards,