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

sd_softdevice_disable() causes application to crash/hang if device is paired

ned_zeppelin

If the device is paired (but not bonded) using "Just Works", sd_softdevice_disable() causes the application to hang/crash (nothing happens until reset by watchdog timer).

I use dfu_app_handler.c from sdk 8.1.0, so sd_softdevice_disable() is called from bootloader_start() when going from application to bootloader/DFU.

If pairing is not performed (using the exact same application) before writing START_DFU Op Code to the DFU Control Point characteristic, everything works as expected.

It should be fairly easy to recreate the issue. I use the following security parameters:

#define SEC_PARAM_TIMEOUT                    10
#define SEC_PARAM_BOND                       0
#define SEC_PARAM_MITM                       0
#define SEC_PARAM_IO_CAPABILITIES            BLE_GAP_IO_CAPS_NONE
#define SEC_PARAM_OOB                        0
#define SEC_PARAM_MIN_KEY_SIZE               7
#define SEC_PARAM_MAX_KEY_SIZE               16

And for the services I want encrypted I use:

BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM()

Any help would be greatly appreciated.

Parents
  • 0

    Hi, I was finally able to do some proper debugging. I was incorrect in assuming that sd_softdevice_disable() caused the program to halt. The reason my uart printout directly after sd_softdevice_disable() did not appear is that I call sd_mutex_acquire() before every printout, and abort if NRF_SUCCESS is not returned. In this case the softdevice had been disabled so the printout was aborted.

    However, dm_application_context_set(), called from dfu_app_handler.c, returns (NRF_ERROR_INVALID_STATE | DEVICE_MANAGER_ERR_BASE) (due to VERIFY_DEVICE_BOND(p_handle->connection_id) failing), causing the app_error_handler() to be called.

    The first line of my app_error_handler is APP_ERROR_CHECK(sd_nvic_critical_region_enter(0)), which is probably what caused program execution to "hang" (as the softdevice had been disabled).

    I was able to recreate it using the ble_app_hrs example with dfu from sdk 8.1.0 by adjusting the security settings etc., but the issue was as explained above not sd_softdevice_disable().

    The bug was in my code and not the SDK or Softdevice. The DEVICE_MANAGER_APP_CONTEXT_SIZE define should be set to 0, if pairing (but not bonding) is performed.

Reply
  • 0

    Hi, I was finally able to do some proper debugging. I was incorrect in assuming that sd_softdevice_disable() caused the program to halt. The reason my uart printout directly after sd_softdevice_disable() did not appear is that I call sd_mutex_acquire() before every printout, and abort if NRF_SUCCESS is not returned. In this case the softdevice had been disabled so the printout was aborted.

    However, dm_application_context_set(), called from dfu_app_handler.c, returns (NRF_ERROR_INVALID_STATE | DEVICE_MANAGER_ERR_BASE) (due to VERIFY_DEVICE_BOND(p_handle->connection_id) failing), causing the app_error_handler() to be called.

    The first line of my app_error_handler is APP_ERROR_CHECK(sd_nvic_critical_region_enter(0)), which is probably what caused program execution to "hang" (as the softdevice had been disabled).

    I was able to recreate it using the ble_app_hrs example with dfu from sdk 8.1.0 by adjusting the security settings etc., but the issue was as explained above not sd_softdevice_disable().

    The bug was in my code and not the SDK or Softdevice. The DEVICE_MANAGER_APP_CONTEXT_SIZE define should be set to 0, if pairing (but not bonding) is performed.

Children
Related
Terms of service