This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52833 development

Hello all,

I am working on low power sensor development with nRF52833 as target. I have some questions but I'm not sure it this was addressed in some other posts.

1. I don't have nRF52833 DK but instead I use nRF52840DK for development under SES environment. What in particular should I be aware of when generating target code for nRF52833?

2. I wan't to place sensor in sleep state for longer period of time. From product spec I understand that I should use wake on RTC and no RAM retention for lowest possible power. Because of no RAM retention, I need CPU to restart after timeout, not to go to application timer timeout handler but to top of main. How can I set this up?

Thanks

  • Hi

    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

  • 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?

  • Hi

    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

  • 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.

  • Hi

    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

Related