• State Verified Answer
  • Replies 21 replies
  • Subscribers 62 subscribers
  • Views 7427 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 123901
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF51 to nRF52 migration, can't discover services

Eliot Stock

Hi. I have some nRF51 firmware I'm migrating to the nRF52. It's a peripheral with bunch of vendor specific services, using SDK 13.0.0 and SD 132 v4.0.2.

My code builds and runs and the device advertises OK. I can see it in the nRF Connect app for Android, and in my own Android app. But when I connect to it and try to discover services, nothing happens.

I've been through the migration guide (infocenter.nordicsemi.com/index.jsp and can't see anything I've missed.

How do I debug the service discovery/connection issue? How do I get logging out of the BLE sources in the SDK? There are no log flags for these in sdk_config.h.

The BLE_GAP_EVT_CONNECTED event is happening, I can see that much.

Edit: Adding two Wireshark captures, one when connecting from our custom Android app, the other when connecting from the nRF Connect Android app.

bike-tracker-nRF52-discovery-from-custom-android-app-2017-07.pcapng

bike-tracker-nRF52-discovery-from-nrf-connect-android-app-2017-07.pcapng

Edit: Adding two more Wireshark captures.

Capture 3: Connection from the nRF Connect Android app to our (Bike Tracker) peripheral app. Same as above, but another attempt at getting a good capture. Shows nothing but empty PDUs after the CONNECT_REQ in this case.

bike-tracker-nRF52-discovery-from-nrf-connect-android-app-2017-07-b.pcapng

Capture 4: Connection from the nRF Connect Android app to the ble_app_hrs example app in SDK 13.0.0. For comparison. Shows service discovery starting right after the connection.

ble_app_hrs-nRF52-discovery-from-nrf-connect-android-app-2017-07.pcapng

Parents
  • 0

    bike-tracker-nRF52-discovery-from-nrf-connect-android-app-2017-07.pcapng shows CONNECT_REQ but no single PDU afterwards so it either failed or sniffer failed to follow the packets. Second bike-tracker-nRF52-discovery-from-custom-android-app-2017-07.pcapng is better but as you said, no GATT procedure visible, just empty PDUs except LL_FEATURE_REQ/RSP procedure. Note that basically all mobile phones today use GATT caching on Client side so to see whole Service discovery "like for the first time" you need to either change GAP Peripheral adv. (MAC) address or you need to erase cache on mobile side (which can be harder then it sounds, e.g. on iPhone you need to erase network settings which hurts because it deletes also other valuable pairings/keys including WiFi if I'm not mistaken, on Android it usually is enough to find "BT Share" or similar process and wipe all data).

Reply
  • 0

    bike-tracker-nRF52-discovery-from-nrf-connect-android-app-2017-07.pcapng shows CONNECT_REQ but no single PDU afterwards so it either failed or sniffer failed to follow the packets. Second bike-tracker-nRF52-discovery-from-custom-android-app-2017-07.pcapng is better but as you said, no GATT procedure visible, just empty PDUs except LL_FEATURE_REQ/RSP procedure. Note that basically all mobile phones today use GATT caching on Client side so to see whole Service discovery "like for the first time" you need to either change GAP Peripheral adv. (MAC) address or you need to erase cache on mobile side (which can be harder then it sounds, e.g. on iPhone you need to erase network settings which hurts because it deletes also other valuable pairings/keys including WiFi if I'm not mistaken, on Android it usually is enough to find "BT Share" or similar process and wipe all data).

Children
No Data
Related