Issue when calling "ble_nus_c_string_send" multiple times to send multiple single bytes

[ACTILE]

Hi,

I am using the ble_app_uart_c example for the ble_central of SDK 12.2.0 to send data over UART to a nrf52832 based peripheral. When following the format as suggested in the example everything appears to be working fine (terminate data to be sent with \n). I sucessfully sent commands with 60 bytes and \n terminated spread across 3 BLE packets at 20 bytes payload each.

However, when commenting out the section that tests for \n or size>20 bytes my code stops working (see attached code snippet). I am basically trying to force sending each individual byte,  not only when certain conditions are met. When sending small amounts (less than 5 bytes) it still works ok, but when sending more than 5 bytes the code seems to be stuck at line "while (ble_nus_c_string_send(&m_ble_nus_c, data_array, index) != NRF_SUCCESS)" and I am struggling to find out why. Could someone please point me in the right direction?

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;

    switch (p_event->evt_type)
    {
        /**@snippet [Handling data from UART] */
        case APP_UART_DATA_READY:
            UNUSED_VARIABLE(app_uart_get(&data_array[index]));
            index++;

            //if ((data_array[index - 1] == '\n') || (index >= (BLE_NUS_MAX_DATA_LEN)))
            //{
                while (ble_nus_c_string_send(&m_ble_nus_c, data_array, index) != NRF_SUCCESS)
                {
                    // repeat until sent.
                }
                index = 0;
            //}
            break;
        /**@snippet [Handling data from UART] */
        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;
    }
}

[MartinBL]

Hi,

It would be interesting to see what value ble_nus_c_string_send() returns if not NRF_SUCCSS. Maybe you can change your code to something like this, and then debug to find out:

uint32_t err_code;
do
{
    err_code = ble_nus_c_string_send(&m_ble_nus_c, data_array, index);
}while(err_code != NRF_SUCCESS);

You can also add APP_ERROR_CHECK(err_code) between line 4 and 5 to have your code end up in an error handler and print your errors to a terminal. 

[ACTILE]

Hi Martin,

thanks for your help. I changed my code to what you suggested and also added the APP_ERROR_CHECK(err_code). The error code is 0x3004 and the error handler prints this:

0> SDH:DEBUG:sd_ble_enable: RAM start at 0x20001fe8
0> BLE_DB_DISC:INFO:Starting discovery of service with UUID 0x1 for Connection handle 0
0> BLE_DB_DISC:INFO:Found service UUID 0x1
0> BLE_DB_DISC:INFO:Discovery of service with UUID 0x1 completed with success for Connection handle 0
0> APP_ERROR:ERROR:Fatal

Can you see from that what the issue is?

Thanks

[MartinBL]

Hi,

Error 0x3004 is BLE_ERROR_NO_TX_PACKETS: 

// In file ble_err.h
#define BLE_ERROR_NO_TX_PACKETS          (NRF_ERROR_STK_BASE_NUM+0x004) /**< Not enough application packets available on this connection. */

// In file nrf_error.h
#define NRF_ERROR_STK_BASE_NUM  (0x3000)    ///< STK error base

It means that the TX buffer in the Softdevice is full, and that you can't queue more packets before one or more packets that are already queued are transmitted successfully. It is strange though, because a simple workaround for this is to do as you are already doing and keep on calling ble_nus_c_string_send() in a loop. What happens if you mask out the no packets error as well and use:

while((err_code != NRF_SUCCESS) && (err_code != BLE_ERROR_NO_TX_PACKETS));

Do you get any other errors?

You can also have a look at the ATT_MTU Throughput Example as well. The example shows how you can use BLE_EVT_TX_COMPLETE events returned from the Softdevice to queue packets only when there is space in the TX buffers. 

---

PS:

To make it print out more informative messages, you can change the code in app_error_fault_handler() in app_error_weak.c to something like this:

__WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
{
    static error_info_t  * p_error_info;
    p_error_info = (error_info_t*)info;
    NRF_LOG_ERROR("Error: ID: %d, PC: 0x%X\r\n", id, pc);
    NRF_LOG_ERROR("Error: Code: 0x%04X (%d), Line: %d, File: %s\n\r", p_error_info->err_code, p_error_info->err_code, p_error_info->line_num, (uint32_t)p_error_info->p_file_name);
    
    NRF_LOG_FINAL_FLUSH();
    // On assert, the system can only recover with a reset.
#ifndef DEBUG
    NVIC_SystemReset();
#else
    app_error_save_and_stop(id, pc, info);
#endif // DEBUG
}

[ACTILE]

Hi,

I tried masking out the "no packets" error but couldn't see any other errors, still only 0x3004. I will have a look at the throughput example and try to understand how to use the BLE_EVT_TX_COMPLETE event.

What concerns me is that the code seems to be stuck in this endless loop of waiting to sucessfully transmit packets and free up the queue. But it seems that after the first couple of bytes not a single packet gets transmitted sucessfully anymore. I would have expected that the queue gets cleared one by one as packets get transmitted. Is there an easy way to troubleshoot the reason for no packets being sucessfully transmitted?

[MartinBL]

Hi,

When I looked at your original code again I realized that you are not handling the index variable correctly. In your code index is initialized to 0. Then used to put your UART byte into an array. At line 11 index is incremented to 1 and then it is used as length of the string you want to transmit with ble_nus_c_string_send(). And then, at line 19 index is set to 0 again. And so it goes over and over. You will in other words never transmit more than 1 byte at the time.  I'm a little short of time so I haven't had the time to figure out why this seemingly causes everything to stall in an endless loop though. Anyway, you should try to implement some code that puts together a longer packet before you transmit the data. 

[ACTILE]

Hi,

yes my intention is to send single bytes. The problem is that my payload does not have a termination character and also does not have a fixed length. Therefore I don't know how many bytes are going to be sent and it is possible that my payload consists of only one byte.

[MartinBL]

Hi,

Sorry for the long wait. I have been out of office for a while.

Have you made any progress? I did some more testing and it seems like you may have stumbled upon a bug in S132 v3.0.0. If you try to upgrade to e.g. SDK v13.1 and S132 v4 then det code above seems to work. 

[ACTILE]

Hi,

thanks for your reply. Unfortunately I'm not having much luck with this. I compiled and flashed the UART examples for central and peripheral from SDK v13.1 and S132 v4 but still get an error when trying to send single bytes multiple times. At the moment the maximum amount of bytes I can send is 27 (that's 27 times 1 byte payload, so 27 packets). When attempting to send 28 bytes the transmitter resets and I am getting the following error message on the Segger RTT terminal:

 0> :ERROR:Error: ID: 16385, PC: 0x0
 0> :ERROR:Error: ID: 1, PC: 0x1AAA4
 0> :ERROR:Error: Code: 0x0579 (1401), Line: 1024, File: KGJ`hó

Are you able to decipher this error message?

Thanks.

[MartinBL]

Hi,

In this case the program counter (PC) points to an assert that originates inside the Softdevice (PC value is smaller than the Softdevice's flash size). I'll have to consult with the Softdevice team to get an explanation of the assert. Are you using S132 v4.0.2 which is bundled with SDK 13.1 by default? If so, can you try upgrading to v4.0.5? (Upgrading to v4.0.5 requires no changes in your code)