FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

FP-SNS-BLEMESH1 PB-ADV provisioning issues on STEVAL-MKBOXPRO

NOUR11
Associate

‎2026-05-20 4:51 PM - last edited on ‎2026-05-22 3:07 AM by

Hello,

I am testing FP-SNS-BLEMESH1 on two STEVAL-MKBOXPROA boards.

Setup:

  • Board: STEVAL-MKBOXPRO A

  • Firmware: BlueNRG-Mesh Sensor Demo v2.1.3

  • Library: BlueNRG-Mesh Library v01.14.000

  • Bearer: PB-ADV

  • One board configured as Embedded Provisioner

  • One board configured as Sensor Node (unprovisioned device)

Issue #1 – Embedded Provisioner cannot discover unprovisioned node

The provisioner starts scanning correctly, but no unprovisioned device is found.

At scan step, the console reports that no unprovisioned device is nearby, even when the second board is physically next to the provisioner.

The sensor node logs show:

DIAG: PB_ADV_SUPPORTED=1 PB_GATT_SUPPORTED=1 BEARER_INFO=3

Unprovisioned device

BlueNRG-Mesh Sensor Demo v2.1.3
BlueNRG-Mesh Library v01.14.000

BLE Stack Initialized & Device Configured

So the node appears to advertise correctly as unprovisioned.

Issue #2 – ST BLE Mesh mobile app crashes/stops after provisioning

Since Embedded Provisioner could not discover the node, I switched to the ST BLE Mesh mobile application.

With the mobile app:

  • the node is detected correctly,

  • provisioning starts,

  • provisioning appears to succeed,

Logs:

ATT mtu exchanged with value = 247

Appli_BleUnprovisionedIdentifyCb - Unprovisioned Node Identifier received: 0a

BluenrgMesh_ProvisionCallback - Device is provisioned by provisioner

After the message:

BluenrgMesh_ProvisionCallback - Device is provisioned by provisioner

nothing else is printed for some time

At this point:

  • the mobile application never completes mesh configuration,

  • the node does not become operational,

  • the configuration phase appears stuck or crashes immediately after provisioning.

Additional notes:

  • I tested the official ST binary as well.

  • Same behavior occurs with the official firmware.

  • PB-ADV was used.

  • Two official STEVAL-MKBOXPRO boards were used.

Questions:

  1. Is Embedded Provisioner mode fully supported and validated on STEVAL-MKBOXPRO in FP-SNS-BLEMESH1 v2.1.3?

  2. Are there known issues where unprovisioned beacons are not detected by the Embedded Provisioner scan module in this firmware version?

  3. Why does the ST BLE Mesh app stop after provisioning success callback without completing node configuration? Is there a recommended configuration for stable provisioning/configuration on SensorTile.box PRO?

Thank you.

Labels:
0 Kudos
3 REPLIES 3
amiana
Associate

‎2026-05-22 3:00 AM

Did you configure the mesh nodes manually before testing, or did you only flash both STEVAL-MKBOXPROA boards directly with FP-SNS-BLEMESH1 default firmware? and how ?I am asking because using the default firmware directly on both boards might explain why the Embedded Provisioner cannot discover the unprovisioned node or why provisioning/configuration stops after the provision callback.

0 Kudos
NOUR11
Associate

‎2026-05-22 4:19 AM

Both boards were flashed with custom firmware based on FP-SNS-BLEMESH1 v2.1.3, not the default binary. The configuration was done explicitly:

Board 1 (Embedded Provisioner):

  • DYNAMIC_PROVISIONER defined in mesh_cfg_usr.h
  • ENABLE_NEIGHBOR_TABLE active
  • PB_ADV_SUPPORTED=1, BEARER_INFO=3 confirmed at runtime via UART diagnostic
  • Appli_StartProvisionerMode(1) called at boot

Board 2 (Sensor Node):

  • ENABLE_PROVISIONER_FEATURE and DYNAMIC_PROVISIONER both commented out
  • Boots correctly as unprovisioned device, beacon interval set to 100ms
  • UUID and BD_MAC confirmed on UART

The core issue on Issue #1 is that BluenrgMesh_GetNeighborState() always returns 0 entries on BlueNRG-LP, even with the node physically adjacent. We confirmed through HCI callback instrumentation (hci_le_advertising_report_event override) that zero advertising reports are received by the provisioner, despite the sensor node broadcasting correctly. This points to a known BlueNRG-LP limitation where ADV_NONCONN_IND packets are not surfaced unless aci_gap_start_procedure(GAP_OBSERVATION_PROC) is called explicitly — but calling it manually conflicts with the mesh library's internal scan state machine.

On Issue #2, provisioning via ST BLE Mesh app succeeds (NVM persists Provisioned node across reboot), but the configuration phase (AppKey Add, Model Bind, Publication Set) never completes.  I observed the same behavior with the official ST binary, ruling out a firmware customization issue.

0 Kudos
amiana
Associate
In response to NOUR11

‎2026-05-22 5:31 AM

it might be because the OOB ( static) tell me how you configured ( what you modified in the code ) exactly and i will correct it with you

0 Kudos
Top