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

[it0406]

Hello Karl,

I am new here with nRF5 SDK and SoftDevice. So I didn't know that there are init functions for SoftDevice and not for it. 

Karl Ylvisaker said:

Could I ask why you are requesting the lfclk here?

I saw it in the usb hid generic example and thought that I need it to communicate a board with PC. 

Do you mean these calls, nrf_drv_clock functions? I tried to remove nrf_drv_clock_init and nrf_drv_clock_lfclk_request and run my code again. It meets the same hardware fault yet. I could use app timer function for ble example. So I didn't remove it.

Karl Ylvisaker said:

The app_timer library will use an RTC instance, and so you may use the app_timer library to create timers for your application needs without risking to access restricted or blocked peripehrals.
Try to remove these calls for direct clock control and let me know if it resolves your issue.

As I know, I need a clock to transfer data between a board and computer. If the calls will not be used, does it mean that they are not important for usb hid protocol? Or does SoftDevice have functions like them? 

Best regards,

it0406

[Karl Ylvisaker]

Hello,

it0406 said:

I am new here with nRF5 SDK and SoftDevice.

Welcome! This is good for me to keep in mind when writing my answers, thanks for letting me know! :) 

it0406 said:

I saw it in the usb hid generic example and thought that I need it to communicate a board with PC. 

it0406 said:

As I know, I need a clock to transfer data between a board and computer. If the calls will not be used, does it mean that they are not important for usb hid protocol? Or does SoftDevice have functions like them? 

Yes, the generic USB hid example does not use the SoftDevice, and so it must request the clocks manually. With the SoftDevice present the lfclk will always be running, and the hfclk will be running whenever needed by the SoftDevice or requested by the application.
The requests for the hfclk should then instead be made through the SoftDevice API - so that the SoftDevice may accept or reject them - such as through the sd_clock_hfclk_request function. The SoftDevice needs to be in complete control of the clock operations since it needs to meet timing-critical deadlines to maintain its BLE connections.

it0406 said:

Do you mean these calls, nrf_drv_clock functions? I tried to remove nrf_drv_clock_init and nrf_drv_clock_lfclk_request and run my code again. It meets the same hardware fault yet. I could use app timer function for ble example. So I didn't remove it.

Yes, it is the direct calls to control the clock peripheral that I am referring to.
Indeed you do not need to remove the app_timer - you can safely use this for your application's lfclk needs.
While this did not resolve this particular hardfault it is still good to have it checked out, as the issue would have come up down the line regardless.
It could however still be that the hardfault is triggered by a read or write operation into SoftDevice controlled memory, for example.

Could you open a debugger session and use breakpoints to figure out exactly how far in your program you are getting before the hardfault triggers? It would also be helpful if I could see the application code leading up to the hardfault triggering (not the hardfault handler, but your own application's code).

Best regards,
Karl

[it0406]

Hello Karl,

Karl Ylvisaker said:

Yes, the generic USB hid example does not use the SoftDevice, and so it must request the clocks manually. With the SoftDevice present the lfclk will always be running, and the hfclk will be running whenever needed by the SoftDevice or requested by the application.

So if I understand, clock will be automatically running from SoftDevice if it is neccessary. I don't need to initialise and call the function. 

Karl Ylvisaker said:

Could you open a debugger session and use breakpoints to figure out exactly how far in your program you are getting before the hardfault triggers?

Do you mean it maybe? The function "nrf_sdh_enable_request" will be called for ble_stack_init. I modified just main file and sdk_config.h from the example code. So I guess that it is possible because of SDK configuration, because I enabled and added some variables for usb hid. 

If it would be helpful, I attach it as file.

0675.sdk_config.h

Best regards

it0406

[Karl Ylvisaker]

Hello again, it0406

it0406 said:

So if I understand, clock will be automatically running from SoftDevice if it is neccessary. I don't need to initialise and call the function. 

This is correct, the SoftDevice will manage the peripherals as it needs.

it0406 said:

If it would be helpful, I attach it as file.

Thank you. I notice in your sdk_config that you have configured the low frequency clock source to be XTAL (NRF_SDH_CLOCK_LF_SRC) - Could you confirm for me that the Feather module actually has an external LFCLK XTAL?
Alternatively, you could try to set the clock configuration to the following:

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
 
// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
 
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#endif

// </h> 

Best regards,
Karl

[it0406]

Hello, Karl

I appreciate your help again.

Karl Ylvisaker said:

Could you confirm for me that the Feather module actually has an external LFCLK XTAL?

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.

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.

Are there some more configurations or lines which should be watched out from SDK? If I know them, it would be nice for the next try.

Best regards,

it0406