This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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?

Parents Reply Children
  • Yes, I think so. But I'm afraid the code is in softdevice. If it is in softdevice I don't have source code to trace it. Could you double check it? It will cause system reset before the function of ble_evt_dispatch if the data length is great than 20 bytes.

  • Uh.. you probably don't want to follow up using an answer.

    Anyway, I have never encountered any system reset due to SoftDevice, whether I use custom BLE services or nRF SDK's BLE Service.

    Following @petter 's suggestion, you should look at all places APP_ERROR_CHECK is used. Or quicker, add the preprocessor DEBUG in compiling option. This change APP_ERROR_CHECK to trap the firmware in an infinite loop at errors rather than reset the system. You can then use debug mode and see where the system freeze. Also when it froze, take a look at app_error.c. There are some global variables storing which line in which file trigger the error.

  • Sorry, I have no good skill with Nordic platform. I follow your instrument to trace the code. I got an event of BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST if the data length is great than 20 bytes. (at APP_ERROR_CHECK)

    But if the data length isn't great than 20 bytes I don't receive the event of LE_GATTS_EVT_RW_AUTHORIZE_REQUEST and system work fine.

    Could you guide me how to trace it and fix this wrong I made?

    static void on_ble_peripheral_evt(ble_evt_t * p_ble_evt)
    {
        uint32_t err_code;
        switch (p_ble_evt->header.evt_id)
        {
            case BLE_GAP_EVT_CONNECTED:
    ...
                 break; //BLE_GAP_EVT_CONNECTED
            case BLE_GAP_EVT_DISCONNECTED:
    ...
                break;//BLE_GAP_EVT_DISCONNECTED
            case BLE_EVT_USER_MEM_REQUEST:
    ...
                break;//BLE_EVT_USER_MEM_REQUEST
            case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
            {
                ble_gatts_rw_authorize_reply_params_t auth_reply;
                if(p_ble_evt->evt.gatts_evt.params.authorize_request.type
                   != BLE_GATTS_AUTHORIZE_TYPE_INVALID)
                {
                    if ((p_ble_evt->evt.gatts_evt.params.authorize_request.request.write.op
                         == BLE_GATTS_OP_PREP_WRITE_REQ)
                        || (p_ble_evt->evt.gatts_evt.params.authorize_request.request.write.op
                         == BLE_GATTS_OP_EXEC_WRITE_REQ_NOW)
                        || (p_ble_evt->evt.gatts_evt.params.authorize_request.request.write.op
                         == BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL))
                    {
                        if (p_ble_evt->evt.gatts_evt.params.authorize_request.type
                            == BLE_GATTS_AUTHORIZE_TYPE_WRITE)
                        {
                            auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_WRITE;
                        }
                        else
                        {
                            auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
                        }
                        auth_reply.params.write.gatt_status = APP_FEATURE_NOT_SUPPORTED;
                        err_code = ***sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.gap_evt.conn_handle,&auth_reply);
                        APP_ERROR_CHECK(err_code);  -->fail at here***
                    }
                }
            }break;//BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST
            default:
                // No implementation needed.
                break;
        }
    }
    
  • First off, I gotta admit I am unfamiliar with these authorization events. So I apologize before hand, but I can't guarantee help. (Also means anyone who know more should feel free to step in).

    What error code is being returned? You can see the list of possible error at the sd_ble_gatts_rw_authorize_reply() function's documentation.

    Also, where did you get the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST handling code from? I believe it is not from the NUS example.

  • 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.

Related