Nus profile seems to cause system reset if the data length too long.

[Ted]

iphone5_b.psdm370_android6_b.psdlong_write_error.pngI using SDK11. I porting nus profile to my system and make a customer's UUID. I use Lightblue on iPhone 5 to connect my system. I sent a data through my customer's UUID. My system work fine when the data length is less than or equal 20 bytes. It will cause system reset if the data length is great than 20 bytes. Was the softdevice error, or I made something wrong?

[Ted]

The error return code of sd_ble_gatts_rw_authorize_reply is 7 (NRF_ERROR_INVALID_PARAM). I don't understand why I haven't received the event of BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST when the data length is less than or equal 20 bytes. I will receive the event of BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST when the data length is great than 20 bytes. My project is modified from the project of ble_app_hrs_rscs_relay_pca10028 of SDK11. (It locations at examples\ble_central_and_peripheral\experimental\ble_app_hrs_rscs_relay\pca10028\s130\arm5_no_packs) I also modified ble_nus.c.

[Hieu]

I am afraid I don't know enough to help beyond this.

It also is not clear to me why a Long Write to NUS would result in authorization request, because the write permission for the NUS RX characteristics is set to open... My only (unhelpful) guess is that because NUS RX characteristic's maximum length is 20, writing more than 20 create some unknown conflicts...

Hope someone could help you soon.

[Petter Myhre]

Ok. So you get into trouble when you are trying to write more than 20 bytes into the TX characteristic. Firstly, as I mentioned above, the maximum ATT MTU with the S130 v2 is 23 bytes, the header is 3 bytes, so up to 20 bytes of data is allowed in one operation. So you are probably triggering long write/queued write by trying to write more than 20 bytes, which is not supported by nus, see this for more information. Secondly, the maximum length of the TX characteristic value is 20 bytes, so if you want to actually do a long write you have to change this. But in most cases it is better to split your data into 20 byte pieces and reassemble the data in the peer application.

[Petter Myhre]

Thirdly, I strongly recommend to test the functionality you want with the ble_app_uart example first, then we have common starting point, and it is easier to figure things out.

[Ted]

I use ble_app_uart example to test. I modified code to print event mesaage. The code is as follows.

static void ble_evt_dispatch(ble_evt_t * p_ble_evt)
{
    ***printf("event=%d\n", p_ble_evt->header.evt_id);***
    ble_conn_params_on_ble_evt(p_ble_evt);
    ble_nus_on_ble_evt(&m_nus, p_ble_evt);
    on_ble_evt(p_ble_evt);
    ble_advertising_on_ble_evt(p_ble_evt);
    bsp_btn_ble_on_ble_evt(p_ble_evt);
}

I got some debug mesages from UART as follows:

UART Start!

event=16

event=80 <-- sent sent 5 characters

12345

event=80 <-- sent sent 10 characters

1234567890

event=80 <-- sent sent 20 characters

12345678901234567890

event=2 <-- sent 22 characters BLE disconnect from phone

The project of ble_app_uart seems same issue.

Our QA team is makeing critical test. They sent unpredictable data to test it.