ble app uart

RE: ble app uart

Karl Ylvisaker — Mon, 11 Oct 2021 13:43:08 GMT

Hello,

Thank you for your patience with this.

To elaborate a little on what I said earlier; error 13313=0x3401 corresponds to BLE_ERROR_GATTS_SYS_ATTR_MISSING and is likely returned by ble_nus_data_send() because it's called before the system attribute table has been updated in the Softdevice, similar to the NRF_ERROR_INVALID_STATE error you get if you try to send notifications before notifications has been enabled by the GATT client .

The attribute table (contain CCCD configurations) is restored on connection if you use the Peer manager module. Maybe ble_nus_data_send() is called before the Peer manager has had time to restore the attributes, or similar.

[quote user="nicky_liu"]I hope it can run correctly without stopping Uart RX, but I still can't achieve it at the moment.[/quote]

If it is important not to stop the UART RX then perhaps we should redirect the messages received on the UART to RAM or Flash storage (depending on the amount of data received in the time that a connection is broken), as a fix to this.
Could this be an option?
If this issue only is present when re-pairing, then you could add a specific error handling for this error, which is to store the data for later transfer, and then try again sometimes later. This error should disappear as soon as the Peer Manager has had enough time to update the attribute table, as mentioned above.
Could you try this, and see if it resolves your issue? I.e implement specific error handling for the 13313 error that stores the data you attempted to queue for later transfer, so that the peer manager has enough time to populate the attribute table.

Best regards,
Karl

RE: ble app uart

nicky_liu — Thu, 07 Oct 2021 09:57:08 GMT

Hi Karl：

1.Are you seeing this 13313 error frequently, or only at a given time in your program?

Ans : Currently the 13313 error only appears when I want to re-pair the device.

2.Could you check whether you are receiving this event in your PM event handler or not?

Ans : I have added the following LOG_INFO in the PM event, but it seems not to be executed.

        case PM_EVT_CONN_SEC_CONFIG_REQ:
        {
            // Allow or reject pairing request from an already bonded peer.
            pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
            pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
            NRF_LOG_INFO("device re-pair/n")　　
        }
            break;

3.Does the applications UART RX callback include a call to queue a notification with the received data? Could it be that the function attempts to queue data for a recently disconnected / unpaired device?
If so, you may handle this error by stopping the UART RX and storing the data you attempted to queue for transfer later, or discard the data entirely if it is not relevant later. How does this work with your application's constraints and requirements?

Ans : I hope it can run correctly without stopping Uart RX, but I still can't achieve it at the moment.

RE: ble app uart

Karl Ylvisaker — Wed, 06 Oct 2021 14:37:10 GMT

[quote user="nicky_liu"]Yes, line 617 in main.c is the APP_ERROR_CHECK following the call to ble_nus_data_send.[/quote]

Thank you for confirming this.
The 13313 error returned from ble_nus_data_send propagates from sd_ble_gatts_hvx, and as I've understood it usually means that you've tried to queue a notification for sending for a connection handle that the SoftDevice has not been provided any system attributes for. This should then generate a BLE_GATTS_EVT_SYS_ATTR_MISSING event, if it is the case. Are you seeing this 13313 error frequently, or only at a given time in your program? Other user's I've seen experience this reported that this error was only returned as a result of a call to queue a notification interrupted by a disconnected event or connected event - could this also be the case here?
If you retry the call to ble_nus_data_send once immediately after having received the 13313 error, does it still return 13313 on the second try?

When not using pairing / bonding this can be handled by adding the following into the ble_evt_handler:

case BLE_GATTS_EVT_SYS_ATTR_MISSING:
    err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0);
    APP_ERROR_CHECK(err_code);
    break;

When using pairing / bonding this should then instead be handled by the peer manager.
Could you check whether you are receiving this event in your PM event handler or not?

[quote user="nicky_liu"]After doing some experiments, I found that the problem of not being able to re-pair seems to occur when the Uart RX listen is not stopped and the device is unpaired. When I stop Uart RX listen first, and then unpair the device, this problem will not occur.
Is there a solution to this?[/quote]

This points in the direction of the aforementioned - that CCCD (notify) is enabled on the peripheral, and when the connection is broken the device may still be trying to send a notification, and/or upon the next reconnection it may generate the BLE_GATTS_EVT_SYS_ATTR_MISSING event to see if it has stored any information about this peer and its attributes (like the CCCD already being enabled from the previous connection).

Does the applications UART RX callback include a call to queue a notification with the received data? Could it be that the function attempts to queue data for a recently disconnected / unpaired device?
If so, you may handle this error by stopping the UART RX and storing the data you attempted to queue for transfer later, or discard the data entirely if it is not relevant later. How does this work with your application's constraints and requirements?

Best regards,
Karl

RE: ble app uart

nicky_liu — Tue, 05 Oct 2021 10:17:20 GMT

Hi Karl:
After doing some experiments, I found that the problem of not being able to re-pair seems to occur when the Uart RX listen is not stopped and the device is unpaired. When I stop Uart RX listen first, and then unpair the device, this problem will not occur.
Is there a solution to this?

RE: ble app uart

nicky_liu — Tue, 05 Oct 2021 09:27:33 GMT

Yes, line 617 in main.c is the APP_ERROR_CHECK following the call to ble_nus_data_send.
What should I do?

RE: ble app uart

Karl Ylvisaker — Tue, 05 Oct 2021 09:09:43 GMT

On a general note I also notice that you have quite a long path to your SDK location.
Please be aware of Window's 260 character path limit - anything exceeding 260 characters will be truncated.
This can cause quite a headache if not aware of it.
I recommend that you move you SDK location to be on top of your hierarchy, like C:\nordic\ or similar.

Best regards,
Karl

RE: ble app uart

Karl Ylvisaker — Tue, 05 Oct 2021 09:07:19 GMT

[quote user="nicky_liu"]Do you want these messages?[/quote]

Yes, exactly this, thank you.

[quote user="nicky_liu"]<error> app: ERROR 13313 [Unknown error code] at C:\Users\user\Desktop\nordic\nRF5SDK1702d674dde\nRF5_SDK_17.0.2_d674dde\examples\ble_peripheral\ble_app_uart\main.c:617
PC at: 0x0003230B
<error> app: End of error report[/quote]

The error report states that the APP_ERROR_CHECK was triggered on line 617 of main.c
Could you also confirm that the APP_ERROR_CHECK following the call to ble_nus_data_send in the code snippet that you have sent is in fact line 617 of your main.c?
It seems strange to me that this could return an unknown error code such as 13313 - this is usually the case when a non-error code is passed to an APP_ERROR_CHECK, or in the case that an uninitialized error code is passed to an APP_ERROR_CHECK.

Best regards,
Karl

RE: ble app uart

nicky_liu — Tue, 05 Oct 2021 08:23:37 GMT

Hi Karl：

Do you want these messages?

<info> app_timer: RTC: initialized.
<info> app: Debug logging for UART over RTT started.
<info> app: Connected
<info> app: Data len is set to 0xF4(244)
<info> app: Disconnected
<info> app: Connected
<info> app: Data len is set to 0xF4(244)
<error> app: ERROR 13313 [Unknown error code] at C:\Users\user\Desktop\nordic\nRF5SDK1702d674dde\nRF5_SDK_17.0.2_d674dde\examples\ble_peripheral\ble_app_uart\main.c:617
PC at: 0x0003230B
<error> app: End of error report

void uart_event_handle(app_uart_evt_t * p_event)
{
    static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];
    static uint8_t index = 0;
    uint32_t       err_code;

    switch (p_event->evt_type)
    {
        case APP_UART_DATA_READY:
            UNUSED_VARIABLE(app_uart_get(&data_array[index]));
            index++;
/*
            if(data_array[0] == 0x02 && data_array[1] == 0x01 && data_array[2] == 0x04 && data_array[3] == 0x03)
            {
            
              int dataLength = data_array[8] + data_array[9] * 256;
                if (data_array[8 + dataLength] && data_array[9 + dataLength] && data_array[10 + dataLength] && data_array[11 + dataLength] == 0xff )
                {
                    if (index > 1)
                    {
                        NRF_LOG_INFO("Send_data");
                        NRF_LOG_DEBUG("Ready to send data over BLE NUS");
                        NRF_LOG_HEXDUMP_DEBUG(data_array, index);

                        do
                        {
                            uint16_t length = (uint16_t)index;
                            err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
                            if ((err_code != NRF_ERROR_INVALID_STATE) &&
                                (err_code != NRF_ERROR_RESOURCES) &&
                                (err_code != NRF_ERROR_NOT_FOUND))
                            {
                                APP_ERROR_CHECK(err_code);
                            }
                        } while (err_code == NRF_ERROR_RESOURCES);
                    }

                    index = 0;
                }

                else if((data_array[index - 1] && data_array[index - 2] && data_array[index - 3] && data_array[index - 4] == 0xff) ||
                        (index >= m_ble_nus_max_data_len))
                {
                    if (index > 1)
                    {
                        NRF_LOG_DEBUG("Ready to send data over BLE NUS");
                        NRF_LOG_HEXDUMP_DEBUG(data_array, index);

                        do
                        {
                            uint16_t length = (uint16_t)index;
                            err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
                            if ((err_code != NRF_ERROR_INVALID_STATE) &&
                                (err_code != NRF_ERROR_RESOURCES) &&
                                (err_code != NRF_ERROR_NOT_FOUND))
                            {
                                APP_ERROR_CHECK(err_code);
                            }
                        } while (err_code == NRF_ERROR_RESOURCES);
                    }

                    index = 0;
                }
            }
*/
           // else
           // {
               // if ((data_array[index - 1] && data_array[index - 2] && data_array[index - 3] && data_array[index - 4] == 0xff) ||
               if ((data_array[index - 1] == '\n') || 
                   (data_array[index - 1] == '\r') ||
                   (index >= (m_ble_nus_max_data_len)))
                {
                    if (index > 1)
                    {
                        NRF_LOG_DEBUG("Ready to send data over BLE NUS");
                        NRF_LOG_HEXDUMP_DEBUG(data_array, index);

                        do
                        {
                            uint16_t length = (uint16_t)index;
                            err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
                            if ((err_code != NRF_ERROR_INVALID_STATE) &&
                                (err_code != NRF_ERROR_RESOURCES) &&
                                (err_code != NRF_ERROR_NOT_FOUND))
                            {
                                APP_ERROR_CHECK(err_code);
                            }
                        } while (err_code == NRF_ERROR_RESOURCES);
                    }

                    index = 0;
                }
        //    }
            break;

        case APP_UART_COMMUNICATION_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_communication);
            break;

        case APP_UART_FIFO_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_code);
            break;

        default:
            break;
    }
}

RE: ble app uart

Karl Ylvisaker — Tue, 05 Oct 2021 08:05:22 GMT

Hello again,

Could you show me the entire error message, preferably as a text string instead of a screenshot?
At the very end of the error message it tells you which line that failed the APP_ERROR_CHECK. Please also show me the code section (entire function) that triggered this APP_ERROR_CHECK. Please also use the Insert -> Code option when sharing code here on DevZone - this drastically increases it's readability.

Best regards,
Karl

RE: ble app uart

nicky_liu — Tue, 05 Oct 2021 07:07:34 GMT

Sorry, the wrong code should be in the red box below

RE: ble app uart

nicky_liu — Tue, 05 Oct 2021 04:14:10 GMT

Hi Karl:

The following is the message I received from debug Treminal. It seems to be caused by APP_UART_COMMUNICATION_ERROR in main.c

RE: ble app uart

Karl Ylvisaker — Mon, 04 Oct 2021 09:01:05 GMT

Aha, now I understand - I was under the impression that you were still talking about the sdk_config issue.

I do not immediately see anything wrong with this event handler, no.
Could you place a breakpoint in the PM_EVT_CONN_CONFIG_REQ section, to confirm that you receive this event when a new connection is made?
Are you able to pair, but not re-pair?
Which error are you getting when you attempt to re-pair?
What does you log say when this happens?

Best regards,
Karl

RE: ble app uart

nicky_liu — Fri, 01 Oct 2021 16:02:08 GMT

Sorry, I didn't express it clearly. After modifying sdk_config.h according to your suggestion, the program can work, but the device still cannot be re-paired. Can you help me confirm the modified part of the main.c file?

RE: ble app uart

Karl Ylvisaker — Fri, 01 Oct 2021 10:38:52 GMT

Hello,

Could you confirm for me that you have defined PEER_MANAGER_ENABLED 1 in your sdk_config.h file? Every driver or module that is not enabled in the sdk_config will be excluded from compilation.

Best regards,
Karl

RE: ble app uart

nicky_liu — Fri, 01 Oct 2021 10:24:28 GMT

I modified the code according to your suggestion, but the problem still exists. Can you check the modified part for me?

/**@brief Function for handling Peer Manager events.
 *
 * @param[in] p_evt  Peer Manager event.
 */
static void pm_evt_handler(pm_evt_t const * p_evt)
{
    ret_code_t err_code;
    bool       is_indication_enabled;

    pm_handler_on_pm_evt(p_evt);
    pm_handler_flash_clean(p_evt);

    switch (p_evt->evt_id)
    {
        case PM_EVT_CONN_SEC_CONFIG_REQ:
        {
            // Allow or reject pairing request from an already bonded peer.
            pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
            pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
        }
            break;

        case PM_EVT_PEERS_DELETE_SUCCEEDED:
        {
            advertising_start();
        }
            break;

        default:
            break;
    }
}


/**@brief Function for the Peer Manager initialization.
 */
static void peer_manager_init(void)
{
    ble_gap_sec_params_t sec_param;
    ret_code_t           err_code;

    err_code = pm_init();
    APP_ERROR_CHECK(err_code);

    memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

    // Security parameters to be used for all security procedures.
    sec_param.bond           = SEC_PARAM_BOND;
    sec_param.mitm           = SEC_PARAM_MITM;
    sec_param.lesc           = SEC_PARAM_LESC;
    sec_param.keypress       = SEC_PARAM_KEYPRESS;
    sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;
    sec_param.oob            = SEC_PARAM_OOB;
    sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
    sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
    sec_param.kdist_own.enc  = 1;
    sec_param.kdist_own.id   = 1;
    sec_param.kdist_peer.enc = 1;
    sec_param.kdist_peer.id  = 1;

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}



/**@brief Application main function.
 */
int main(void)
{
    bool erase_bonds;

    // Initialize.
    uart_init();
    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();
    peer_manager_init();

    // Start execution.
    printf("\r\nUART started.\r\n");
    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    advertising_start();

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}


/**
 * @}
 */

RE: ble app uart

Karl Ylvisaker — Fri, 01 Oct 2021 09:33:57 GMT

Hello,

It seems like you have not enabled the peer manager module in your sdk_config.
Please check the sdk_config of the ble hrs example to see how this could be done.

Best regards,
Karl

RE: ble app uart

nicky_liu — Fri, 01 Oct 2021 08:57:04 GMT

Hi Karl：

I am trying to modify the project file, but there seems to be some problems with the header, how can I solve it?

RE: ble app uart

Karl Ylvisaker — Thu, 30 Sep 2021 12:12:45 GMT

[quote user="nicky_liu"]Thank you for your reply[/quote]

No problem at all, I am happy to help!

[quote user="nicky_liu"]Is there any relevant example?[/quote]

You will need to add the peer manager to your application if you intend to support pairing, re-pairing and/or bonding. By default the ble_app_uart does not actually use any encryption / security as it is mainly meant as a demonstration of how to set up the most generic custom service.
There is indeed a couple of examples demonstrating the use of the peer manager, such as the Blood pressure example and heart rate example - both of which require a higher security level for their services.
You can also read more about the peer manager in general in its library documentation.

Please do not hesitate to ask if any part of this still should be unclear, or if you have any other questions about this!

Best regards,
Karl

RE: ble app uart

nicky_liu — Thu, 30 Sep 2021 10:44:57 GMT

Thank you for your reply, but I can't find pm_evt_handler() in the ble app uart example. Is it set by ble_evt_handler (SDK 17.0.2)? Is there any relevant example?

RE: ble app uart

Karl Ylvisaker — Thu, 30 Sep 2021 10:01:03 GMT

Hello again,

[quote user="nicky_liu"]I restarted an unmodified uart_app_ble project and used bebug Treminal. The information I received when I want to re-pair the device is as follows[/quote]

Thank you for testing this again with an unmodified version of the ble_app_uart example. My apologies for misunderstanding what you were seeking to achieve earlier, I now understand that you wish to allow for re-pairing of the connection specifically.
Re-pairing is by default not enabled in any of our examples, since this reduces the security of the connection. Please have a look at the answer by my colleague Einar in this ticket for additional detail, it also includes the necessary code to allow re-pairing in your application.

For future reference, please make sure to have DEBUG defined in your preprocessor defines like shown in the included image:

This will make a detailed error message be printed to your logger whenever a non-NRF_SUCCESS error is passed to an APP_ERROR_CHECK, instead of the shortform error message.

Best regards,
Karl

RE: ble app uart

nicky_liu — Thu, 30 Sep 2021 05:25:55 GMT

Hi Karl：

I restarted an unmodified uart_app_ble project and used bebug Treminal. The information I received when I want to re-pair the device is as follows

<info> app_timer: RTC: initialized.
<info> app: Debug logging for UART over RTT started.
<info> app: Connected
<info> app: Data len is set to 0xB6(182)
<info> app: Disconnected
<info> app: Connected <========When I want to re-pair
<info> app: Data len is set to 0xB6(182)
<error> app: Fatal error

RE: ble app uart

Karl Ylvisaker — Wed, 29 Sep 2021 10:28:18 GMT

No, I would like to see the loggers output from the nRF52832 that is connected to your sensor device.
Are you using Segger Embedded studios to do your programming?
If so, start a debugging session and click to view the debug terminal before you start the program - there should be a message reading "Debug logging for UART over RTT started." at the very start of the program, for instance.

Best regards,
Karl

RE: ble app uart

nicky_liu — Wed, 29 Sep 2021 09:51:22 GMT

Do you want to confirm the operation of the sensor device?
When the Ble is unpaired, the sensor will continue to send data to the BLE module through uart

RE: ble app uart

Karl Ylvisaker — Wed, 29 Sep 2021 09:14:51 GMT

Oh, my apologies - I meant to say that I would like to see the peripheral's side log.
The UART example by default logs using the RTT backend, which you can see either in the debug terminal in Segger Embedded Studios, or in the standalone RTT Viewer application by SEGGER.
Please instead show me this log for the scenario in which this behavior occurs.

[quote user="nicky_liu"]In the example of ble app uart, the code I modified is as follows:[/quote]

Thank you for specifying.

Best regards,
Karl

RE: ble app uart

nicky_liu — Wed, 29 Sep 2021 08:48:36 GMT

Hi Karl：

This picture is the message that appeared in the nRF Connect Log when I unpaired

The pictures are the screen that appears on nRF Connect when I want to re-pair again, and the message that appears in the log

In the example of ble app uart, the code I modified is as follows:

#define BLE_GATT_ATT_MTU_DEFAULT 247 //23

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(20, UNIT_1_25_MS) //20
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS) //70