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]

Hello,

If I change the sequence, then from the other initialising.

Could you elaborate on what you meant by this?

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

Could you confirm that you have DEBUG defined in your Preprocessor Definitions of the Common build configuration, as shown in the included image?

This will make a detailed error message be written to your logger whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.
Please do this, and let me know what this error message says.

Best regards,
Karl

[it0406]

Karl Ylvisaker said:

Could you elaborate on what you meant by this?

I mean, I thought that there is the problem because of flow. For example, the clock should be initialized after timer initialization or before bluetooth low energy. I moved clock initialization between timer and ble initialization.

Karl Ylvisaker said:

Could you confirm that you have DEBUG defined in your Preprocessor Definitions of the Common build configuration, as shown in the included image?

They are all defined like below:

APP_TIMER_V2
APP_TIMER_V2_RTC1_ENABLED
BOARD_PCA10056
CONFIG_GPIO_AS_PINRESET
DEBUG
DEBUG_NRF
FLOAT_ABI_HARD
INITIALIZE_USER_SECTIONS
NO_VTOR_CONFIG
NRF52840_XXAA
NRF_SD_BLE_API_VERSION=7
S140
USBD_POWER_DETECTION

I thought that the problem comes from the pin setting. I corrected all pin setting from PCA10056 to nRF52840 Feather which I am using. I got now interrupt while ble_stack_init() with the message. I initialized also log to print out error message, but it doesn't work. So I am just using printf function.

HARD FAULT at 0x00032FE0
  R0:  0x2003FFAC  R1:  0x000287D9  R2:  0x20007BDC  R3:  0x00000001  R12: 0x20007B20  LR:  0x00033075  PSR: 0x01000000

I have also some questions.

Is there software flow diagram which I have to consider by programming?

I set the configuration just like from ble_app_multilink and usbd_hid_generic examples. If I combine these two examples, should I set more memory segment?

Memory Segment : FLASH RX 0x0 0x100000;RAM1 RWX 0x20000000 0x40000

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

[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