Client unable to receive notification after 0x3002 from SoftDevice

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Wed, 16 Jun 2021 13:43:40 GMT

Great to hear, I will let the team know.

Kenneth

RE: Client unable to receive notification after 0x3002 from SoftDevice

aghogho obi — Wed, 16 Jun 2021 13:17:00 GMT

Wow, that is indeed the case. Big thanks to you and the team for getting to the bottom of this. As it turns out, the ble_gatts_hvx_params_t::p_len parameter was indeed set to 0 by the SD. But we never change its value before calling the "ble_nus_data_send()" function. As such, I updated our FW as follows:

nus_data_length = SIZE_OF_DATAPACKET;
err_code = ble_nus_data_send(&m_nus, (uint8_t*)ble_queue[0], &nus_data_length, m_conn_handle);

Now, the ble_gatts_hvx_params_t::p_len parameter will be set everytime before call "ble_nus_data_send()". The system is able to recover from the disconnect event and still keep on streaming the data afterwards. Thank you once again!!

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Wed, 16 Jun 2021 12:27:37 GMT

In addition to my previous reply, the team have a working theory:

the attribute is variable sized
on disconnect sd_ble_gatts_hvx returns error code and thus ble_gatts_hvx_params_t::p_len is set to 0 by SD
on the next iteration application does not update value of ble_gatts_hvx_params_t::p_len so attribute size is set to 0 in the attribute database

Can you check if that is the case?
Kenneth

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Wed, 16 Jun 2021 09:22:23 GMT

Thanks for the log, I will check internally and let you know.

Some questions from the team:

When you declared the characteristric, did you set variable attribute lenght?
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/structble__gatts__attr__md__t.html#a921e414734cd784e0c3b7309d3a14f39

Our best guess that something happened with attribute database on disconnect so the attribute in question becomes zero length. Note that the length you provide in sd_ble_gatts_hvx is not necessary the length of value sent on air. For fixed size attribute length will be taken from attribute database. App can check ble_gatts_hvx_params_t::p_len on return from sd_ble_gatts_hvx to see how many bytes were actually written. For more info see p_hvx_params parameter description here https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.2.0%2Fstructble__gatts__hvx__params__t.html&anchor=a8b0b2dadb3128b0838c71235661f8174

Kenneth

RE: Client unable to receive notification after 0x3002 from SoftDevice

aghogho obi — Wed, 16 Jun 2021 02:07:04 GMT

I was able to get some logs from the use of the nRF sniffer. I acquired logs before/after the occurrence of the 0x3002 error. The file before the error is

devzone.nordicsemi.com/.../no_5F00_err_5F00_code1_5F00_sniffer.pcapng

while the logs after the error is

devzone.nordicsemi.com/.../err_5F00_code1_5F00_sniffer.pcapng

Our use case involves advertising, connection and then initiating notification on the RX characteristic. I did notice that the logs after the error indicate that the RX characteristic is smaller in size when compared to a case with no 0x3002 error. Do let me know if the files reveal other information about the state of the BLE link after the 0x3002 error.

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Thu, 10 Jun 2021 06:25:15 GMT

[quote user="aghogho obi"]

When the softdevice returns error 0x3002, is there some clean/re-initialization of a sub-system that needs to happen?

I will report back with info on the use of the on-air sniffer.

[/quote]

There shouldn't be, so hopefully that on-air sniffer log will provide some more information.

Kenneth

RE: Client unable to receive notification after 0x3002 from SoftDevice

aghogho obi — Thu, 10 Jun 2021 00:38:45 GMT

I will try to do an on-air sniffer log as suggested. To clarify some more, we observed the same behavior when using our custom app, our modified "ble_app_uart_c" on a PCA10040, the nrfConnect App on a phone or desktop with PCA10040. Once the peripheral returns the 0x3002 error during our disconnection/re-connection testing, no notifications can be received from the peripheral using any type of central device. Any central device can still connect and send commands using the RX characteristic, but notifications associated with the TX characteristic cannot be received on the central device.

From the snippet of code I sent above with our usage of the "ble_nus_data_send()" function, we trap error codes not equal to "NRF_SUCCESS". Also, we have an "NRG_LOG()" in our "nus_data_handler()" to log the "BLE_NUS_EVT_TX_RDY" events. The logs indicate that the "ble_nus_data_send()" function returns "NRF_SUCCESS" and triggers the "BLE_NUS_EVT_TX_RDY" event as well. I can even use the nrfConnect app to disable the notification of the TX characteristic in which case the "ble_nus_data_send()" function now returns an error.

When the softdevice returns error 0x3002, is there some clean/re-initialization of a sub-system that needs to happen?

I will report back with info on the use of the on-air sniffer.

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Wed, 09 Jun 2021 07:28:34 GMT

Re-reading the case we found this sentence that stands out a bit:

[quote user=""]Also, the "ble_nus_data_send()" function returns "NRF_SUCCESS" and the "BLE_NUS_EVT_TX_RDY" event is also triggered.[/quote]

This sentence may indicate a different theory of the problem you experience, either:

There is some problem in the app, and the quoted statement is not the case. For example, interpreting the missed log as NRF_SUCCESS while data_send was not called at all.
HVNs are sent, and the problem is on receiving side. Sniffer log can clarify it.

Do you have the possibility to do an on-air sniffer log (e.g. nRF sniffer)?

Kenneth

RE: Client unable to receive notification after 0x3002 from SoftDevice

aghogho obi — Tue, 08 Jun 2021 12:03:38 GMT

Below shows our implementation of the connected/disconnected BLE stack events. As seen, the disconnection event is used to reset our flag variables.

switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);

            ble_gap_phys_t const phys =
			{
				.rx_phys = BLE_GAP_PHY_2MBPS,
				.tx_phys = BLE_GAP_PHY_2MBPS,
			};

            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);

            NRF_LOG_INFO("Connection handle = %u", m_conn_handle);

            break;

        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected");
            // LED indication will be changed when advertising starts.
            m_conn_handle = BLE_CONN_HANDLE_INVALID;
            ble_conn_flag = 0;
            ble_conn_intvl = 0;

            
            NRF_LOG_INFO("Connection handle = %u", m_conn_handle);
            nrf_gpio_pin_write(NRF_GPIO_PIN_MAP(0,19), 1);

            break;

RE: Client unable to receive notification after 0x3002 from SoftDevice

aghogho obi — Tue, 08 Jun 2021 11:48:00 GMT

I have added the NRF_LOG()s as suggested. But first, let me give more context about our FW. Below is a snippet of code for sending the packets to the client.

if(ble_conn_flag == 1)
        {
            if(ble_conn_intvl == 1)
            {
                do
                {
                    if(m_conn_handle != BLE_CONN_HANDLE_INVALID)
                      err_code = ble_nus_data_send(&m_nus, (uint8_t*)ble_queue[blerdptr], &nus_data_length, m_conn_handle);
                    else
                      err_code = 0x20;

                } while (err_code == NRF_ERROR_RESOURCES);

                if(err_code != NRF_SUCCESS)
                {
                    //err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0, 0);
                    //NRF_LOG_INFO("BLE_ERROR_GATTS_SYS_ATTR_MISSING_LOOP");

                    NRF_LOG_INFO("ERROR_CODE IS %u", err_code);
                    if(err_code == 0x3002)
                    {
                      /* Reset device */
                      //nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_RESET);
                    };
                };

                if(m_conn_handle == BLE_CONN_HANDLE_INVALID)
                    nrf_gpio_pin_write(NRF_GPIO_PIN_MAP(0,19), 1);
                else
                    nrf_gpio_pin_toggle(NRF_GPIO_PIN_MAP(0,19));
            };                        
        };

"ble_conn_flag" is set when we receive a command from the client side through "BLE_NUS_EVT_RX_DATA". "ble_conn_interval" is set after responding to the "BLE_GAP_EVT_CONN_PARAM_UPDATE" or "BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST" events from the BLE stack. We also check for the connection handle before calling the function :ble_nus_data_send()". From my NRF_LOG()s, when connected the connection handle is 0. On disconnect, the connection handle is 0xFFFF.

When there is a disconnection/reconnection of the BLE link that is recoverable, a snippet of the NRF_LOG() is

00> <info> app: Disconnected
00> 
00> <info> app: Connection handle = 65535
00> 
00> <info> app: ERROR_CODE IS 32
00> 
00> <info> app: Connected
00> 
00> <info> app: Connection handle = 0

The error code is the 0x20 from the "else" statement from the FW snippet above. This indicates that the trap caught the invalid handle before the call to "ble_nus_data_send()".

Now, when we have a disconnection/reconnection of the BLE link that is not recoverable, theNRF_LOG()s show

00> <info> app: Disconnected
00> 
00> <info> app: Connection handle = 65535
00> 
00> <info> app: ERROR_CODE IS 12290
00> 
00> <info> app: Connected
00> 
00> <info> app: Connection handle = 0

I am assuming that BLE stack events have higher priority than my code, and if a disconnect event happens that a change in the connection handle will occur before the "ble_nus_data_send()" is called. There is clearly a race condition happening but it is not clear where/how is it manifesting. As you can see, i trapped the call to "ble_nus_data_send()". Also, I do not call "ble_nus_data_send()" until the BLE link is establish and we receive events from the BLE stack and commands from the client.

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Mon, 07 Jun 2021 18:11:04 GMT

I suggest to add some NRF_LOG() output every time you connect, disconnect and ble_nus_data_send(), to log the connection handle. I suspect that your handle is incorrect, for instance that you may have some race condition in your code where the handle is somehow set wrong between connects and disconnects.

Kenneth

RE: Client unable to receive notification after 0x3002 from SoftDevice

aghogho obi — Mon, 07 Jun 2021 12:18:31 GMT

Hi Kenneth,

Thanks for the suggestion. In our current implementation, we do have a global flag that we use to make sure we have a valid connection. That test is right above the call to "ble_nus_data_send()" in the "do" loop but this is not shown in the code snippet above.

We still get the same behavior with or without the test for a valid connection. Most of the time, we are able to recover because the err_code is 0x0005. But in a few times, we get the 0x3002 err_code. Only when this happens that we have problems getting notifications after a reconnect and no errors are generated by the Softdevice.

RE: Client unable to receive notification after 0x3002 from SoftDevice

Kenneth — Mon, 07 Jun 2021 12:05:17 GMT

Hi,

I assume 0x3002 means BLE_ERROR_INVALID_CONN_HANDLE.

That seem to indicate that m_conn_handle has changed between the two connections, which it may do. Can you make sure that m_conn_handle is updated/correct before calling ble_nus_data_send()?

Typically you want to have a global flag of some sort, that make sure you don't call ble_nus_data_send() unless you are in a connection (with a valid m_conn_handle).

Kenneth