This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 Ble Peripheral Example - ble_app_blinky not showing led/button service

Hi I have run a few peripheral examples ok and now move to evaluation of ble_peripheral also.

I'm using this version of the SDK....

If I program the softdevice and then the application hex file into board using the files shown below the led 1 turns on as expected. 

Using rfConnect I can connect to "Nordic Blinky" and the led 2 turns on and led 1 turns off. However in the list of services I see there is not one showing for the Led/Button.

Using the blinky app for Android to connect I get a message indicating the "Device does not have the required services".

I checked the code in sdk_config.h to see if the service was enabled and this looks ok...

Looking at the help for the application at this link http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk%2Fdita%2Fsdk%2Fnrf5_sdk.html

I think I have done things correctly so I am now looking for some ideas/support to move forward please.

Regards MPH

  • Hi Martin

    This looks good to me. For clarity I would insert the compound_char_handles field in ble_lbs_s struct after the button_char_handles field, and before the event handler, but this has no practical impact on the code (it's just to bundle the char handles together). 

    Secondly you can also consider renaming the characteristic to something more relevant to the data that you want to send. 

    The UUID definition looks fine, the main point is to pick a unique 16-bit number for all the new characteristics. 

    Best regards
    Torbjørn

  • Hi Torbjørn

    I started to look for some tutorials on integrating application events/processing into the BLE framework but do you have any recommendations on this. I found something using a scheduler for example.

    BR Martin

  • Hi Martin

    There isn't that much to it, other than be a bit careful about the interrupt priorities you run your events at. 

    If your events run at priority 6 or 7 there isn't much to think about. Critical SoftDevice interrupts and event forwarding to the application will have priority, and will not be impacted. 

    If your events run a priority 2 or 3 you have to be a bit more careful, as you will supersede events coming from the SoftDevice, and you will not be able to call SoftDevice functions from your application event directly. 

    The remaining interrupt priorities (0, 1, 4 and 5) are unavailable when using a SoftDevice. 

    Best regards
    Torbjørn

Related