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

GDB server goes out of sync after ble_advertising.c:463 nRF52832

SDK version 15

I'm adding two more BLE services to my working custom one. And ran into some advertising issues. This is what's spitted out from GDB.

ble_advertising_init (p_advertising=p_advertising@entry=0x20002f3c <m_advertising>, p_init=p_init@entry=0x2000ff3c)
    at ../../../../../../components/ble/ble_advertising/ble_advertising.c:463
463        memset(&p_advertising->peer_address, 0, sizeof(p_advertising->peer_address));
(gdb) stepi
460        p_advertising->current_slave_link_conn_handle = BLE_CONN_HANDLE_INVALID;
(gdb)
463        memset(&p_advertising->peer_address, 0, sizeof(p_advertising->peer_address));
(gdb)
0x0002fd9e    463        memset(&p_advertising->peer_address, 0, sizeof(p_advertising->peer_address));
(gdb)
Remote failure reply: E62F00200000000007000000D02F00203C2F0020FFFF0000D4FF00203CFF0020000000000000000000000020000000000000000000FF0020C7E10200A2FD020000000001
Remote failure reply: E62F00200000000007000000D02F00203C2F0020FFFF0000D4FF00203CFF0020000000000000000000000020000000000000000000FF0020C7E10200A2FD020000000001
(gdb)
Remote failure reply: E62F00200000000007000000D02F00203C2F0020FFFF0000D4FF00203CFF0020000000000000000000000020000000000000000000FF0020C7E10200A2FD020000000001
(gdb)
Remote failure reply: E62F00200000000007000000D02F00203C2F0020FFFF0000D4FF00203CFF0020000000000000000000000020000000000000000000FF0020C7E10200A2FD020000000001
(gdb)
Remote failure reply: E62F00200000000007000000D02F00203C2F0020FFFF0000D4FF00203CFF0020000000000000000000000020000000000000000000FF0020C7E10200A2FD020000000001

Address of p_advertising seems fine

$ arm-none-eabi-gdb --version
GNU gdb (bleeding-edge-toolchain) 8.0.1

Anyone has any idea what's going on here?

  • Hi Neil,

    It would help if you elaborate more on what kind of advertising issues you have. The gdb log does not help in understanding that much.

  • The error code returned back from ble_advertising_init is 12 however when we step into the function itself, the error code generated at the end is 0. Please see the attachment for the values of the init variable.

    (gdb) bt
    #0  0x0002e0b6 in advertising_init () at ../../../main.c:1012
    #1  main () at ../../../main.c:1106
    (gdb) nexti
    1002	    init.advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
    (gdb) 
    1008	    init.config.ble_adv_fast_timeout  = APP_ADV_TIMEOUT_IN_SECONDS;
    (gdb) 
    1010	    init.evt_handler = on_adv_evt;
    (gdb) 
    1012	    err_code = ble_advertising_init(&m_advertising, &init);
    (gdb) 
    1013	    APP_ERROR_CHECK(err_code);
    (gdb) p init.advdata.uuids_complete
    $10 = {uuid_cnt = 2, p_uuids = 0x34e74 <m_adv_uuids>}
    (gdb) p err_code
    $11 = 12
    (gdb) p init.advdata.uuids_complete
    $12 = {uuid_cnt = 2, p_uuids = 0x34e74 <m_adv_uuids>}
    (gdb) nexti
    0x0002e0c6	1013	    APP_ERROR_CHECK(err_code);
    (gdb) 
    1013	    APP_ERROR_CHECK(err_code);
    (gdb) 
    
    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x00027374 in app_error_fault_handler (id=id@entry=16385, pc=pc@entry=0, info=info@entry=536936220)
        at ../../../../../../components/libraries/util/app_error_weak.c:99
    99	    NRF_BREAKPOINT_COND;
    (gdb) bt
    #0  0x00027374 in app_error_fault_handler (id=id@entry=16385, pc=pc@entry=0, info=info@entry=536936220)
        at ../../../../../../components/libraries/util/app_error_weak.c:99
    #1  0x00027344 in app_error_handler_bare (error_code=<optimized out>)
        at ../../../../../../components/libraries/util/app_error.c:73
    #2  0x0002e242 in advertising_init () at ../../../main.c:1013
    #3  main () at ../../../main.c:1106
    (gdb) frame 2
    #2  0x0002e242 in advertising_init () at ../../../main.c:1013
    1013	    APP_ERROR_CHECK(err_code);
    (gdb) p init
    $13 = {advdata = {name_type = BLE_ADVDATA_FULL_NAME, short_name_len = 0 '\000', include_appearance = true, 
        flags = 6 '\006', p_tx_power_level = 0x0, uuids_more_available = {uuid_cnt = 0, p_uuids = 0x0}, 
        uuids_complete = {uuid_cnt = 2, p_uuids = 0x34e74 <m_adv_uuids>}, uuids_solicited = {uuid_cnt = 0, 
          p_uuids = 0x0}, p_slave_conn_int = 0x0, p_manuf_specific_data = 0x0, p_service_data_array = 0x0, 
        service_data_count = 0 '\000', include_ble_device_addr = false, le_role = BLE_ADVDATA_ROLE_NOT_PRESENT, 
        p_tk_value = 0x0, p_sec_mgr_oob_flags = 0x0, p_lesc_data = 0x0}, srdata = {name_type = BLE_ADVDATA_NO_NAME, 
        short_name_len = 0 '\000', include_appearance = false, flags = 0 '\000', p_tx_power_level = 0x0, 
        uuids_more_available = {uuid_cnt = 0, p_uuids = 0x0}, uuids_complete = {uuid_cnt = 0, p_uuids = 0x0}, 
        uuids_solicited = {uuid_cnt = 0, p_uuids = 0x0}, p_slave_conn_int = 0x0, p_manuf_specific_data = 0x0, 
        p_service_data_array = 0x0, service_data_count = 0 '\000', include_ble_device_addr = false, 
        le_role = BLE_ADVDATA_ROLE_NOT_PRESENT, p_tk_value = 0x0, p_sec_mgr_oob_flags = 0x0, p_lesc_data = 0x0}, 
      config = {ble_adv_on_disconnect_disabled = false, ble_adv_whitelist_enabled = false, 
        ble_adv_directed_high_duty_enabled = false, ble_adv_directed_enabled = false, ble_adv_fast_enabled = true, 
        ble_adv_slow_enabled = false, ble_adv_directed_interval = 0, ble_adv_directed_timeout = 0, 
        ble_adv_fast_interval = 300, ble_adv_fast_timeout = 0, ble_adv_slow_interval = 0, ble_adv_slow_timeout = 0, 
        ble_adv_extended_enabled = false, ble_adv_secondary_phy = 0, ble_adv_primary_phy = 0}, 
      evt_handler = 0x2de69 <on_adv_evt>, error_handler = 0x0}
    

  • The hardfault is normal as you are halting the CPU for debugging and the softdevice timers when they do not do the housekeeping on time, then when you step (un-halt CPU) then at some point the softdevice throws assert that it failed to keep track of time correctly. I do not think you need to worry about the hardfault

    About error code being 12, that is being returned from ble_advdata_encode from inside the ble_advertising_init and clearly according to the documentation for encode funtion

    * @retval NRF_ERROR_DATA_SIZE If the operation failed because not all the requested data could
    * fit into the provided buffer or some encoded AD structure is too
    * long and its length cannot be encoded with one octet.

    You need to calculate to see what kind of data you are trying to put in the advertising packet, and check if it fits in it.

  • Thank you very much Aryan for your reply. We are able to narrow down the problem to exactly what you mentioned through GDB. However, what we are having trouble figuring out is which requested data that we are adding to the buffer is exceeding the size and how we should figure that out.

  • Hi Neil,

    in ble_advdata.c->ble_advdata_encode function. You can see that the function takes your p_len as reference as max_size allowed for the p_encoded_data buffer. The function will encode the below values, only if presented in your p_advdata pointer

    1. Device address
    2. Appearance
    3. any flags
    4. tx power level 
    5. more uuid's if presented, complete list, solicited service list
    6. slave connection interval range
    7. Manufacturer specific data
    8. service data and finally
    9. name (truncated if less space)

    So your problem is that, you provided the value pointed by pointer p_len too low to fit all the encoded data.

    • You need to understand what you initialized in p_advdata to cause the encoded data grow more than you expected or
    • you can increase the size of value pointed by p_len to fit the bigger buffer.
Related