Multiperipheral NUS crashes

[lee-marc]

Module:	ilumi H52 BLE module (nRF52832)
SDK:	nRF5_SDK_15.2.0_9412b96
Softdevice:	132_nrf52_6.1.0_softdevice.hex
Compiler:	gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-4)

I have integrated the code from example "ble_app_uart" into example "ble_app_multiperipheral". Unfortunately there is some strange behaviour:

(1) NUS in single- and multiperipheral mode:
If I send debug information to UART instantly after connection established, the module crashes.

(2) NUS in single peripheral mode:
NRF_SDH_BLE_PERIPHERAL_LINK_COUNT = 1
NRF_SDH_BLE_GATT_MAX_MTU_SIZE = 247

If I send a big amount of data from UART to BLE the modules crashes sometimes. I can't figure out why.

(3) NUS in multiperipheral mode:
NRF_SDH_BLE_PERIPHERAL_LINK_COUNT = 3
NRF_SDH_BLE_GATT_MAX_MTU_SIZE = 247 / NRF_SDH_BLE_PERIPHERAL_LINK_COUNT

The module crashes frequently. It depends on how much data is sent from UART to BLE. It does not depend on of how many central devices are connected.

for (uint8_t i = 0; i < NRF_SDH_BLE_PERIPHERAL_LINK_COUNT; i++)
{
  if (m_qwr[i].conn_handle != BLE_CONN_HANDLE_INVALID)
  {
    do
    {
      uint16_t length = (uint16_t)uart_rx_index;
      err_code = ble_nus_data_send(&m_nus, uart_rx_data_array, &length, m_qwr[i].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);
  }
}

I have no idea how to figure out the reason. How can I check if BLE buffer is full? What ways of debugging can I use to figure out why the module crashes?

[awneil]

lee-marc said:

What ways of debugging can I use to figure out why the module crashes?

What have you tried so far?

If you run from the debugger, what state is the system in when the "crash" occurs?

You may need to use Monitor Mode Debugging; eg, see https://devzone.nordicsemi.com/b/blog/posts/monitor-mode-debugging---revolutionize-the-way-you-debug-ble-applications and search for more references.

I had a case where it seemed that (too much) RTT debug was crashing the system - possibly crashing the J-Link itself. It was a Private case - maybe someone from Nordic could look into it ... ?

[Sigurd]

Hi,

lee-marc said:

What ways of debugging can I use to figure out why the module crashes?

If you are entering the APP_ERROR_CHECK()/app_error_fault_handler with an error-code, please make sure that you have DEBUG defined. (CFLAGS += -DDEBUG and ASMFLAGS += -DDEBUG in the makefile when you are using gcc). Please also remove compiler optimization (to get expected debug results, OPT = -O0 -g3).

lee-marc said:

gcc version 7.3.1

Note that we used GCC ARM Embedded 6.3 2017-q2-update for testing and verification for the SDK 15.2 release.

[lee-marc]

I have been using only UART outputs for debugging because I couldn't get working Segger RTT. Now Segger RTT is working and I get different error messages.

[lee-marc]

I have just got working Segger RTT. The flag -DDEBUG doesn't make any difference.

RTT sends different error messages.

NRF_SDH_BLE_GAP_DATA_LENGTH = 251:

<info> app: Multiperipheral example started.
<error> nrf_ble_gatt: sd_ble_gap_data_length_update() (request) on connection 0x0 returned NRF_ERROR_RESOURCES.
<error> nrf_ble_gatt: The requested TX/RX packet length is too long by 165/165 octets.
<info> app: Connection with link 0x0 established.
<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at .//main.c:395
PC at: 0x0002CAF7
<error> app: End of error report

If I set NRF_SDH_BLE_GAP_DATA_LENGTH = 80:

<info> app: Multiperipheral example started.
<info> app: Connection with link 0x0 established.
<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at .//main.c:395
PC at: 0x0002CAF7
<error> app: End of error report

[Sigurd]

Could you post the code-line you have at line 395 and 394 in main.c? Please also post the whole function that line 395 is a part of.