ble_app_uart_c losing characters

[Robin]

Hello again Nordic World.

We are slowly attempting to transition from the nRF51 environment to nRF52.  We are starting, not with development environment for our product, (it will remain at the 51 leve for now) but with the replacement of our nRF51 Dongles, which we use with the ble_app_uart_c code as a terminal interface to our board for testing.  We are attempt in to replace the nRF51 Dongle with the nRF52 DK.

The problem is that the ble_app_uart_c code from the 15.2 SDK, running on the 52 DK is dropping characters.   Please review the following snippets and note the alignment and missing characters which always seem to get lost in the 3rd column:

3689 4100 419 3689 4123 0 0 2 4100 4193 0 3689 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5190 4734 1
3682 4100 4193 3682 4123 -7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5191 4735 1
3682 4100 4193 3682 4123 0 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5192 4736 1
3682 4100 4193 3682 4123 0 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5193 4737 1
3682 4100 4193 3682 4123 0 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5194 4738 1
3689 4100 4193 3682 4123 7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5195 4739 1
3682 4100 4193 3682 4123 -7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5196 4740 1
3682 4100 4193 3682 4123 0 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5197 4741 1
3689 4100 4193 3682 4123 7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5198 4742 1
3682 4100 4193 3682 4123 -7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5199 4743 1
3689 4100 419 3682 4123 7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5200 4744 1
3682 4100 4193 3682 4123 -7 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5201 4745 1
3682 4100 4193 3682 4123 0 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5202 4746 1
3682 4100 4193 3682 4123 0 0 2 4100 4193 0 3682 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 5203 4747 1

Here is the exact same information as printed by the 51 Dongle under SDK 12.3:  Note the perfect alignment and no missing characters.

3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4861 4405 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4862 4406 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4863 4407 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4864 4408 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4865 4409 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4866 4410 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4867 4411 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4868 4412 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4869 4413 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4870 4414 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4871 4415 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4872 4416 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4873 4417 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4874 4418 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4875 4419 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4876 4420 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4877 4421 1
3710 4100 4193 3710 4123 0 0 2 4100 4193 0 3710 4123 0 4100 3400 0 4000 3300 0 1 1 0 0 4878 4422 1

Any ideas on where to search for and correct this problem is greatly appreciated.

Robin @ TL

Some additional information requested by stateside FAE:

The dropping is consistent in that the only characters dropped are the 16th, 17th, or possibly 18th (not know as both are spaces) in the first string sent.to each line.  However when it is dropped seems to be somewhat random.

The 52DK is connected form its u-usb connector on board to a USB-C on my computer by a short (~18") cable.

The only change is the hardware and the version of the unaltered example code running on each.

2 each 52DK's and 2 each cables have been tested.

[Robin]

Hi Edvin,

TX_BUFFER_MASK just masks the ring buffer index to only 32 entries. ( FYI, I got the buffer code from one of your colleagues).  

The snippets are not correction.  They are troubleshooting efforts to try to find this issue.

Do you know why any chars would be echoed back to the target over BLE?  That is what appears to be happening.

Robin @TL 

[Robin]

Edvin,

I found the "cause" of the above insertion of characters. There is a "new feature" in this newer uart central code that, by default, echoes everything back to the target over ble.  (Not sure why anyone would want to do this.  Perhaps you can explain this to me?

I have changed it and the insertion of characters is fixed.

from main.c:

...
#define ECHOBACK_BLE_UART_DATA  1                                       /**< Echo the UART data that is received over the Nordic UART Service (NUS) back to the sender. */
...
    if (ECHOBACK_BLE_UART_DATA)
    {
        // Send data back to the peripheral.
        do
        {
            ret_val = ble_nus_c_string_send(&m_ble_nus_c, p_data, data_len);
            if ((ret_val != NRF_SUCCESS) && (ret_val != NRF_ERROR_BUSY))
            {
                NRF_LOG_ERROR("Failed sending NUS message. Error 0x%x. ", ret_val);
                APP_ERROR_CHECK(ret_val);
            }
        } while (ret_val == NRF_ERROR_BUSY);
    }
...

However it is still dropping characters.

I now have RTT Viewer up and connected.  If you could guide on how to get these strings echoed to that terminal it would be very helpful.

[Edvin]

I suggest that if you have the RTT viewer up and running, and you can see the log messages from the application, that you check by sending a fixed string, so that you know what characters you are expecting, and then check if they are missing. It would be interesting to see whether the characters are dropped over the BLE link (which I find unlikely), or if they are dropped in the UART on the central.

Also, I suggest that you check the return values from your peripheral, inside send_chars():

static void send_chars(const char * str)
{
  if (connected)
  {
    uint8_t i = 0;
    while (str[i] != 0x00) 
    {
      i+=1;
    }
    uint32_t err_code;
    tx_buffer_insert(&m_nus, (uint8_t*)str, i);
    err_code = tx_buffer_process();
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_INFO("tx_buffer_process returned %x", err_code);
        // Alternatively, APP_ERROR_CHECK(err_code);
    }
  }
}

Alternatively, if you don't have logging on your peripheral, you can use APP_ERROR_CHECK(err_code);

Of course, you would need to make the function return the err_code:

uint32_t tx_buffer_process(void)
{
  uint32_t err_code = NRF_SUCCESS;
  if (m_tx_index != m_tx_insert_index)
  {
    
    err_code = ble_nus_string_send(m_tx_buffer[m_tx_index].p_nus,
                                   m_tx_buffer[m_tx_index].p_data,
                                   m_tx_buffer[m_tx_index].length);
    if (err_code == NRF_SUCCESS)
    {
      ++m_tx_index;
      m_tx_index &= TX_BUFFER_MASK;
    }
  }
  return err_code;
}

[Robin]

Hello Edvin,

So... I am up and running now, thanks to support from a state side FAE.  Seems there are some deep incompatibilities between SDK 12.3 and 15.3 w//r/t string/char xmission, that are somehow causing the drops.  I now have the 52DK running the 12.3 version of uart central (which was unaware was and option until the FAE set me straight) and all is well.  I am, however, a bit dismayed that something as basic as string and character handling is that different between SDK versions.  I am very interested in understanding exactly why, as our intentions for this product is to upgrade to the newer parts/sdk.  If you could enlighten me on what has changed w/r/t string and char handling that could cause this, I would very appreciative.  Beyond that you can close this case for now.

Thanks again  for all your efforts,

Robin @ TL

[Edvin]

Good morning Robin,

BLE links are lossless. That means that if a packet over the air is not received correctly, it needs to be retransmitted. This part is handled in the softdevice, and I have yet to see that it fails. 

Typically, in these cases, the issue is that the sd_ble_gatts_hvx() returns something other than 0, then this needs to be accounted for.

Some possible reasons why you may see different behavior in SDK12.3 vs 15.3:

-The SDKs use different preferred connection intervals, changing the available throughput, resulting in sd_ble_gatts_hvx() returning != 0.

-BLE throughput is not a continuous flow. The packets come in bursts. It may also be that the bursts with the new connection parameters (intervals) cause the UART to not finish the printing that you queued (printing received packets) before a new packet was coming in. This is why I asked you to check whether or not you can see that the chars are missing in the BLE events, before printing them over the air.