Softdevice S112 Incorrect Packet Length with new NRF52SDK

[snoopy20]

Upgraded from v16.0.0 to v17.1.0 and have a truncation issue. It only occurs after the first send. Reverted back to v16.0.0 and all ok.

No other code change other than the fixes to RAM1 and FLASH1.

static uint32_t BLUETOOTH_Push (uint16_t len, uint8_t *data, uint16_t handle) {

    if (m_conn_handle == BLE_CONN_HANDLE_INVALID) {
      return 0;
    }

    ble_gatts_hvx_params_t params;

    memset(&params, 0, sizeof(params));
    params.type   = BLE_GATT_HVX_NOTIFICATION;
    params.handle = handle;
    params.p_data = data;
    params.offset = 0;
    params.p_len  = &len;

    return sd_ble_gatts_hvx(m_conn_handle, &params);
}

uint32_t BLUETOOTH_PushStatus(void) {

    return BLUETOOTH_Push(sizeof(status), (uint8_t *) &status, m_lbs.status_char_handles.value_handle);
}

The bluetooth phone app shows the following being passed - 

LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 25, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 30, 60, 101, 0, 0, 18, 19, 102, 10], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}
LOG {"data": [0, 0, 3, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 0, 0, 20, 0, 0, 0, 1], "type": "Buffer"}

There should only but the one and then a long delay but it looks that as well as the truncation the softdevice is in a loop.

[snoopy20]

The Phone App writes a code to the command characteristic which is picked up by nrf52810, inferred and calls the relevant operation - in this situation BLUETOOTH_PushStatus(), which updates the status characteristic. 

void ble_lbs_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context) {
    ble_lbs_t * p_lbs = (ble_lbs_t *)p_context;
    ble_gatts_evt_write_t const *p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    switch (p_ble_evt->header.evt_id) {
        case BLE_GATTS_EVT_WRITE:
            // update config
            if ((p_evt_write->handle == m_lbs.config_char_handles.value_handle)) {
                CONFIG_ApplySettings((struct settingsProto*) &p_evt_write->data);
                BLUETOOTH_PushStatus();
                return;
            }
            // update control
            if ((p_evt_write->handle == m_lbs.control_char_handles.value_handle)) {
                CONTROL_ApplyUpdate((struct controlProto*) &p_evt_write->data);
                return;
            }
            // execute command
            if ((p_evt_write->handle == m_lbs.command_char_handles.value_handle)) {
                COMMAND_Exec(p_evt_write->data[0]);
                return;
            }
            break;
        default:
            // No implementation needed.
            break;
    }
}

SDK 16.0.0, S112 v7.01 or v7.2 - working
SDK 17.1.0, S112 v7.2 - not working

[Einar Thorsrud]

I see. So it is your BLUETOOTH_Push() that is called for each of these, then. As mentioned there is nothing here for me to go on. Have you debugged now, as I asked? What are the parameters provided to sd_ble_gatts_hvx() in the calls where it fails? Please check with a debugger to verify that they are not corrupt. Also please check the data buffer and length field. That is the only sensible way forward unless you can provide me with a code snippet that runs out of the box on a DK and reproduces this (in that case I can test on my side).