Call to nrf_sdh_enable_request fails in SDK v16.0.0 (works in SDK v15.3.0)

[RVM]

I am porting our firmware from SDK v15.3.0 to 16.0.0. I believe I have most of the changes in place
as I am able to build the boot loader and get it to execute without any catastrophic errors.

However, when I try to port a basic advertisement project to this newer SDK, the call to 'nrf_sdh_enable_request()'
triggers a fault. The issue is triggered by this call inside that function:

    sdh_state_observer_notify(NRF_SDH_EVT_STATE_ENABLED);

It appears that handler eventually in the file 'nrf_drv_power.c' checks to see if the local module
(i.e. m_initialized) is set to TRUE/1.

For reasons that I cannot currently triage, the combination of using SDK v16.0.0 and the preprocessor symbol DEBUG_NRF
triggers this failure. This issue disappears if I DO NOT define DEBUG_NRF in the build.

RMV

[Hung Bui]

Hi RMV, 

If you don't define DEBUG_NRF the ASSERT check with be masked and it may explain why it run fine without. 

Could you add some breakpoint and check what exactly throwing the error ? 

I'm a bit confused what exactly causing the issue, nrf_sdh_enable_request or a function inside nrf_drv_power.c

Did you add any modification into nrf_drv_power.c ? Could you give some more info on how you use the library in your application ? 

 

[RVM]

Hi Hung,

Thanks for your response, and it certainly confirms my suspicions too as to why I am seeing this behavior.
Below is the stack trace when the assert traps the error

And further down is a screen shot of the firmware that fails the assertion.

In SDK v16.0.0, one of the only places I see that the variable 'm_initialized' is set to true
with my specific SDK configuration is in this function below:

I call 'nrf_pwr_mgmt_init()' before 'nrf_sdh_enable_request()' but do I also have to call 'nrf_drv_power_init()'  ?

Cheers
RMV

[RVM]

Just an update.

I added a call to nrf_drv_power_init() after the call to nrf_pwr_mgmt_init()  -- not sure if the order is correct.
Now, I get the error "NRF_ERROR_SVC_HANDLER_MISSING" when the call to nrf_sdh_enable_request() internally calls 'sd_softdevice_enable()'

Cheers
RMV

[Hung Bui]

Hi RMV, 

I don't think the nrf_pwr_mgmt_init() is related to the nrf_drv_power library.

Could you let me know what exactly you are doing with the nrf_drv_power library  ?

I would suggest to have a look at one of our example in the SDK that uses the nrf_drv_power , for example the usbd_ble_uart example where we uses both the softdevice and the nrf_drv_power to handle the interrupt when USB power is plugged. 

NRF_ERROR_SVC_HANDLER_MISSING is not in the list of error code for sd_softdevice_enable(). Please double check if it's actually return error code 1. 

[RVM]

Hi Hung,

No, I did not plan to use the nrf_power_drv at all.

The only reason I did so was because the call to nrf_sdh_enable_request() ended up (via one of its registered handlers) making a call to 'nrf_drv_power_on_sd_enable()' which, as I indicated before, fails because the variable 'm_initialized' is FALSE.

And this variable is only ever set to TRUE if the nrf_drv_power module is initialized....

And our firmware does NOT intend to use the nrf_drv_power or the USBD.

This firmware design was working well for the past year or so but that was without defining the symbol DEBUG_NRF. This problem only occurs when I define DEBUG_NRF in the build.

The only reason I chose to set this definition was because it was set in one of the examples I was reviewing when trying to bring up the bootloader and buttonless DFU application.

I think I will revert back to not having this symbol defined and get on with my development plans for now.

Cheers

RMV