nrf_sdh_enable_request fails without USBD initiated first

https://devzone.nordicsemi.com/f/nordic-q-a/70679/call-to-nrf_sdh_enable_request-fails-in-sdk-v16-0-0-works-in-sdk-v15-3-0/291135?focus=true

I've been suffering from the same issue as in the above post. Except with SDK17.0.2

I find that if i have nrf_drv_power included, this results in an observer being registered for SD state change events, (line ~313 of the aforementioned file), the observer registered is: nrf_drv_power_sdh_state_evt_handler

When i then enable the soft device, this handler is called (soft device state changes when enabled), the action of this function call when the NRF_SDH_EVT_STATE_ENABLED event is received, is to call the function: nrf_drv_power_on_sd_enable();

This function checks the validity of "m_initialized" and subsequently asserts an error. (line 357).

Some of the legacy aspects to the code i am working with used a call to "app_usbd_init" before the soft device was enabled. I noticed this solved the error asserted by the aforementioned call.

I beleive this is because this function calls "nrf_drv_power_init" which in turn, sets m_initialised to true. Thus i can see why this function previously prevented the error.This all seems a bit sporadic and confusing. Additionally i no longer wish to use the USB driver and subsequently have no need for the legacy code. But of course, if i comment out the function and leave the file included. the observer is still registered and subsequently the error is still asserted.

Q1: I could just disclude the file. But I want to know why a power driver file would register an observer for softdevice events?

Q2: If i dont register this observer, if i disclude the nrf_drv_power file from the build this solves my issue, but what if i later want to use some other aspect of the nrf_drv_power file, i need to make sure the m_initialised variable is true? What function must i call do acheive this.

Q3: Upon searching for the m_initialised variable throughout the SDK i found it is declared across several files? How is it i dont see any symbol conflict errors from this?

  • Hi Sean,

    I will try to answer your questions

    Q1: I could just disclude the file. But I want to know why a power driver file would register an observer for softdevice events?

    The nrf_drv_power module is important to have if you want your application to handle POF events and if you are using USB and you want your application to handle USB power events. If you need none, then you can ofcourse remove this file so that it does not plug itself into the softdevice events. As you can see in the nrf_soc.h file NRF_EVT_POWER_FAILURE_WARNING is triggered from inside the softdevice and that is the reason for nrf_drv_power module to register itself to the softdevice events.

    Q2: If i dont register this observer, if i disclude the nrf_drv_power file from the build this solves my issue, but what if i later want to use some other aspect of the nrf_drv_power file, i need to make sure the m_initialised variable is true? What function must i call do acheive this.

    I tried to explain why we need this module in the first place. As an application designer you should make a choice if you need this feature or not. The application can of course choose not to handle POF or USB power events, it is all you who decide what you want your application to do in case of sudden power failures. Many application are just fine not to handle this event. for m_initialized variable, it is just the matter of initializing the power driver using nrf_drv_power_init. If you do not want to use the USB driver anymore in your application, then just initialize the nrf_drv_power module yourself in the application start before the softdevice enable. It was unfortunate that the legacy versions of our template application used USB initialization to indirectly initialize the nrf_drv_power module which seems to have confused you.

  • Hi Susheel,

    " If you do not want to use the USB driver anymore in your application, then just initialize the nrf_drv_power module yourself in the application start before the softdevice enable. It was unfortunate that the legacy versions of our template application used USB initialization to indirectly initialize the nrf_drv_power module which seems to have confused you."

    -That about summed up what i was looking to understand. you are correct in that the indirect initialisation is quite confuding as there is little annotation/documentation to explain it's initialisation. 

    Thanks,

    Sean

  • FYI: Trying to mark this thread as closed but the forum wont seem to let me.

  • no worries, I can marked it closed, Thanks for following up Slight smile

Related