nRF52833 development

RE: nRF52833 development

Simonr — Fri, 14 Aug 2020 10:54:09 GMT

Sorry, my mistake. The bottom part is the stack section absolute address location and size (that is set in the adjustment. The stack, however, is placed at the top of RAM and grows down. If you check out the generated .map file, you can search for the symbol "__StackTop" to see exactly this.

Best regards,

Simon

RE: nRF52833 development

deknoob — Fri, 14 Aug 2020 07:19:18 GMT

I am using SES and this is what I think is indication which part of RAM is used. There is something at the top.
In fact I already tried powering off all of RAM8 and it crashed.

I also tried to change RAM size in linker, to bring all used RAM closer to bottom, but it also crashed when I power off RAM8.

RE: nRF52833 development

Simonr — Fri, 14 Aug 2020 07:02:16 GMT

The RAM should get filled up "from the bottom up", so depending on how much RAM your application uses, you should be able to turn off the "later" RAM pages of your application.

Best regards,

Simon

RE: nRF52833 development

deknoob — Thu, 13 Aug 2020 10:51:37 GMT

My application is using around 32KB of RAM. Hence I should be able to turn off power to some RAM sections. How can I find out which RAM sections I am able to power off in system ON mode, without application crashing?

RE: nRF52833 development

deknoob — Wed, 12 Aug 2020 12:39:35 GMT

Hi Simon,

I did not make any other changes to the app I included in last post, Just setting RTC callback to zero.

I am using nrf52840 DK for development and my application is drawing 2.8uA @3V while sleeping. There is absolutely no activity happening during sleep, except maybe for RTC ticks. I am quite happy with this, but trying to improve as much as I can because this product will have soldered battery which should last for 10 years. I will eventually disable some RAM and my target device is nRF52833 which has only half of RAM compared to 52840, so I will be able to reduce consumption.
Thank you for your support

RE: nRF52833 development

Simonr — Wed, 12 Aug 2020 12:12:00 GMT

I'm sorry, but setting the rtc_handler to 0 in the nrf_drv_rtc_init() bricks the device on my end. Have you made any other changes to your application to allow for this setting to 0? What current consumption is the best you're able to achieve? I've tested myself on an nRF52832 DK (the only DK I had at hand this morning, which according to the spec. should draw ~1.9µA in this mode) and got it down to ~2.3µA with very small adjustments to the RTC handler.

As for the 1.5µA that is stated in the spec. this is the absolute lowest possible current consumption you can achieve with the RTC running. This is a combination that's not really usable in and of itself as you will always need to have some RAM enabled if you'd want to execute interrupts, etc. The SDK examples are made to be generic and suit most use cases, and are likely in need of modifications in order to suit specific use cases. With the RTC module in the SDK with a usable application wrapped around it, getting the current consumption down to ~2.0µA should be feasible during sleep mode, depending on the application of course.

My apologies for any confusion and misunderstandings throughout this thread.

Best regards,

Simon

RE: nRF52833 development

deknoob — Tue, 11 Aug 2020 10:24:58 GMT

Hi again,

I figured out that if I change this line

err_code = nrf_drv_rtc_init(&rtc, &config, rtc_handler);

to this:

err_code = nrf_drv_rtc_init(&rtc, &config, 0);

then it seems to work fine, no bricking when all RAM power is off. Presumably replacing RTC callback routine by system reset vector. I guess 0 is system reset vector, is it?

Regards

RE: nRF52833 development

deknoob — Tue, 11 Aug 2020 07:25:26 GMT

Hi Simon,

My application is such that sensor sleeps for 8 hours, wakes up, performs soft reset, then starts advertising for few minutes, then goes back to 8 hour sleep. It stays in this loop forever. As you can see, battery life greatly depends on power during sleep. I hope to achieve 1.5uA sleep current as specified in product spec (wake on RTC event and no RAM retention)

I_{ON_RAMOFF_RTC}

System ON, no RAM retention, wake on RTC (running from LFRC clock)

1.50

µA

Actually, RAM retention is term applicable only for System OFF state (above table entry may be misleading because wake on RTC event assumes system is ON). I think the table entry should say "System ON, all RAM powered off, wake on RTC".

I have modified RTC example as below. After RTC timer is initialised, all of the RAM is powered off. When RTC interrupts, soft reset is called.

This is exactly what I want to do in my application. Result is that my nRF52840 DK bricks itself (I need to recover it by (nrfjprog --recover --family NRF52)

I actually expected this will happen because turning ALL of the RAM off is like "cutting the branch you sit on" 🙂

Can you illustrate example which results in 1.5uA current during timeout and wake on RTC?

/**
 * Copyright (c) 2014 - 2020, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */
/** @file
 * @defgroup rtc_example_main main.c
 * @{
 * @ingroup rtc_example
 * @brief Real Time Counter Example Application main file.
 *
 * This file contains the source code for a sample application using the Real Time Counter (RTC).
 *
 */

#include "nrf.h"
#include "nrf_gpio.h"
#include "nrf_drv_rtc.h"
#include "nrf_drv_clock.h"
#include "boards.h"
#include "app_error.h"
#include 
#include 

#define COMPARE_COUNTERTIME  (3UL)                                        /**< Get Compare event COMPARE_TIME seconds after the counter starts from 0. */

#ifdef BSP_LED_0
    #define TICK_EVENT_OUTPUT     BSP_LED_0                                 /**< Pin number for indicating tick event. */
#endif
#ifndef TICK_EVENT_OUTPUT
    #error "Please indicate output pin"
#endif
#ifdef BSP_LED_1
    #define COMPARE_EVENT_OUTPUT   BSP_LED_1                                /**< Pin number for indicating compare event. */
#endif
#ifndef COMPARE_EVENT_OUTPUT
    #error "Please indicate output pin"
#endif

const nrf_drv_rtc_t rtc = NRF_DRV_RTC_INSTANCE(0); /**< Declaring an instance of nrf_drv_rtc for RTC0. */

/** @brief: Function for handling the RTC0 interrupts.
 * Triggered on TICK and COMPARE0 match.
 */
static void rtc_handler(nrf_drv_rtc_int_type_t int_type)
{
    NVIC_SystemReset();


}

/** @brief Function configuring gpio for pin toggling.
 */
static void leds_config(void)
{
    bsp_board_init(BSP_INIT_LEDS);
}

/** @brief Function starting the internal LFCLK XTAL oscillator.
 */
static void lfclk_config(void)
{
    ret_code_t err_code = nrf_drv_clock_init();
    APP_ERROR_CHECK(err_code);

    nrf_drv_clock_lfclk_request(NULL);
}

/** @brief Function initialization and configuration of RTC driver instance.
 */
static void rtc_config(void)
{
    uint32_t err_code;

    //Initialize RTC instance
    nrf_drv_rtc_config_t config = NRF_DRV_RTC_DEFAULT_CONFIG;
    config.prescaler = 4095;
    err_code = nrf_drv_rtc_init(&rtc, &config, rtc_handler);
    APP_ERROR_CHECK(err_code);

    //Enable tick event & interrupt
    nrf_drv_rtc_tick_enable(&rtc,true);

    //Set compare channel to trigger interrupt after COMPARE_COUNTERTIME seconds
    err_code = nrf_drv_rtc_cc_set(&rtc,0,COMPARE_COUNTERTIME * 8,true);
    APP_ERROR_CHECK(err_code);


    //Power on RTC instance
    nrf_drv_rtc_enable(&rtc);


}

/**
 * @brief Function for application main entry.
 */
int main(void)
{
    leds_config();

    lfclk_config();

    rtc_config();

NRF_POWER->RAM[0].POWERCLR = 0x3; 
NRF_POWER->RAM[1].POWERCLR = 0x3;
NRF_POWER->RAM[2].POWERCLR = 0x3;
NRF_POWER->RAM[3].POWERCLR = 0x3;
NRF_POWER->RAM[4].POWERCLR = 0x3;
NRF_POWER->RAM[5].POWERCLR = 0x3;
NRF_POWER->RAM[6].POWERCLR = 0x3;
NRF_POWER->RAM[7].POWERCLR = 0x3;
NRF_POWER->RAM[8].POWERCLR = 0x3F;

    while (true)
    {
        __SEV();
        __WFE();
        __WFE();
    }
}


/**  @} */

But if I only power OFF RAM 8, like this

NRF_POWER->RAM[8].POWERCLR = 0x3F;

Then it doesn't brick itself.

What I meant is that some RAM must stay powered on during sleep.

Regards

Kerim

RE: nRF52833 development

Simonr — Mon, 10 Aug 2020 12:31:43 GMT

No problem at all, we're here to help you get a better understanding of nRF development. I should have been clearer in my explanation.

The RTC peripheral is its own independent peripheral and is not dependent on the app_timer in order to trigger a wake-up, as long as the peripheral is powered you won't be dependent on what the RAM is doing. You can take a look at the RTC peripheral example to see how you can use RTC without the app_timer.

Keep in mind that, depending on your application, you might not see a better average current consumption if you have to reinitialize a bunch of peripherals whenever your device wakes up due to the RAM not being retained, so it might be just as energy-efficient to have RAM retention if you save a lot of power on the wake-up process that way.

Best regards,

Simon

RE: nRF52833 development

deknoob — Fri, 07 Aug 2020 08:35:58 GMT

I am sorry for bothering you, but I think there is still a problem with sleep-wakeup sequence:

1. When sleep timer is created, pointer to sleep timer callback routine is stored in RAM (by calling app_timer_create)
2. RAM retention is turned OFF and device sleep timer starts counting. (by calling app_timer_start)
3. If there is no active task (for example advertising), device will go to low power mode. All RAM content will be lost
4. When sleep timer expires, CPU will have to fetch pointer to sleep timer callback routine (created in step 1.)

But at step 4 all RAM data is lost, including pointer to sleep timer callback routine. How can program execution go to sleep timer callback routine if pointer to it is destroyed

Best regards

RE: nRF52833 development

Simonr — Fri, 07 Aug 2020 07:01:11 GMT

Thank you for clarifying. When you're sleeping with no RAM retention, the RAM block(s) will be disabled and powered off. So when you wake up again, you would necessarily have to reinitialize your application again, either by doing a reset or by running the necessary init functions upon wake-up.

Best regards,

Simon

RE: nRF52833 development

deknoob — Thu, 06 Aug 2020 13:09:37 GMT

Hi Simon,

My understanding is that data stored to RAM with no retention will simply "evaporate" after some time. Basically, we are unplugging the power source to RAM.

If device goes to sleep and there is no RAM retention, then when device wakes up by RTC (after few hours), all data stored to RAM will be invalid, like stack and all other variables. And CPU could go to some undefined state when reading faulty data from RAM. Same would happen if you have RAM hardware fault for example.

This is why I think RTC wake up after sleep with no RAM retention has to be followed by device reset (or cold restart, reboot... such that RAM is first powered on and then initialised before being used). Or alternatively, at least some minimal part of RAM has to be retained.

RE: nRF52833 development

Simonr — Thu, 06 Aug 2020 08:25:47 GMT

Correct, the System ON, RTC, No RAM retention is the lowest power state allowing wakeups from an internal timer. I'm sorry, I'm not exactly sure I follow on the reset you're talking about. Is there any particular reason you need to go back on top of main upon wake-up? The RTC timer will be reset and triggered again once your device is put back to sleep, so I'm not sure what you're referring to here.

Best regards,

Simon

RE: nRF52833 development

deknoob — Wed, 05 Aug 2020 13:16:13 GMT

Thank you Simon for comprehensive answer.

Regarding 2., I am aware that I can't use SYSTEM OFF because I don't have external source to wake device up after timeout. As I understand, lowest power state which allows wake after long timeout is wake on RTC event and no RAM retention.

I am actually not sure if I have to do anything special to ensure device resets after RTC timeout, considering that all RAM context will be invalid when timer callback handler is called. Because pointer to timer callback handler is stored in RAM, is it?

RE: nRF52833 development

Simonr — Wed, 05 Aug 2020 11:51:12 GMT

1. The biggest difference between the two is that the nRF52840 has the CryptoCell feature for a crypto backend, unlike the nRF52833 which is using OBERON for this purpose. Other than that the RAM and Flash memory of the nRF52833 is halved compared to the nRF52840.

The changes you would need to make in a pca10056 project are, therefore:

As the nrf_crypto library provides a unified API. The only thing you need to do is to disable the CC310 backend in sdk_config.h by setting NRF_CRYPTO_BACKEND_CC310_ENABLED to 0, and enable the Oberon backend by setting NRF_CRYPTO_BACKEND_OBERON_ENABLED to 1, as well as setting the NRF_CRYPTO_BACKEND_NRF_HW_RNG_ENABLED to 1. You can compare with the sdk_config.h of the pca10040 project to see how this should be done, and they should be identical with regard to crypto configuration.
Next, you will also have to do these changes to your project settings. Change to device "NordicSemiconductor->nRF52833_xxaa". In the C/C++ preprocessor settings, remove the defines "NRF52" and "NRF52840_XXAA" and add the preprocessor define "NRF52833_XXAA". In the linker script settings, adjust the linker script to match the maximum RAM and Flash size of nRF52833. Remove the following files from the project: <compiler>_startup_nrf52.s and system_nrf52.c and add the following files to the project: <compiler>_startup_nrf52833.s and system_nrf52833.c.

2. You should be able to just do a system reset upon wake up in your application. Please note that SYSTEM OFF sleep would be the least consuming power-saving mode, and will trigger a reset upon wake-up. This will, however, not be able to use an internal timer to decide when to wake up, as the CPU would effectively be off for the sleep duration, and would need an external event to wake it up.

Best regards,

Simon