Serialized ble_app_hrs example app Hard Faults when de-serializing SD_BLE_GAP_ADV_SET_CONFIGURE response

RE: Serialized ble_app_hrs example app Hard Faults when de-serializing SD_BLE_GAP_ADV_SET_CONFIGURE response

BenEdna — Wed, 09 Oct 2019 06:48:31 GMT

Thank you! The example is working now for me

RE: Serialized ble_app_hrs example app Hard Faults when de-serializing SD_BLE_GAP_ADV_SET_CONFIGURE response

tesc — Tue, 08 Oct 2019 16:36:04 GMT

Hi,

Good news! It looks like this has been fixed for the next nRF5 SDK release.

The issue was with using adv_data instead of p_adv_handle in input/output parameters in <sdk folder>/components/serialization/application/codecs/ble/middleware/app_mw_ble_gap.c.

In gap_adv_set_configure_rsp_dec() (line 1899 in SDK 15.3), change the calls to app_ble_gap_adv_buf_addr_unregister() inside the if statement to:

    app_ble_gap_adv_buf_addr_unregister(mp_out_params[1], false);
    app_ble_gap_adv_buf_addr_unregister(mp_out_params[2], false);

(I.e. indexes 0 and 1 changed to 1 and 2 respectively.)

Similarly, in _sd_ble_gap_adv_set_configure() (line 1925 in SDK 15.3), change the indexes from 0 and 1 to 1 and to respectively. Also add the "mp_out_params[0] = p_adv_handle;" before the if statement. Excerpt should look like this after the change:

    mp_out_params[0] = p_adv_handle;
    if (p_adv_handle)
    {
        mp_out_params[1] = p_adv_data->adv_data.p_data;
        mp_out_params[2] = p_adv_data->scan_rsp_data.p_data;
    }
    else
    {
        mp_out_params[1] =  NULL;
        mp_out_params[2] =  NULL;
    }

The main reason for the hardfault seems to be when mp_out_params[0] was set to NULL, then at some location in code there is an attempt to use that NULL pointer. The above changes fixes the root cause which was wrong use of parameters.

Regards,
Terje

RE: Serialized ble_app_hrs example app Hard Faults when de-serializing SD_BLE_GAP_ADV_SET_CONFIGURE response

BenEdna — Tue, 08 Oct 2019 14:38:01 GMT

We have the same issue (using IAR 8.32.3), is there any update on the issue report?

RE: Serialized ble_app_hrs example app Hard Faults when de-serializing SD_BLE_GAP_ADV_SET_CONFIGURE response

tesc — Thu, 13 Jun 2019 11:48:47 GMT

Hi,

I have tested the example on my desk, and was able to reproduce. I used SES on Windows 7 and I got a hardfault shortly after starting the example. At first glance it looks like a buffer size error when decoding the result of the sd_ble_gap_adv_set_configure() call.

There were some changes to the advertising part of the SoftDevice API between SoftDevice versions 5 and 6. A further change behind the hood happened between versions 6.0.0 and 6.1.0, at which point the SoftDevice started to use the advertising data buffer of the application rather than copying the data into its own buffer. Those changes may be related in some way to the issue, e.g. the API is newly changed and the usage pattern of transferring buffer data has changed.

I have reported the issues internally. For now, potential workarounds might be:

1) Try with a different physical transport layer for the serialization. For instance HCI has proven to be more reliable (and also uses UART). HCI is also what is used for pc-ble-driver and nRF Connect for Desktop.

2) Revert to an earlier version of the SoftDevice (see for instance nRF5 SDK v14.2).

Regards,
Terje