Go into hardfault "NRF_BREAKPOINT_COND" while initialising

[it0406]

Hello developers,

I would like to combine BLE Central with USB HID. I am using the SDK example "BLE_Central_multilink", I can get signal from BLE modules.

Now I want to send data to PC through USB HID Protocol. I followed the example "usbd_hid_generic" and got finally no error from build.

However, the code go into hardfault while the initialising "err_code = nrf_drv_clock_init();" If I change the sequence, then from the other initialising.

If I debug it, this message is printed out "UNKNOWN FAULT at 0x0002DDE6".

If you help me to explain or solve the problem, I will very thank you.

I attatch my main code below

int main(void)
{
    // Initialize.

    log_init();
    timer_init();
    leds_init();
    buttons_init();
    power_management_init();
    ble_stack_init();
    gatt_init();
    db_discovery_init();
    lbs_c_init();
    ble_conn_state_init();
    scan_init();

    /* USB HID Intialization */
    ret_code_t err_code;
    static const app_usbd_config_t usbd_config = {
        .ev_state_proc = usbd_user_ev_handler
    };

    err_code = nrf_drv_clock_init();
    APP_ERROR_CHECK(err_code);

    nrf_drv_clock_lfclk_request(NULL);

    while(!nrf_drv_clock_lfclk_is_running())
    {
    } /* Waiting till running */

    //err_code = app_timer_init();
    //APP_ERROR_CHECK(ret);

    err_code = app_timer_create(&m_usb_hid_timer, APP_TIMER_MODE_REPEATED, data_transfer_timer_handler);
    APP_ERROR_CHECK(err_code);

    init_bsp();
#if NRF_CLI_ENABLED
    init_cli();
#endif
    printf("Hello USB!\n");
    err_code = app_usbd_init(&usbd_config);
    APP_ERROR_CHECK(err_code);

    printf("USBD HID generic example started\n");
    app_usbd_class_inst_t const * class_inst_generic;
    class_inst_generic = app_usbd_hid_generic_class_inst_get(&m_app_hid_generic);

    err_code = hid_generic_idle_handler_set(class_inst_generic, idle_handle);
    APP_ERROR_CHECK(err_code);

    err_code = app_usbd_class_append(class_inst_generic);
    APP_ERROR_CHECK(err_code);

    if(USBD_POWER_DETECTION)
    {
        err_code = app_usbd_power_events_enable();
        APP_ERROR_CHECK(err_code);
    }else
    {
        printf("No USB power detection enabled\r\nStarting USB now");
        app_usbd_enable();
        app_usbd_start();
    }

    // Start execution.
    printf("Multilink example started.\n");
    scan_start();

    for (;;)
    {
        
        idle_state_handle();
    }
}

Program information:

Segger Embedded Studio for ARM v5.50b

nRF52 SDK 17.0.2

Softdevice s140

codes based on PCA10056

Best regards

it0406

[Karl Ylvisaker]

it0406 said:

I appreciate your help again.

No problem at all, I am happy to help!

it0406 said:

I checked that there is just a internal rc clock. I tried again with the clock configuration and also "NRF_SDH_CLOCK_LF_SRC 0". It doesn't work yet.

Thank you for confirming this. If this was not the current issue then it would certainly have become an issue down the road anyways, so it's good to clear up. I have not worked with any feather modules myself - do they provide any documentation or guide for how to adapt a DK example / project to work with their module?

it0406 said:

I think that it could be more effective when I try to write code again from 0 or the original example with BLE Central.

I just mixed two examples, BLE Central Multilink and USBD HID Generic in this time. I guess, it is not a good way to use SDK examples.

I suppose the biggest thing to look out for is shared resources, as the SoftDevice must come first and be in control of all the peripherals detailed in the list I referenced earlier. Any overwriting of the SoftDevice's configuration's here will likely lead to an assert or hardfault.

I was able to dig up this old ticket by my colleague Sigurd, in which he includes a Multilink + USBD HID generic example - while the SDK used for this is old, the general approach should still be largely the same - especially so considering overlapping resources etc.
You could either try to match the approach used in the included example, or upgrade the example to the newest SDK version. In that case, you will need to go through the release notes of each newer SDK version to see if there are any changes that might affect these examples or the SoftDevice/USBD API. Keep in mind that this example is also made for a DK, so it will likely need some modification to work with the Feather module as well.

I hope this example by my colleague could come in helpful for you!

Best regards,
Karl