Hard Fault After BLE Connection in nRF52840DK FreeRTOS HRS Application Example

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

Parents
  • 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

  • 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);
    }
    

Reply
  • 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);
    }
    

Children
  • Omer,

    Happy New Year and thanks a ton for your patience. I took over this thread as I have good experience with FreeRTOS related issues.

    I see that you have tried your sample without the FreeRTOS and still having the hardfault issue (you said same result, so assuming that it is still the hardfault) ? 

    Failing connection update procedure should not give a hardfault but a normal app assert. Is this something I can reproduce? If yes, can you please give me steps to reproduce this and give the sdk version?

  • Thanks for your reply, Sushell. Happy New Year to you too. Let's go through your questions.

    I see that you have tried your sample without the FreeRTOS and are still having the hard fault issue (you said the same result, so I assume that it is still the hard fault). 

    * Yes, I tried with the SDK example of ble_app_hrs. After completing the pairing and bonding process, it transitions to a disconnect event. Actually, I tried different examples without making any modifications. When I try to connect Bluetooth via my PC, it goes to a disconnect event after pairing and bonding. For my project, it gives hard fault handler errors. 

    * The SDK version that I use is 17.1.0. 

    Is this something I can reproduce? 

    * Actually, I do not think so. The roadmap that I followed was like this: I took the ble_app_hrs_freertos example and built my service on it. The service works as an ADC sample sender, when the notification is active it sends an ADC value. While I was creating the notification timer I used xTimerCreate to fire the ADC sender event. Generally, the code works like that.

    * I used this link to create my service. 

    The first time, I did not try the bonding operation, I just used the nRF connect app to see the values. But now, when I am trying to connect with my PC, it goes disconnection event immediately after bonding and pairing occurred. 

    As I said in my first post, can it be the problem of Softdevice configuration? Because it gives an error in this range. Thank you in advance for your help!

Related