What is the power and clock model of peripheral in NRF51?

[paulinx]

Hello,

I was puzzled by RM.

I notice POWER control register in peripheral(UART,SPI,TWI) module.

Please answer following questions about the relation between system power and the peripheral power register value.

1. Will UART be powered when system power off and uart register power on?
2. Will UART be powered when system power on (constant latency) and UART register power off?
3. Will UART be powered when system power on (low power) and UART register power off?

====================================================

Will system control logic shutdow power of modules when system in power on (low power) mode?

Alternatively, you can answer next question.

Is there any possible that UART be power off by control logic, when system power on (low power) and UART register power on?

If yes, can registers retention their values?

=====================================================

What does IDLE and RUN mean in RM/PS, is it something about clock gating?

Is IDLE the only low power mode of model?

If yes:

1. Will module clock be automatically gated in IDLE mode?
2. How does control logic knows module in IDLE mode?
3. Can clock automatically on when needed, eg. new byte comes in UART?
4. Is this schematic transparent to software?

===================================================

What is the relationship between ENABLE and IDLE state?

Is it possible for a module to enter IDLE when ENABLE is true?

For UART,

1. Will it be IDLE when not enabled?
2. Will it be RUN once enabled?
3. Will it be IDLE when not transmitting and not receiving?
4. Will it be RUN only when transmitting or receiving?

Thanks a lot!

Edit: format, tags.

[Ole Morten]

For information on the low frequency clock model (32kHz), look at this thread.

For information on the high frequency clock model (16MHz), look at this thread.

With the nRF51822, there is just two power modes you need to be aware off, system on idle and system off.

System on, idle In this mode, all peripherals that are enabled when entering sleep stays enabled, and you can wake up on any interrupt. All clocks and regulators that are not required by a running peripheral will be turned off, but all RAM and registers are retained. When the chip comes out of sleep, it continues where it left off.

With the softdevices, you can enter this sleep mode using sd_app_event_wait(), and if you don't use the softdevice, you can use __WFE(). sd_app_event_wait() function (inside power_manage() function) is used in most of the examples in the nRF51 SDK. An example on how to use __WFE() is given in the system-on-wakeup-on-gpio example on Nordic's Github.

The base current consumption in this mode is given in table 32 in the nRF51822 PS v3.1 as I_ON, 2.6 µA. The current consumption of any running peripheral, and their required clocks and regulators will come on top of this. The block requirements of the different peripherals can be seen in table 33 in section 8.3 in the nRF51822 PS v3.1.

Sub-power modes There are also two sub-power modes, the default LOWPWR, and CONSTLAT. These are described in section 11.1.4 in the nRF51 Reference Manual. Using the CONSTLAT mode will keep the 16 MHz clock running all the time, so that the wake-up time is constant and low (< 3 µs). This comes with the cost of having the 16 MHz clock always running, even when no peripherals need it, which gives a consumption increase of several hundred µA. The default is to use LOWPWR.

System off In this mode, all peripherals, clocks and regulators are turned off, and the only wake-up sources are a reset and GPIOs with SENSE configured (SENSE field in PIN_CNF set to low or high). By default, all RAM is also turned off, but this can optionally be kept on by changing the RAMON register. When the chip comes out of this sleep mode, it always starts from reset, and RAM (if not configured otherwise) and registers that are not marked as retained are cleared. See table in section 11.1.7.8 in the nRF51 Reference Manual for details on reset behavior.

With the softdevices, you can enter this mode with sd_power_system_off(), and without them, by writing 1 to the SYSTEMOFF register in the POWER peripheral. When entering system off, all peripherals are automatically turned off, so no preparation is needed.

The base current consumption in System Off is given in table 32 in the nRF51822 PS as I_OFF, 0.6 µA. RAM retention increases this, as stated in the same table. Since all peripherals and clocks are turned off, which peripherals are enabled when entering this mode doesn't matter for the current consumption.

General considerations All peripherals are per default off, and only peripherals that have been explicitly enabled will be on at any time. To achieve low current consumption with the nRF51, the general recommendation is therefore to only turn perpiherals on for as short time as possible, and explicitly turn them off whenever they are not needed. This is usually done by writing a Disabled value to the peripheral's ENABLE register, and will ensure that they don't keep the clock running when it isn't actually needed.

In addition, it's always safe to enter system on, idle, from the main context, since whatever has been enabled before you enter this mode will stay enabled through it. This is therefore very well suited to be the only action in the main loop, and you should make all other actions in your application depend on interrupts or events coming either from perpiherals (timers) or from the BLE/ANT stacks.

Use system off only when you can live with requiring user action (i.e. button presses) to wake you up again, and with a reset being done (i.e. when you don't have any state information that you need to preserve).

Finally, when doing current measurements, remember that the debug interface of the nRF51 consumes > 1 mA, so do a power-on-reset after flashing. See this question for details.

Edit: Some clarifications.

[paulinx]

OK, I got something from your answer. Please correct me if i made mistake in followings.

1. In off mode, everything can be turned off are turn off from clock, turn off from power, no retention.

2. In constant latency mode, every power and any clock are forced on, even in wfi.

3. In low power mode, when in wfi, peripheral, which is not enabled, is not clocked and power off with retention. When not in wfi, every module is powered and clocked.

4. So if I explicitly power off some module that i need not throughout my application by POWER register, i will save power in RUN mode.

Am I right?

[paulinx]

Can anyone answer my new questions?

[Ole Morten]

1. When you enter system off, everything is turned off automatically, and no preparation is needed.

2. Only the 16 MHz clock is forced on in CONSTLAT, not anything else.

3. Both in WFI and when running normally, only peripherals that have been enabled are powered.

4. See above. The only thing you should care about is to enable peripherals when you need them, and disable them as soon as possible afterwards, no matter if you are currently running or sleeping.

I've also tried to clarify the above answer somewhat, so I'd be happy if you could accept it if you found it useful, by clicking the "Accept as answer" button below it. That makes it easier for others to find. :-)

[roger hayes]

Ole - Thanks for your comments - Please keep going:

[b]YOu said "System on, idle In this mode, all peripherals that are enabled when entering sleep stays enabled, and you can wake up on any interrupt. All clocks and regulators that are not required by a running peripheral will be turned off, but all RAM and registers are retained. When the chip comes out of sleep, it continues where it left off.

With the soft devices, you can enter this sleep mode using sd_app_event_wait(), and if you don't use the softdevice, you can use __WFI().

The base current consumption in this mode is given in table 23 in the PS as I_ON, 2.3 µA. The current consumption of any running peripheral, and their required clocks and regulators will come on top of this. The block requirements of the different peripherals can be seen in table 24 in section 8.3 in the nRF51822 PS. "[/b]

1. Further - I cannot seem to get below 1.69Ma current loading w/ the _WFI as per above. The wait is work ing well (per a gpio LED flask between loops) and i see the current drop from about 4.2Ma while active and the lower when it's sleeping. This is still WAY too much current loading for the life we're looking for. Assuming that the RTC requires a clock, what are our options on killing the peripherals. In my case, ADC is disabled, and the ANT is not enabled yet.

2. Where can one find competent, complete examples of the nrf_wait_for_app_event calls?? The documents leave LOTS to be desired and cause lots of struggles w/ the new-comers to NS. Other makers are flooded with examples and variations of them - NS does not seem to have it there..??

3. Note that I notice lots of examples referencing the BTE development sets (that are still Corex-0 based?) but are missing from the NRF (ANT sdk) examples? Are they interchangeable, excluding the radio basis'. Why are the examples not global to the SOC's?

4. I stumbled into getting the nrf_wait_for_app_event working a few days ago (my fault) but cannot seem to get it working again. I had it to ~.00-3Ma at one point but lost it and did not consider that it would be this difficult to get it running again. I've never gotten it to work since.

tks!