NCS for VS Code creating a project in Zephyr RTOS for ideal mode configuration and deep sleep mode configuration using power management library functions with Bluetooth example to achieve the defined current consumption in low power mode .

Hi 

I want to migrate my application to Zephyr RTOS platform from old setup given below.

  • Old Setup:
    Hardware: nRF52832 board. 
    Soft device: S132
    Software: SEGGER Embedded Studio
    SDK: nRF5_SDK_15.3.0

  • New Setup:
    Hardware: nRF52832 board. 
    Software: visual studio. version (1.87.2)
    SDK: nRF Connect for Visual Studio. Version (v2.5.2)

Zephyr RTOS environment with the new setup:

In the ticket, I found out that there is no separate soft device for nRF connect. https://devzone.nordicsemi.com/f/nordic-q-a/83481/nrf-connect-for-vs-code-and-softdevice

I have tried the example code of system_off (https://github.com/nrfconnect/sdk-zephyr/tree/v3.5.99-ncs1/samples/boards/nrf/system_off) on my customized board and measured the current using the joule scope meter (I am not using PPK2 setup). My device is consuming around 1mA of current.

According to the given value in the data sheet it should consume in 0.3µA. In my case it is not.

I have also testing the following listed functions in the nRF connect SDK by creating a new project and no other major functions used, but still the current consumption is around 1mA only.

  1. k_cpu_idle();
  2. k_sleep(K_FOREVER);
  3. rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
    if (rc < 0) { printf("Could not suspend console (%d)\n", rc);
    return 0; }
    sys_poweroff();
  4. NRF_POWER->DCDCEN=1;
     while(true);

With the old setup:

In my last project, using nRF SDK 15.3.0 with soft device S132. I am using the following power management functions to put the device into low power mode.(from the nRF SDK example "ble_app_buttonless_dfu")

static void idle_state_handle(void)
{
    if (NRF_LOG_PROCESS() == false)
    {
        nrf_pwr_mgmt_run();
    }
}

void powerManagementInit(void)
{
    uint32_t err_code = nrf_pwr_mgmt_init();
    APP_ERROR_CHECK(err_code);
}

sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);

Now I want to port into the Zephyr RTOS platform,

  1. What configuration adjustments in the nRF Connect SDK project would be necessary to achieve the same functionality (deep sleep mode, ideal mode/low power mode)?
  2. What other possible settings must I make in order to maintain the same functionality of my code since Zephyr RTOS does not support independent soft devices? There are no libraries in Zephyr RTOS that support soft devices.?
  3. In the "ble_app_buttonless_dfu" example code we have below function. what is the equivalent API to be used while porting into the Zephyr RTOS.
    // Initialize the async SVCI interface to bootloader before any interrupts are enabled.
        err_code = bleDfuButtonlessAsyncSvciInit();
        APP_ERROR_CHECK(err_code);

I've already opened a ticket regarding the porting task, but I wasn't sure how to move forward in this case: https://devzone.nordicsemi.com/f/nordic-q-a/110919/porting-the-application-from-nrf5_sdk_15-3-0-to-the-nrf-connect-sdk-for-vs-code . Since there is no 1-1 mapping of API of all functionalities as these SDK work on different fundamental concepts of one being baremetal and the other being RTOS based.

Please advise how to proceed with the VS code for the nRF Connect SDK Zephyr RTOS as I am finding difficulty in mapping the each functionality.

Kindly assist me with this issue of porting from nRF SDK to NCS for VS Code as I am stuck.

Your input will be appreciated.

Regards,

Naveed

  • Hello Naveed,

    I've already opened a ticket regarding the porting task, but I wasn't sure how to move forward in this case: https://devzone.nordicsemi.com/f/nordic-q-a/110919/porting-the-application-from-nrf5_sdk_15-3-0-to-the-nrf-connect-sdk-for-vs-code . Since there is no 1-1 mapping of API of all functionalities as these SDK work on different fundamental concepts of one being baremetal and the other being RTOS based.

    Yeah I can imagine that being a bit annoying. Like you've seen in this previous case of yours, it unfortunately isn't that straight forward to simply migrate something to NCS. You would essentially have to remake it from scratch, adding one element at the time. It might be a process to migrate an entire application, but hopefully you'll find the flexibility, the learning and the development process of NCS worthwhile. For more on the difference between the two SDKs, see here.

    I would first of all recommend you to have a look at our Dev Academy, which would help you on how to get started with NCS and how to develop with it. This is the first step you are looking for.

    Once you are done with the 'Fundamentals' course, have a look at the others in DevAcademy. Like the Intermediate and BLE one.

    Congrats on taking the first steps towards the nRF Connect SDK!

    In the ticket, I found out that there is no separate soft device for nRF connect

    Right. In NCS, we get the host layer of the stack from Zephyr, and the SoftDeviceController is automatically added when building the project in NCS. You get everything you need in one hexfile.

    What configuration adjustments in the nRF Connect SDK project would be necessary to achieve the same functionality (deep sleep mode, ideal mode/low power mode)?

    NCS is a bit different in the way that you don't have to do much to get low power consumption. It will perform great with just the idle thread running. Though there are ofcourse a few other things to keep in mind, like the use of peripherals which would affect the power consumption.

    What other possible settings must I make in order to maintain the same functionality of my code since Zephyr RTOS does not support independent soft devices? There are no libraries in Zephyr RTOS that support soft devices.?

    I am not sure if I understand. If by softdevices you mean closed source BLE stacks that are added independently from the application, then no, those are not needed/used. In Zephyr&NCS, the SDC and Zephyr host layer is added automatically. Though I should say that there are a few different versions of the SDC, and the correct version gets automatically added to the project depending on what features are enabled ( eg. Scanner functionality if CONFIG_CENTRAL is enabled). If you want to use the open source zephyr controller you can do so as well. 

    So everything needed for the BLE stack is added automatically.

    In the "ble_app_buttonless_dfu" example code we have below function. what is the equivalent API to be used while porting into the Zephyr RTOS.

    See here.

    Regards,

    Elfving

  • Hi Elfving,

    Thank you for you reply. Your inputs are much appreciated and will be very helpful in getting the NCS in the Zephyr RTOS platform going.

    I'm going to take the course that you have suggested. I have further queries concerning the implementation as I continue to migrate my application onto NCS. I will be communicating with you via the same ticket going forward.

    Currently my nRF52832 device is working on nRF SDK with the following hex files.

    1. Secure bootloader code hex file "secure_bootloader_ble_s132_pca10040.hex".
      SDK path: ..\..\nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_bootloader\pca10040_ble\ses
    2. Soft device hex file: "s132_nrf52_6.1.1_softdevice.hex"
      Path: ..\..\nRF5_SDK_15.3.0_59ac345\components\softdevice\s132\hex
    3. And my application hex file: my_application.hex

    Flashing steps:
    I am currently flashing my application program using two different steps,

    1. Only using nrf command line tool by running the script and programming (SBL+SD+my_application) using jlink.
    2. Using (nrf command line tool + nrf Connect mobile application), first generate the zip file using nrfgenpkg script, program the (SBL+SD) from the PC using nrf command line tool(by running the script) via jlink. And flash the generated zip file package with nRF Connect mobile application.



    I've learned that in order to program my freshly migrated application in the NCS, I need to use the MCU boot secure bootloader and SDC .Could you please clarify the necessary configuration and how to obtain these hex files to accomplish this? Correct me if I am wrong.

    How will I program my device in the Zephyr RTOS environment after upgrading to NCS? Will the process remain same what will be the change?

    Regards,

    Naveed

  • You do not need to worry about MCUBoot or anything else in order to flash something with NCS. Or atleast not more than with nRF5 SDK.

    The physical act of flashing/program can happen in two ways essentially. Either you flash it using a JLink debugger connected to the SoC you are flashing, or you are taking advantage of a bootloader being already on the SoC you are planning on flashing, and making it update it's application with what you are providing by essentially doing a DFU. This is practical in situations where you do not have a dedicated OB debugger on the board, like on the nRF52840 dongle. You do this the same way on the nRF5 SDK and in NCS.

    Naveed said:
    I've learned that in order to program my freshly migrated application in the NCS

    If you by "freshly migrated" do you mean that this is an application you want to move to a board that is already in the field, or with the customer? If so then you of course wouldn't be able to flash things in the normal way, since you do not necessarily have access to it. Though once again, that would also be a problem with nRF5 SDK.

    Naveed said:

    How will I program my device in the Zephyr RTOS environment after upgrading to NCS? Will the process remain same what will be the change?

    The programming will be the same. Things regarding bootloaders will be  bit more complicated than this, but the main thing to keep in mind is that now instead of 2 hex files (softdevice and app) you get 1 (app+host+SDC). So the flashing is easier, since there is only one file to worry about.

    Of course if you want to create an application for the nRF5340 which has two cores, or the nRF54, or if you are working on something for DFU, it might be a bit more complex. But generally it's as simple as this.

    Regards,

    Elfving

Related