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]

Hi

This seems to indicate that there is a priority issue with the USB implementation and some other part of your application? What priority level have you set the USB peripheral to? From the SoftDevice specification: The SoftDevice uss priority levels 0, 1, and 4 by default. So if the USB peripheral uses one of these priority levels as well, that would explain the conflict.

Best regards,

Simon

[Pegaze]

Hi,

Thanks for your rely !

I have checked and my softdevice task has a priority of 2. As for the USBD task, its priority is 0.

But I'm not sure this is due to a priority issue. During my research, I deleted the creation of the usbd task but despite this, i had the same error 0xdeadbeef. I therefore concluded that there could be a conflict between the softdevice and the sources imported for the usbd

Could that be possible ?

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?