softdevice enable +usbd -> deadbeef error

[Pegaze]

Hi,

I'm working on a project using BLE via s140, everything was working fine until I wanted to implement usb.

I created a blank project in order to validate the usbd then once validated, I implemented it to my BLE project.

when the code enable the softdevice, I'm redirected to app_error_fault_handler. You can see below id's error and p_info who tell me that err_code equal to 0xdeadbeef

Sometime I get 0x165 for the line_num.

It's noted that I'm using freeRTOS for my program and here is the memory mapping:

I also oversized freeRTOS heap's size to rule out any related problem.

thanks for your support

[Simonr]

What "imported sources" are these exactly? Are you able to see what line of code leads to this deadbeef error? I think some further debugging is necessary here to find out what exactly is conflicting with the SoftDevice.

Best regards,

Simon

[Pegaze]

Hi,

I apologize for the late response.

There is no particular line of code that causes this deadbeef. Let me explain, just after the call to the sd_softdevice_enable(); called by the function below, I'm randomly caught by this deadbeef before the end of the function.

ret_code_t nrf_sdh_enable_request(void)
{
    ret_code_t ret_code;

    if (m_nrf_sdh_enabled)
    {
        return NRF_ERROR_INVALID_STATE;
    }

    m_nrf_sdh_continue = true;

    // Notify observers about SoftDevice enable request.
    if (sdh_request_observer_notify(NRF_SDH_EVT_ENABLE_REQUEST) == NRF_ERROR_BUSY)
    {
        // Enable process was stopped.
        return NRF_SUCCESS;
    }

    // Notify observers about starting SoftDevice enable process.
    sdh_state_observer_notify(NRF_SDH_EVT_STATE_ENABLE_PREPARE);

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

    CRITICAL_REGION_ENTER();
#ifdef ANT_LICENSE_KEY
    ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler, ANT_LICENSE_KEY);
#else
    ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);
#endif
    m_nrf_sdh_enabled = (ret_code == NRF_SUCCESS);
    CRITICAL_REGION_EXIT();

    if (ret_code != NRF_SUCCESS)
    {
        return ret_code;
    }

    m_nrf_sdh_continue  = false;
    m_nrf_sdh_suspended = false;

    // Enable event interrupt.
    // Interrupt priority has already been set by the stack.
    softdevices_evt_irq_enable();

    // Notify observers about a finished SoftDevice enable process.
    sdh_state_observer_notify(NRF_SDH_EVT_STATE_ENABLED);

    return NRF_SUCCESS;
}

I know that debbugging with a softdevice is complex but the deadbeef appears with and without a breakpoint. I also tried to put the breakpoint after this function to be sure that the error does not appear because of the breakpoint.

Regarding the imported sources, here they are:

<file file_name="../../../../../../components/libraries/fds/fds.c" />
<file file_name="../../../../../../components/libraries/atomic_fifo/nrf_atfifo.c" />

<file file_name="../../../../../../components/libraries/fstorage/nrf_fstorage.c" />
<file file_name="../../../../../../components/libraries/fstorage/nrf_fstorage_sd.c" />

<file file_name="../../../../../../components/libraries/usbd/app_usbd.c" />
<file file_name="../../../../../../components/libraries/usbd/class/cdc/acm/app_usbd_cdc_acm.c" />
<file file_name="../../../../../../components/libraries/usbd/app_usbd_core.c" />
<file file_name="../../../../../../components/libraries/usbd/app_usbd_serial_num.c" />
<file file_name="../../../../../../components/libraries/usbd/app_usbd_string_desc.c" />
<file file_name="../../../../../../components/libraries/cli/uart/nrf_cli_uart.c" />
<file file_name="../../../../../../components/libraries/cli/nrf_cli.c" />
<file file_name="../../../../../../components/libraries/cli/cdc_acm/nrf_cli_cdc_acm.c" />
<file file_name="../../../../../../components/libraries/queue/nrf_queue.c" />

<file file_name="../../../../../../integration/nrfx/legacy/nrf_drv_power.c" />
<file file_name="../../../../../../modules/nrfx/drivers/src/nrfx_power.c" />

<file file_name="../../../../../../integration/nrfx/legacy/nrf_drv_uart.c" />
<file file_name="../../../../../../modules/nrfx/drivers/src/nrfx_uart.c" />
<file file_name="../../../../../../modules/nrfx/drivers/src/nrfx_uarte.c" />
<file file_name="../../../../../../modules/nrfx/drivers/src/nrfx_usbd.c" />

I hope I have been clear in this answer. If necessary, do not hesitate to ask me to clarify

Thanks for your support

[Susheel Nuguru]

Hi,

Pegaze said:

There is no particular line of code that causes this deadbeef. Let me explain, just after the call to the sd_softdevice_enable(); called by the function below, I'm randomly caught by this deadbeef before the end of the function.

 Normally the assert fault handler should give you a valid details of the line, file and instruction address that caused the assert, if you think that there is no valid code at the given addresses then it most likely is a memory corruption. If you have increased heap size in FreeRTOSConfig.h file and increased the stack sizes of your tasks accordingly, then you have atleast ruled out the stack overflow memory corruption. 

Is it possible to attach your project, so that i can try to replicate it here and attempt to debug inside softdevice if necessary?

[Susheel Nuguru]

This is inside your application and if you see your .map file, you should be able to atleast tell the context of which the assert happened. What is at this memory address 0x37c7d in your map file?

[Pegaze]

nrf_usb_ble__deadbeef.zip

Hi Nuguru,

In order to avoid any side effects, I created a project with only the uwbd and softdevice.

So here is the deadbeef error i'm getting:

As you advised, I went to look in my .map file at "pc" address. But I didn't find anything conclusive

I have at the same time look in memory but apart from the address 0x000324A7 where <e can observe DEADBEEF (maybe this is only coincidence), I do not see what could help me.

Normally my project is attached to this answer. I used the pca10056 board for this project.

Thanks for your support

[Susheel Nuguru]

Pegazee, really sorry for late response, . I will look into your project today.

[Susheel Nuguru]

This is an SDK error

And looking at the p_info structure, it gives the file name and line number

looking at nrf_drv_power.c line 0x165 which is deciman 357

It looks to me that this function is called without the nrf_drv_power being initialized. Setting a breakpoint here and running again shows the call stack

The nrf_drv_power_init is called in app_usbd_init which is called in your usbd_thread. But this thread does not start until the scheduler starts later on. 

Cleaner way would be just call this below before ble_stack_init

#if APP_USBD_CONFIG_POWER_EVENTS_PROCESS
    uint32_t ret = nrf_drv_power_init(NULL);
    if ((ret != NRF_SUCCESS) && (ret != NRF_ERROR_MODULE_ALREADY_INITIALIZED))
    {
        /* This should never happen */
        APP_ERROR_HANDLER(ret);
    }
#endif

I see that later you ble_advertising_init is failing with a wrong data size but that is a different error and seems like the data you are trying to fit into your advertising packet does not fit the legacy adv packet.

[Pegaze]

Thanks for your feedback !

I feel a little silly not to have thought of this.. The deadbeef error has probably disturbed me.

I fixed the error concerning the advertising packet and all works correctly on the pca10056 board.

Thanks again for your support !

I'm faced with an "error" when I try to run the code on my board.

The code reaches into the function:

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

but never leaves it.

No error is caught despite the fact that I waited 5-10min.

[Susheel Nuguru]

It seems like you verified this thread and hence it comes out of my queue. I opened it again to be able to watch it. 

 

Pegaze said:

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

 This is strange, but possible to happen if you have given the clock configuration wrong? 

It looks like you have set the NRF_SDH_CLOCK_LF_SRC in the sdk_config.h to XTAL. The softdevice might stall waiting for the XTAL to start if there is no XTAL or if your XTAL is not starting up as it should. Please check if this setting is right for you?