Using nrf_regulators_system_off in newer Connect SDKs

[dboling]

I am having difficulty getting the nrf_regulators_system_off function to work correctly on newer versions of the Connect SDK.

In earlier versions v1.3 and such, the call would power down the 9160 to a very low current draw. Now, when I use it, i see a power draw compatible to all threads idle.

I suspect this has something to do with the rearchitecting of the SPM configuration file and that I'm not successfully granting non-secure rights to the power regulators but I'm not sure. All the posts on this topic (that I've found) are relatively old and reference older SDK versions.

It would be quite helpful to have a simple modern, example that compiled for the latest SDKs (I'm on v1.6.1 but v1.7 is fine) that powered off the 9160 and restarted it with a button press.

Thanks.

Doug

[Håkon Alseth]

Hi Doug,

 

I am having difficulty getting the nrf_regulators_system_off function to work correctly on newer versions of the Connect SDK.

In earlier versions v1.3 and such, the call would power down the 9160 to a very low current draw. Now, when I use it, i see a power draw compatible to all threads idle.

I suspect this has something to do with the rearchitecting of the SPM configuration file and that I'm not successfully granting non-secure rights to the power regulators but I'm not sure. All the posts on this topic (that I've found) are relatively old and reference older SDK versions.

It would be quite helpful to have a simple modern, example that compiled for the latest SDKs (I'm on v1.6.1 but v1.7 is fine) that powered off the 9160 and restarted it with a button press.

This example shows the usage of systemoff using the pm library:

https://github.com/nrfconnect/sdk-zephyr/blob/master/samples/boards/nrf/system_off/src/main.c#L93

 

Which effectively calls nrf_regulators_system_off here:

https://github.com/nrfconnect/sdk-zephyr/blob/v2.6.99-ncs1/soc/arm/nordic_nrf/nrf91/power.c#L19

 

In earlier versions v1.3 and such, the call would power down the 9160 to a very low current draw. Now, when I use it, i see a power draw compatible to all threads idle.

How much do you see now?

 

Kind regards,

Håkon

[dboling]

Thanks for the response. Perhaps I wasn't clear, the problem is controlling power from a non-secure app. The examples you reference seem to be compiled for secure mode. 

As far as power differences, my board has some extra stuff on it so I can't give absolute numbers. However, the difference between what used to work and the current builds is around 240 uA.

Doug

[Håkon Alseth]

Hi Doug,

 

It is hard to say what happens here, because the external devices are affecting the sleep current. This means that you have to ensure that any GPIOs going to external devices must be set to "idle" state before entering systemoff mode.

dboling said:

Thanks for the response. Perhaps I wasn't clear, the problem is controlling power from a non-secure app.

The NRF_REGULATORS register is by default set to non-secure:

https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/spm/Kconfig#L289

 

I do not think this is the issue. If it were permissions problem, you will have seen a fault occurring.

 

Kind regards,

Håkon

[dboling]

OK, I'll continue to work on it. One point, the initial code you pointed me was for the nrf52, not the 91. Is there an equivalent sample for the 91? Thanks.

Doug

[dboling]

One other point. Calling nrf_regulators_system_off results in exactly the same current as calling k_sleep with a Forever flag. Seems like I'm missing something.

Doug

[Håkon Alseth]

Hi,

 

dboling said:

OK, I'll continue to work on it. One point, the initial code you pointed me was for the nrf52, not the 91. Is there an equivalent sample for the 91? Thanks.

The sequence is similar for all nRF devices. You'll need to disable CONFIG_SERIAL in prj.conf, and in spm in order to use the sample.

 

dboling said:

One other point. Calling nrf_regulators_system_off results in exactly the same current as calling k_sleep with a Forever flag. Seems like I'm missing something.

This isn't that strange, as there's a very small difference between the two:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/_tmp/alta.nRF9160/autodita/CURRENT/parameters.id_current_sleep.html

 

Kind regards,

Håkon

[dboling]

Håkon,

I’ve discovered my issue has nothing to do with power down call.

The problem was a failure to initialize the NRF Modem library. The old modem firmware (1.2.3 and before) responded well to a non-init of the modem/bsd library if I was only powering down. The new modem firmware, not so much.

Once the call to nrf_modem_lib_init was made, I was able to get the power levels expected. The interesting thing is that the init call is required even if the device goes immediately into power down after a reset. My code detects a power down request, set a flag in the flash, resets the 9160 and powers down upon return. The change in behavior in the v1.3.0 modem firmware caught me unaware.

Thanks for your help.

Doug

[Håkon Alseth]

Hi Doug,

 

I'm glad to hear that you found a solution to the issue.

dboling said:

Once the call to nrf_modem_lib_init was made, I was able to get the power levels expected. The interesting thing is that the init call is required even if the device goes immediately into power down after a reset. My code detects a power down request, set a flag in the flash, resets the 9160 and powers down upon return. The change in behavior in the v1.3.0 modem firmware caught me unaware.

My apologies for the inconvenience this caused! the modem is awaiting commands from the application, ie. a initialization, which accounts for this added consumption.

 

Kind regards,

Håkon

[ben]

Just wanted to say thanks for this thread, it helped me a bunch

[Håkon Alseth]

Glad to hear that you found help in this thread. If you run into any issues or have questions, please feel free to contact us. I hope you have a wonderful weekend when that time comes!

 

Kind regards,

Håkon