Soft Device 140 ignores param.p_len in ble_app_blinky

[kw_martin]

Overview: number of bytes sent by ble_app_blinky at notification is determined by (note my changes for debug:

    /*
    add_char_params.init_len          = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;
    add_char_params.max_len           = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;
    add_char_params.init_len          = sizeof(uint8_t);
    add_char_params.max_len           = sizeof(uint8_t);
    */
    add_char_params.init_len          = 4;
    add_char_params.max_len           = 4;

in ble_lbs_init() of ble_lbs.c and not by:

    params.p_data = test_data;
    uint16_t len = sizeof(test_data);
    params.p_len  = &len;

in ble_lbs_on_button_change() as it should be. In addition, peeking at the size using:

      errcode = sd_ble_evt_get(NULL, &len2);
      SEGGER_RTT_printf(0, "Peeked length %u\n",len2);

is returning 0 and not memory size of the notification characteristic.

Scenario 1 which works with:

    add_char_params.init_len          = 1;
    add_char_params.max_len           = 1;

Peeked length 0
About to call sd_ble_gatts_hvx(), p_len 1, p_data: 5
Peeked length 0

from:

      SEGGER_RTT_printf(0, "Peeked length %u\n",len2);
      SEGGER_RTT_printf(0, "About to call sd_ble_gatts_hvx(), p_len %d, p_data: %d\n",
        *params.p_len, *params.p_data);
      err_code = sd_ble_gatts_hvx(conn_handle, &params);
      errcode = sd_ble_evt_get(NULL, &len2);
      SEGGER_RTT_printf(0, "Peeked length %u\n",len2);

Note: p_len and p_data are as I initialized, but also the peeked length appears to be inconsitent with documentation.

The output from the client (Raspberry Pi running python/bluepy is as expected:

(Pdb) 
b'\x05'

Next, the only change made was:

    add_char_params.char_props.read  = 4;
    add_char_params.char_props.write = 4;

The RTT output is still correct:

Peeked length 0
About to call sd_ble_gatts_hvx(), p_len 1, p_data: 5
Peeked length 0

However, the bytes actually sent are:

(Pdb) 
b'\x05\x01\x00\x05'

If the maximum data is initialized to 8 bytes, then 8 bytes are sent. Similarly, using:

    add_char_params.init_len          = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;
    add_char_params.max_len           = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;

and no other changes sends:

(Pdb) 
b'\x05\xd1\xbc\xea_x#\x15\xde\xef\x12\x12%\x15\x00\x00\x00\x01\x00\x05'

while the RTT output is still correct:

Peeked length 0
About to call sd_ble_gatts_hvx(), p_len 1, p_data: 5
Peeked length 0

(well except for the peeked memory size which is still wrong). Finally, setting NRF_SDH_BLE_GAP_DATA_LENGTH = 251

and NRF_SDH_BLE_GATT_MAX_MTU_SIZE = 247, sends 20 bytes (extended length is not working)

(Pdb) 
b'\x05\x00\x00\x00\x00 \x00@\x00\x00\x00\x00\x00 \x00@\x00\x00\x00\x00'

and now the link disconnects always after 27s (as is described in a separate thread).

These behaviors do not seem correct to me, and unfortunately due to lack of documentation and visibility into the soft device, I can not debug

what is going wrong. For the last case, I can supply data from on-air sniffing, if you think it would help.

[Joakim Jakobsen]

Hi!

Sorry about the delay here. 

Maybe you could add which version of the Softdevice and SDK you are working with here, and I can do some testing on my end. 

Also, adding a sniffer trace might shed some light on what is causing the disconnect. Are the disconnection consistent after 27s?

Br, 
Joakim

[kw_martin]

Joakim, I was using SDK 16 and am now using 17. I haven't gone back to this issue as I have not been able to solve it. The disconnects are consistent and I was dealing with them in a separate thread that I also have not been able to resolve (I'm really not having much success going getting anything to work; sigh!). In the other thread https://devzone.nordicsemi.com/f/nordic-q-a/64728/ble_blinky-timeout-disconnect-for-nrf_sdh_ble_gatt_max_mtu_size-247 I did send sniffer output. It showed the disconnects were due to the Nordic Soft device stopping in replying to Master 0 data keep alive packets. The time the Nordic Soft Device stopped replying was application dependent, but consistent for a particular application. After the Nordic Soft device stopped sending 0 data keep alive packets, the Master disconnected 4s later as expected. The disconnect issue was the same in both SDK 16 and SDK 17. I haven't checked the current issue (Soft Device 140 ignores param.p_len) again as I'm currently trying to find a way around it without solving it due to time pressure to get something working.