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

[el_jefe]

Hello!

I have been trying to implement the serialization for STM32L476.  During my development I discovered that the deserialization of the SD_BLE_GAP_ADV_SET_CONFIGURE response in ble_gap_adv_set_configure_rsp_dec caused a Hard Fault.  To trouble shoot, I built and loaded the Nordic example ble_app_hrs application (unmodified) and connectivity application(also unmodified) on two PCA10040 boards as outlined below.  I noticed that the example application run on the Nordic hard faults in the same location.  This should be easy to reproduce.

Using SDK 15.3 & GCC toolchain (6.3.1 20170620) on MacOS (10.14.5)

Following instructions provided in SDK Serialization Documentation

Build connectivity application (examples/connectivity/ble_connectivity/pca10040/ser_s132_uart/armgcc) and load onto a PCA10040 with SB17 shorted (using make flash and make flash_softdevice)

Build connectivity application (examples/ble_peripheral/ble_app_hrs/pca10040/ser_s132_uart/armgcc) and load onto another PCA10040 (using make flash).

Connect the two boards per the documentation.  Power on both boards.

I ran ble_app_hrs using Ozone debugger, with break point set on Hard Fault handler.

It seems the hard fault happens in the function uint8_t_dec, after ble_gap_adv_set_configure_rsp_dec.

Please advise.

Thank you,

Jeff

[tesc]

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

[BenEdna]

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

[tesc]

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

[BenEdna]

Thank you! The example is working now for me