Device hangs after repeated use of ble_nus_data_send from ble_app_uart.

[ParanBada]

I am testing a BLE example that transmits 50 times per second (50Hz) using nRF52-DK(PCA10040) and SDK16's ble_app_uart.
After making an arbitrary value into a string using sprintf, it sends it by specifying the total length.

The above Timer Routine (main_routine_handler) is called every 1msec.
To transmit at 50Hz, add DATA_TX_50HZ and then transmit.

Android phone is Samsung S20 Ultra. Android 11 version.
The test app uses the UART app in nRF_ToolBox. It receives data smoothly and stops at some point. Stuck in the firmware of the nRF52-DK board.

What could be the cause?
I want to develop a firmware that continuously transmits 50 or 20 times per second for about 24 hours using ble_app_uart.
Does it matter if I call ble_app_uart at 50msec or 20msec intervals in Timer?
I seek help very urgently.

Please let me know how to solve the problem or if there is a suitable example.

[Einar Thorsrud]

Hi,

First of all, I would recommend you enable logging and test a debug build of your application (if using a SES example project as basis select the Debug build target, if not add two global defines for the project: DEBUG and DEBUG_NRF). If an error check has been hit this will let you know at which file and which line and with which error code. This is usually the first step in understanding an issue when using the nRF5 SDK.

Does it matter if I call ble_app_uart at 50msec or 20msec intervals in Timer?

Maybe. I am not sure if it is related to the issue you see or not, but I see that you handle NRF_ERROR_RESOURCES so that you attempt to send data again by calling ble_nus_data_send() until it is successfully queued. However, if for some reason data is not transmitted fast enough, then your timing will be off as you time by calling this function repeatedly (every ms). So it is not a good idea, you should instead call it as often as you hope to send data (every 20 ms). That will be more efficient and more robust.

[hmolesworth]

Also maybe add an extra test; might not help but recommended:

   // Also now check BLE_ERROR_GATTS_SYS_ATTR_MISSING or correctly set up due to timer race hazard
   if ((err_code != NRF_ERROR_INVALID_STATE)
    && (err_code != NRF_ERROR_RESOURCES)
    && (err_code != NRF_ERROR_NOT_FOUND)
    && (err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING))
   {
      APP_ERROR_CHECK(err_code);
   }