Hard Fault After BLE Connection in nRF52840DK FreeRTOS HRS Application Example

[omerBzkrt]

I am developing a BLE application on the nRF52 platform using FreeRTOS. My application involves custom BLE services and characteristics, and I am encountering a hard fault after a BLE connects after that it goes directly to the disconnection event. The hard fault occurs consistently, and I have added detailed logging to help diagnose the issue. The hard fault address is within the range of the linker ram_start and ram_size. I put a log file of the nrf52. I am trying to connect with my PC to nrf52. It gives same result when I try to connect with my phone.

I would appreciate any insights or suggestions on what might be causing this hard fault and how to resolve it. Specifically, I am looking for guidance on:

1. Potential causes of hard faults after BLE disconnection events.
2. Best practices for debugging hard faults in nRF52 applications.
3. Any known issues or common pitfalls related to BLE and FreeRTOS on the nRF52 platform.

Thank you in advance for your help!

<info> app: BLE Custom FreeRTOS example started.
<info> app: Fast advertising.
<info> app: BLE event received. Event type = 16

<info> app: BLE event received. Event type = 16
<info> app: Connected
<info> app: BLE event received. Event type = 85

<info> app: BLE event received. Event type = 85
<info> app: BLE event received. Event type = 58

<info> app: BLE event received. Event type = 58
<info> app: BLE event received. Event type = 35

<info> app: BLE event received. Event type = 35
<info> app: BLE event received. Event type = 19

<info> app: BLE event received. Event type = 19
<info> app: BLE event received. Event type = 36

<info> app: BLE event received. Event type = 36
<info> app: BLE event received. Event type = 21

<info> app: BLE event received. Event type = 21
<info> app: BLE event received. Event type = 33

<info> app: BLE event received. Event type = 33
<info> app: BLE event received. Event type = 80

<info> app: BLE event received. Event type = 80
<info> app: BLE event received. Event type = 34

<info> app: BLE event received. Event type = 34
<info> app: BLE event received. Event type = 18

<info> app: BLE event received. Event type = 18
<info> app: BLE event received. Event type = 18

<info> app: BLE event received. Event type = 18
<info> app: BLE event received. Event type = 26

<info> app: BLE event received. Event type = 26
<info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle:
<info> app: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bon
<info> app: BLE event received. Event type = 25

<info> app: BLE event received. Event type = 25
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bo
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Pe
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Lo
<info> app: BLE event received. Event type = 53

<info> app: BLE event received. Event type = 53
<info> app: BLE event received. Event type = 54

<info> app: BLE event received. Event type = 54
<info> app: BLE event received. Event type = 18

<info> app: BLE event received. Event type = 18
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Ce
<info> app: BLE event received. Event type = 82

<info> app: BLE event received. Event type = 82
<info> app: BLE event received. Event type = 18

<info> app: BLE event received. Event type = 18
<info> app: Fast advertising.
<info> app: BLE event received. Event type = 17

<info> app: BLE event received. Event type = 17
<info> app: Disconnected, reason: 0x13
<error> hardfault: HARD FAULT at 0x200072A4
<error> hardfault:   R0:  0x200071E8  R1:  0x20006514  R2:  0x00000001  R3:  0x2
<error> hardfault:   R12: 0x200078E8  LR:  0x000353FB  PSR: 0x20000000
<error> hardfault: Cause: The processor has attempted to execute an instruction

[Charlie]

Hi,

Thank you for reaching out about your issue. As you are aware, we do not provide official support for FreeRTOS, which means potential challenges will need to be addressed independently when choosing this path.

That said, we do have an expert who has worked with FreeRTOS, but he will be available only starting next week. I’ll check with him then to see if we can offer additional guidance on this problem.

From a general debugging perspective, hard faults are often related to RAM misuse or overflow. You might want to use debugging tools to identify the hard fault address in your code. I recommend reviewing Exercise 2 - Debugging with core dump and addr2line - Nordic Developer Academy from the Nordic Developer Academy for detailed guidance.

Best regards,

Charlie

[omerBzkrt]

Thank you for your reply, Charlie. While I was waiting for your reply, I tried ble_app_hrs without using the FreeRTOS option. It still produces the same result. After completing the pairing and bonding process, it transitions to a disconnect event. Before the connection was lost, it reported 0x12 - BLE_GAP_EVT_CONN_PARAM_UPDATE. Could this be the problem?

#define FIRST_CONN_PARAMS_UPDATE_DELAY      5000                                    /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY       30000                                   /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT        3                                       /**< Number of attempts before giving up the connection parameter negotiation. */


/**@brief Function for initializing the Connection Parameters module. */
static void conn_params_init(void)
{
    ret_code_t             err_code;
    ble_conn_params_init_t cp_init;

    memset(&cp_init, 0, sizeof(cp_init));

    cp_init.p_conn_params                  = NULL;
    cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
    cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
    cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
    cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
    cp_init.disconnect_on_fail             = false;
    cp_init.evt_handler                    = on_conn_params_evt;
    cp_init.error_handler                  = conn_params_error_handler;

    err_code = ble_conn_params_init(&cp_init);
    APP_ERROR_CHECK(err_code);
}