This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 example application runs into app_error_fault_handler

Hello,

We're evaluating the Laird BL654 using your nRF52840 (to be precise, we're using two DVK-BL654-1.0 development kits).We tried to use the 'blinky' examples (ble_app_blinky_c and ble_app_blinky) provided in nRF5_SDK_15.0.0_a53641a with the Segger Embedded Studio.OS was Win10.

Unfortunately, we ran into some problems.

0) At first, we couldn't step past ble_stack_init(). However, a coworker of mine found a document stating that clock source for the soft device had to be changed in nrf_sdh_enable_request().

With the new code (below) it worked:

    nrf_clock_lf_cfg_t const clock_lf_cfg =
    {
        .source       =  0, //NRF_SDH_CLOCK_LF_SRC,
        .rc_ctiv      = 16, //NRF_SDH_CLOCK_LF_RC_CTIV,
        .rc_temp_ctiv =  2, //NRF_SDH_CLOCK_LF_RC_TEMP_CTIV,
        .accuracy     = NRF_SDH_CLOCK_LF_ACCURACY
    };

1) After solving 0, we could step through the initialisation functions without a problem, but as we reached the main loop the step command (F10) let the device run forever; when we paused the execution, the PC sat at some assembler code not associated with the blinky C code. After stepping some time, the PC finally reached the app_error_fault_handler().

We also tried to add some dummy code to the main for(;;) loop, but the result was the same. Stepping through, it seems the problem seems to happen the 2nd time sd_app_evt_wait(); is called in ret_code_t nrf_pwr_mgmt_init(void). I'm willing to accept that there was no 'application event' and the application thus didn't return; still, there should be no (hard) fault.

2) We also tried to let the dev kit run free (F5, no breakpoint) and to connect with an other BLE application (called 'BLE Scanner', avaliable at the Playstore; it ran on a tablet with Android 6.0.1). The app found the 'blinky', and we were able to connect to the dev kit. However, the connection was closed again after 10-15 seconds by the dev kit/'blinky'.

Despite this, a peripheral and a central 'blinky' were able to establish a stable looking BLE connection and behaved as expected (in regard to LEDs flashing and Button 1).

My questions are:

-Why does the application run into a hard fault?

-How do we avoid it from getting struck in sd_app_evt_wait()?

-Why can't we connect (or, more precisely, stay connected) to the BLE Scanner app?

Best regards,

     Lasse

Parents
  • Hi,

    You can't single step the code after the softdevice have been enabled. The debugger will halt the CPU, preventing the softdevice from handling events. This will generate a hardfault.

    If you want the posibility of doing breakpoint/stepping debugging with the softdevice enabled, you should look into Monitor Mode Debug.

    It is hard to answer why you are sseing a disconnect. This can happen for many reasons. You need to provide a sniffer trace of the connection that we can use to check if there is some unhandled events. Since it is working together with the blinky central firmware, there seems to be some issue on the phone-side.

    Best regards,
    Jørgen

Reply
  • Hi,

    You can't single step the code after the softdevice have been enabled. The debugger will halt the CPU, preventing the softdevice from handling events. This will generate a hardfault.

    If you want the posibility of doing breakpoint/stepping debugging with the softdevice enabled, you should look into Monitor Mode Debug.

    It is hard to answer why you are sseing a disconnect. This can happen for many reasons. You need to provide a sniffer trace of the connection that we can use to check if there is some unhandled events. Since it is working together with the blinky central firmware, there seems to be some issue on the phone-side.

    Best regards,
    Jørgen

Children
No Data
Related