ble app uart

[nicky_liu]

Hi：

I use nrf52832 to connect to the sensor module through uart. When the sensor device is turned off, I can repeat the pairing and unpairing of the Ble module through the nRF Connect app. But after the Ble module pairing is completed and the sensor is turned on, when I cancel the Ble pairing and want to re-pair, I cannot scan the Ble device and cannot pair. How can I solve it

[Karl Ylvisaker]

Hello,

If the device does not show up again in the nRF Connect application scanner after a disconnect it is likely due to the device not advertising. 
Could you make sure that your device restarts advertising when a connection is disconnected?

Do I understand you correctly that you are working with the BLE UART example? If so, have you made any modifications to the example application?

Best regards,
Karl

[nicky_liu]

Yes, I am using the ble_app_uart example. For the example, I only modify MIN_CONN_INTERVAL and MAX_CONN_INTERVAL.

This problem only occurs when the sensor device is turned on, how can I modify it for the ble example?

[Karl Ylvisaker]

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

[nicky_liu]

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

[nicky_liu]

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

[Karl Ylvisaker]

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

[nicky_liu]

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;
    }
}

[Karl Ylvisaker]

nicky_liu said:

Do you want these messages?

Yes, exactly this, thank you.

nicky_liu said:

<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

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

[Karl Ylvisaker]

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

[nicky_liu]

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

[nicky_liu]

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?

[Karl Ylvisaker]

nicky_liu said:

Yes, line 617 in main.c is the APP_ERROR_CHECK following the call to ble_nus_data_send.

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?

nicky_liu said:

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?

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