To identify, adjust sleep period of sample app threads?

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Fri, 08 Apr 2022 08:28:56 GMT

[quote user="tedhavelka"]Thank you for helping me to track down the rogue thread, a run-time result of ncs v1.6.1 aws_iot sample app calling at_configure() ncs API routine in its main.c source file.[/quote]

No, the at_configure() isn't involved. The problem is the at_host library, which runs in the background and don't interract directly with the application.

[quote user="tedhavelka"]By the way I notice that in ncs v1.9.1 aws_iot main.c there is no longer any call anywhere to at_configure()[/quote]

Yes, we have reworked the AT command interface, so the at_cmd() and at_notif() libraries no longer is needed.

Instead, you can use the AT command interface in the modem_lib directly: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrfxlib/nrf_modem/doc/at_interface.html

[quote user="tedhavelka"]Will you please mark this Devzone post as answered?[/quote]

I'll see if I can find some usefull answers to mark as verified.

Best regards,

Didrik

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 07 Apr 2022 19:13:51 GMT

Hello Didrik,

Will you please mark this Devzone post as answered? I strayed from the original threads question at points, but the answers for tracking down the mystery thread in my aws_iot sample based app are here. Plus the related Zephyr thread debugging questions have also been answered. Following Håkon's instructions for gdb server and gdb in each their own terminal window provides me run time inspection of Zephyr 2.6.0 threads in a custom app.

Thanks,

- Ted

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 07 Apr 2022 18:16:25 GMT

Hello Didrik,

Regarding nRF9160 GPIO settings I will open a new Devzone ticket. Thank you for helping me to track down the rogue thread, a run-time result of ncs v1.6.1 aws_iot sample app calling at_configure() ncs API routine in its main.c source file.

By the way I notice that in ncs v1.9.1 aws_iot main.c there is no longer any call anywhere to at_configure().

As for the attached low power examples, I only want to note that I've yet to obtain approximate 3uA deep sleep current readings. The first of the five versions of attached hello_world I could build and run, but draws about 3mA on nRF9160DK board rev 1.0.0 (known issue there you note and link to an errata sheet). The later attached projects I cannot build. A modified version I tried to adapt, and eventually in Devzone post 86265 draws too little current for me to trust, about 46nA. Have further testing to perform, and I may open a new ticket on the low power sample app question too.

Thank you again for the detailed help and your patience Didrik. Stay safe,

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Thu, 07 Apr 2022 15:14:33 GMT

[quote user="tedhavelka"]I no longer see any periodic ~25Hz to ~33Hz current pulsing[/quote]

That's great!

[quote user="tedhavelka"]Kindly tell me whether this question group is best to open in a new Devzone ticket[/quote]

They are a bit outside of my area of expertise and given that we found the rouge thread (and you no longer see the current pulsing), I think those questions are best answered in a new ticket.

[quote user="tedhavelka"]As always thank you, Didrik[/quote]

You're welcome.

Best regards,

Didrik

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Wed, 06 Apr 2022 17:10:44 GMT

Thank you Didrik,

Your mention of the separate power supply, I believe nRF9160 datasheet names it VDD_GPIO or similar, reminds me of a related question: what is or are the correct Zephyr 2.6.0 GPIO configuration to assign to nRF9160 general purpose I/O port pins,

(a) when I/O pin acts as a chip select line to external device, which itself is powered off (at ground state)

(b) when I/O pin in wake mode receives interrupts from external device,

To be clear, during active wake times of nRF9160 + external circuit + firmware, I will configure I/O pins for their normal input or output uses, and set pull-ups and pull-downs as needed. But to enter deep sleep mode and avoid unintended "bleed" currents to and from nRF9160 GPIOs, I expect I must in some cases change pin configurations at run time or "on the fly". Is my understanding in this correct?

Kindly tell me whether this question group is best to open in a new Devzone ticket.

I ask this I/O config question, due to modest progress with my team's custom 9160-based board. My latest efforts to modify project firmware to emulate the settings and action of your low power hello_world have gotten me to sub-one-hundred uA current draw. It is true my custom board differs from the nRF9160DK kit. In particular, I can only measure total board current, I don't have a break out solder bridge or test points pair to look only at nRF9160 VDD current use. But this measure-all-board-current is good. I need to bring total board current down to very close to nRF9160 advertised lowest current for battery life requirements.

The code I run is also still different code with respect to attached low-power code samples. In my firmware project I've commented out everything I may reasonably disable. Given custom board however I wrote and use custom board files (dts, yaml). These depart from your shared hello_world sample apps.

So I am trying to adapt my firmware as near as possible to your hello_world configuration settings and run time functionality. I no longer see any periodic ~25Hz to ~33Hz current pulsing, just small steady current in tens of microamps. I suspect GPIO mis-configuration.

As always thank you, Didrik. Once I solve our low current conundrums I will share a practical summary of steps taken plus what works.

- Ted

( p.s.: I have tested three different Zephyr GPIO pin configurations, which I set in code sequence to enter my custom firmware into deep sleep mode. These configurations include (1) GPIO_INPUT with weak pull-down enabled, (2) GPIO_OUTPUT with output set low, (3) GPIO_DISCONNECTED. These settings I apply to pins which are connected to external sensors, FETs, memory which are themselves at that point powered down. I actually see more current consumption on our custom board when I attempt these settings, than when making no explicit GPIO configuration at all. Strange. I am now working through one and a few pins' settings at a time and building a table of current measurement results, to narrow down whether one or a few pins are contributing the additional currents. But there are many combinations of configurations possible, and pins to configure, which motivate my latest questions! )

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Wed, 06 Apr 2022 15:40:59 GMT

[quote user="tedhavelka"]Question - with PPK II connected to "nRF Current Measurement" jumper, is it true that I am measuring the current consumed only and only by the nRF9160 SiP on the nRF9160DK development kit?[/quote]

Yes, the "nRF Current Measurement" header will only give you the current drawn by the nRF9160. The GPIO pins are powered through a sepparate source.

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Tue, 05 Apr 2022 18:21:04 GMT

Hello Didrik,

On 2022-04-05 Didrik asked: What DK version do you have?

A white rectangular sticker on the non-component side of my nRF9160DK reads:

PCA10090

1.0.0

2021.11

960048580

Contains FCC ID: xxxxx . . .

Contains IC: 24529-NRF9160

Just downloaded and unzipped your latest, number four nRF9160 low power sample app, "blinky_low_power.zip". I tried to compile again with `west build -b nrf9160dk_nrf9160ns` and again have that cyclic build error where cmake cannot get past what looks to be Kconfig processing.

All the same, I'd actually gotten the same blinky app code merged in with my prior modified version of the very first intended low power sample you sent / shared in this Devzone post. So my "doubting Thomas" streak is sated that I am indeed able to modify the low power app -- something I cannot see at any terminal with UART and high speed clocks suspended -- and I can now share back with you the code which builds on my host and runs on my hardware.

Question - with PPK II connected to "nRF Current Measurement" jumper, is it true that I am measuring the current consumed only and only by the nRF9160 SiP on the nRF9160DK development kit?

I thought I had seen mention of this point in an earlier reply of yours, Didrik, but I could not find it reviewing all our exchanges in this Devzone ticket.

Thank you and will keep you posted on progress I make with 9160DK current measurements on my side.

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Tue, 05 Apr 2022 13:29:43 GMT

[quote user="tedhavelka"]

Question 1 - Curious, each of your 'hello_world' examples compiles for you with only the prj.conf symbols I find in the zipped archives, correct? Last night's exercise to revisit and combine elements of two of the example zips you sent provides a good lesson. But if the zips compile for you, is it that you are building in VSCode, and VSCode holds some project settings outside of your shared, zipped sources?

Question 2 - does your hello_world `west` manifest file pull in any different set of ncs or third party git repositories, with respect to the west.yml file I posted here a day or two ago?

[/quote]

I use the Toolchain Manager to manager my NCS installations, and don't keep a sepparate West workspace for each application. So, when I open a terminal through the Toolchain Manager, it will create an environment where West/CMake finds the right version of the toolchain, etc. Perhaps the most important effect for this conversation is that it sets ZEPHYR_BASE to point to my NCS 1.6.0 installation (there shouldn't be any . Similarly, I have configured VS Code to use my 1.6.0 installation (you can see the settings in the .vscode folder).

But there shouldn't be any "magic" happening. As long as West finds your 1.6.0 installation, I would have expected it to work.

[quote user="tedhavelka"]Question 3 - I have our nRF9160DK board connect to PPK II as shown in measuring current in Ampere Meter mode. My first current measurements are around 46 nano-amperes, which seems too low to be real. In particular, I kept the `while (1) { printk(...); k_msleep(1000); } code block in main() routine, expecting to see a current spike at about one Hertz. I don't see that. Is a standard USB-C cable from computer providing 5VDC to the development board?[/quote]

It might be that the printk is turned into a no-op when the console is disabled (which it will be because we disabled it's only backend). But I agree that 46 nA is a bit too good. What DK version do you have?

If your DK didn't come with a jumper on the "nRF current meassurement" header, you need to cut a solder bridge connecting the two pins: https://infocenter.nordicsemi.com/topic/ug_nrf91_dk/UG/nrf91_DK/prepare_board.html

[quote user="tedhavelka"]Ah wait, I may need to strike my last question. With UARTs and high speed clocks turned off I will not see any "hello world" message, correct? As a sanity check then that firmware is actually running, I would want some alternate heartbeat test such as flashing an LED?[/quote]

Yes, without the UART, you will not see messages over UART 🙂

I'll try to be optimistic and provide another sample project. This time the blinky sample, with the same changes as I made to the hello_world sample. When I meassure it on my 1.0.0 DK with a PPK2 in source meter mode, I get a total average of ~3.8 uA, and ~2.7 uA in the idle periods.

The compiled .hex file is included as well.

devzone.nordicsemi.com/.../blinky_5F00_low_5F00_power.zip

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 31 Mar 2022 22:28:14 GMT

Hello Didrik,

When you hear back findings on the Linux / Ubuntu command line based build, please let me know. I am actually not using VSCode. So far `west` and the other `west` orchestrated command line tools are working well for me. Past experience with integrated development environments has been useful on some points, but always more difficult in terms of understanding compile time settings. IDEs nearly always seem to hide configuration settings of project `make` and more recently cmake files.

Thank you also for including `merged.hex` in the example app archives. Failing to reach a successful build outcome I could still test the specific board for which those pre-compiled binaries are built.

Regarding the enumerated changes in your reply, yes, I more or less learned those through some trial and error and searching the hello_world / ncs workspace' Kconfig settings. I am finding `west build -t menuconfig` to be helpful and educational, though I don't know that I will move much beyond scratching the surface of this programming realm.

Question 2 - does your hello_world `west` manifest file pull in any different set of ncs or third party git repositories, with respect to the west.yml file I posted here a day or two ago?

Question 3 - I have our nRF9160DK board connect to PPK II as shown in measuring current in Ampere Meter mode. My first current measurements are around 46 nano-amperes, which seems too low to be real. In particular, I kept the `while (1) { printk(...); k_msleep(1000); } code block in main() routine, expecting to see a current spike at about one Hertz. I don't see that. Is a standard USB-C cable from computer providing 5VDC to the development board?

When I flash and run the hello_world app, I see the following Zephyr start up messages arrive over the board-powering USB-C cable:

*** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
Flash regions           Domain          Permissions
00 01 0x00000 0x10000   Secure          rwxl
02 31 0x10000 0x100000  Non-Secure      rwxl

Non-secure callable region 0 placed in flash region 1 with size 32.

SRAM region             Domain          Permissions
00 07 0x00000 0x10000   Secure          rwxl
08 31 0x10000 0x40000   Non-Secure      rwxl

Peripheral              Domain          Status
00 NRF_P0               Non-Secure      OK
01 NRF_CLOCK            Non-Secure      OK
02 NRF_RTC0             Non-Secure      OK
03 NRF_RTC1             Non-Secure      OK
04 NRF_NVMC             Non-Secure      OK
05 NRF_UARTE1           Non-Secure      OK
06 NRF_UARTE2           Secure          SKIP
07 NRF_TWIM2            Non-Secure      OK
08 NRF_SPIM3            Non-Secure      OK
09 NRF_TIMER0           Non-Secure      OK
10 NRF_TIMER1           Non-Secure      OK
11 NRF_TIMER2           Non-Secure      OK
12 NRF_SAADC            Non-Secure      OK
13 NRF_PWM0             Non-Secure      OK
14 NRF_PWM1             Non-Secure      OK
15 NRF_PWM2             Non-Secure      OK
16 NRF_PWM3             Non-Secure      OK
17 NRF_WDT              Non-Secure      OK
18 NRF_IPC              Non-Secure      OK
19 NRF_VMC              Non-Secure      OK
20 NRF_FPU              Non-Secure      OK
21 NRF_EGU1             Non-Secure      OK
22 NRF_EGU2             Non-Secure      OK
23 NRF_DPPIC            Non-Secure      OK
24 NRF_REGULATORS       Non-Secure      OK
25 NRF_PDM              Non-Secure      OK
26 NRF_I2S              Non-Secure      OK
27 NRF_GPIOTE1          Non-Secure      OK

SPM: NS image at 0x10000
SPM: NS MSP at 0x200179e8
SPM: NS reset vector at 0x124dd
SPM: prepare to jump to Non-Secure image.

But I never see the "hello world" or "printk" messages themselves. Am I correct that I should see these messages?

When the 9160 DK is powered, the Linux station enumerates three /dev/ttyACMx devices: ttyACM0, ttyACM1, ttyACM2. I see no terminal messages on ACM1 nor ACM2.

My terminal program is configured for no hardware flow control, no software flow control, and baud of 115200. I ought to see at least the starting "hello world" message, yes?

Ah wait, I may need to strike my last question. With UARTs and high speed clocks turned off I will not see any "hello world" message, correct? As a sanity check then that firmware is actually running, I would want some alternate heartbeat test such as flashing an LED?

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Thu, 31 Mar 2022 15:31:28 GMT

I have not seen this kind of loop before. I have also given the hello_world_low_pwer .zip to a colleague of mine with a Linux computer, and for him the project builds just fine.

However, he did tell me that he have seen such loops when a project has been moved from one location to another. So you could try to delete the build folder and the .vscode folder and see if that helps.

However, in the low power projects, and the current meassurement blogpost, there should be compiled versions of the programs as well. So you should be able to use them to meassure the current consumption even though you can't build the projects.

Or, you could create your own project by applying the same changes:

1. Enable CONFIG_NRF_MODEM_LIB (which also requires CONFIG_NETWORKING, CONFIG_NET_SOCKETS and CONFIG_HEAP_MEM_POOL_SIZE)

2. Disable CONFIG_SERIAL in both the application and in any child images (CONFIG_NRF_MODEM_LIB requires that you build the application for the non-secure domain, so you need the SPM to start your application). If you do not, you risk the child image starting the UART, and the application not turning it off.

3. Ensure that the application doesn't do anything, so that the idle thread puts the device to sleep.

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 31 Mar 2022 05:58:46 GMT

Hi again Didrik,

Working with the first hello_world sample app you sent, I am now able to build and flash that example with `CONFIG_NRF_MODEM_LIB=y` added to this app's prj.conf file. There were a few build time errors to resolve. These were all resolvable with a few additions to prj.conf:

Code excerpt - amended prj.conf file to build first version low power hello_world app:

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n

CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n

CONFIG_SERIAL=n

# 2022-03-30 WED - Ted adding config from latest, third hello_world zip de Didrik:
CONFIG_NRF_MODEM_LIB=y

# Network - need following networking facilities for cmake to find 'sockets_internal.h':
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS=y

# Modem library - may or may not need modem lib sys init, but present in aws_iot sample app:
##CONFIG_NRF_MODEM_LIB=y
CONFIG_NRF_MODEM_LIB_SYS_INIT=n

# 2022-03-30 need following kernel features to make k_malloc() defined to 'ncs/nrf/lib/nrf_modem_lib/nrf91_sockets.c':
CONFIG_KERNEL_MEM_POOL=y
CONFIG_HEAP_MEM_POOL_SIZE=2048

I am reviewing proper Power Profiler Kit connections now, preparing to measure current draw. Also I note here that I have not yet added the child_image/spm.conf to this earliest shared hello_world app.

Also noting that no amendments were needed in CMakeLists.txt. Expressing the three or so Kconfig symbols in prj.conf is sufficient to inform cmake where to locate certain header files and kernel level functions.

Will update you on current use findings when I have them - Ted

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 31 Mar 2022 04:45:41 GMT

Hi again Didrik,

As I attempt to amend the first hello_world project you posted in this thread, I find that adding to prj.conf the symbol setting `CONFIG_NRF_MODEM_LIB=y` causes for me the build error:

Excerpt - cmake build time snippet:

$ west build -b nrf9160dk_nrf9160ns
[0/14] Performing build step for 'spm_subimage'
ninja: no work to do. 
[2/12] Building C object modules/nrf/lib/nrf_modem_lib/CMakeFiles/..__nrf__lib__nrf_modem_lib.dir/nrf91_sockets.c.obj
FAILED: modules/nrf/lib/nrf_modem_lib/CMakeFiles/..__nrf__lib__nrf_modem_lib.dir/nrf91_sockets.c.obj 
ccache /opt/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -DBUILD_VERSION=v2.6.0-rc1-ncs1 -DEXT_API_MAGIC=0x281ee6de,0xb845acea,23298 -DFIRMWARE_INFO_MAGIC=0x281ee6de,0x8fcebb4c,23298 -DKERNEL -DNRF9160_XXAA -DNRF_TRUSTZONE_NONSECURE -DUSE_PARTITION_MANAGER=1 -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/ted/projects/zephyr-based/zephyr/include -I/home/ted/projects/zephyr-based/hello-world-0311/build/zephyr/include/generated -I/home/ted/projects/zephyr-based/zephyr/soc/arm/nordic_nrf/nrf91 -I/home/ted/projects/zephyr-based/nrf/include -I/home/ted/projects/zephyr-based/modules/hal/cmsis/CMSIS/Core/Include -I/home/ted/projects/zephyr-based/modules/hal/nordic/nrfx -I/home/ted/projects/zephyr-based/modules/hal/nordic/nrfx/drivers/include -I/home/ted/projects/zephyr-based/modules/hal/nordic/nrfx/mdk -I/home/ted/projects/zephyr-based/zephyr/modules/hal_nordic/nrfx/. -I/home/ted/projects/zephyr-based/modules/debug/segger/SEGGER -I/home/ted/projects/zephyr-based/modules/debug/segger/Config -I/home/ted/projects/zephyr-based/zephyr/modules/segger/. -I/home/ted/projects/zephyr-based/nrfxlib/nrf_modem/include -isystem /home/ted/projects/zephyr-based/zephyr/lib/libc/minimal/include -isystem /opt/gcc-arm-none-eabi-10.3-2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/include -isystem /opt/gcc-arm-none-eabi-10.3-2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/include-fixed -Os -imacros /home/ted/projects/zephyr-based/hello-world-0311/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -imacros /home/ted/projects/zephyr-based/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/ted/projects/zephyr-based/hello-world-0311=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/ted/projects/zephyr-based/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/ted/projects/zephyr-based=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT modules/nrf/lib/nrf_modem_lib/CMakeFiles/..__nrf__lib__nrf_modem_lib.dir/nrf91_sockets.c.obj -MF modules/nrf/lib/nrf_modem_lib/CMakeFiles/..__nrf__lib__nrf_modem_lib.dir/nrf91_sockets.c.obj.d -o modules/nrf/lib/nrf_modem_lib/CMakeFiles/..__nrf__lib__nrf_modem_lib.dir/nrf91_sockets.c.obj -c /home/ted/projects/zephyr-based/nrf/lib/nrf_modem_lib/nrf91_sockets.c
/home/ted/projects/zephyr-based/nrf/lib/nrf_modem_lib/nrf91_sockets.c:21:10: fatal error: sockets_internal.h: No such file or directory
   21 | #include <sockets_internal.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

When I change working directory from hello_world up to ../zephyr and search for this header file, I find it located in `subsys/net/lib/sockets`. So from my ncs top level dir the path and file are `ncs/zephyr/subsys/net/lib/sockets/sockets_internal.h`.

I have attempted to add this path to hello_world's build with a stanza in CMakeLists.txt, a line of the form:

include_directories($ENV{ZEPHYR_BASE}/subsys/net/lib/sockets)

As well I have tried some related paths with fewer path elements. None of these has solved the missing header file error, nor had any visible impact on the -I options reported during build, and visible as part of line 4 in the build snippet above.

Question 1 - have you a west.yaml file for your latest hello_world_low_power project, which you can share?

Question 2 - are there one or more other Kconfig symbols, e.g. CONFIG_NETWORKING which I may need to enable?

My effort here is to build the hello_world sample app, with nRF Modem lib enabled but not explicitly called by the sample, so that I can confirm our nRF9160DK kit can draw as little as 3 microamps. I'm presently copying my own west.yml file. This manifest file works for ncs v1.6.1 sample apps and a couple ncs based projects of my own. I am however unsure if my west.yml sets up the same libraries as you have when you build and run your hello_world app versions.

Attempting to build and prove your project draws 3uA, so I may adopt its key configurations to my team's work and achieve the same result there. Will continue researches here to overcome these build time errors.

- Ted

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Wed, 30 Mar 2022 22:04:50 GMT

Hello Didrik,

Reporting now findings with the latest low power hello_world code you send. The project zipped in file hello_world_low_power.zip results for me in the same erroneous, cyclic 'endless loop' cmake build behavior which I described first time a couple of days ago. I have unzipped and attempted to build this project four times, in two different ways, on two different Ubuntu 20.04 based work stations.

My first try was to unzip hello_world_low_power in an extent ncs v1.6.1 workspace. I've often called this my 'west workspace'. The yaml file which directs `west` how to populate this workspace is:

manifest:
  remotes:
    - name: nrfconnect
      url-base: https://github.com/nrfconnect
  projects:
    - name: nrf
      repo-path: sdk-nrf
      remote: nrfconnect
      revision: v1.6.1
      import: true 
  self:
    # This repository should be cloned to 
    path: aws-iot-stand-alone

The projects you zipped and have shared with me do not have any manifest file, so I assumed they would build against ncs v1.6.1. I find no reference in these modified hello_world projects to any particular ncs version. You mention however that 1462.hello_world.zip unintentionally was or is built against ncs version 1.9.1. I think that's today's latest stable ncs. v1.9.1 is definitely a newer release than the nrf-connect SDK code I am presently using.

The second way I attempt my builds is to create a fresh ncs folder, add my west.yml file there, and run `west init -l hello_world_low_power` in the ncs folder, and then cd into the hello_world_low_power project folder and `west update` there. There's no obvious reason I can see this would make a difference, but I wanted to be sure I wasn't gumming up any works by re-using my existing ncs workspace. ( I have successfully used the same ncs workspace for multiple projects, taking care to know that each one depends on the same ncs and third party git repos. )

The two work hosts on which I'm developing have mostly identical toolchain elements. I am likely missing some key elements of toolchain description but here are the primary tools I use and think about in my nRF9160 Zephyr application based work:

Excerpt 1 - host 2 toolchain, Nordic Semi + Zephyr + arm-none-eabi-gcc:

ted@dev-host-2:~/projects/zephyr-based$ west --version
West version: v0.12.0

ted@dev-host-2:~/projects/zephyr-based$ cmake --version
cmake version 3.23.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).
ted@dev-host-2:~/projects/zephyr-based$ dtc --version
Version: DTC 1.5.0

ted@dev-host-2:/opt/gcc-arm-none-eabi-10.3-2021.10/bin$ ./arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Excerpt 2 - host 1 toolchain, Nordic Semi ncs 1.6.1 + Zephyr + crosstool-NG compiler:

Ubuntu 20.04 LTS - Dell tower FG

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work$ west --version
West version: v0.11.0

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work$ cmake --version
cmake version 3.21.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work$ dtc --version
Version: DTC 1.5.0

ted@localhost:/opt/zephyr-sdk-0.13.0/arm-zephyr-eabi/bin$ ./arm-zephyr-eabi-gcc --version
arm-zephyr-eabi-gcc (crosstool-NG 1.24.0.378_e011758) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The first hello_world.zip project, which lacked the setting of symbol `CONFIG_NRF_MODEM_LIB=y` prj.conf, and also did not include a child_image subdirectory builds and runs on both hosts. I can build this sample app simply unzipping it within my existing ncs west workspace. The two later low power hello_world apps fail to build, but without producing any cmake or other error messages. To recap the build time failure is that cmake or a subordinate tool in the build process keeps cycling back to the start of project processing.

Do you have any suggestion where further I can look in cmake's output to determine what's misguiding the build process? This 'cmake endless loop' error so far is specific to the two latest modified projects you share in this Devzone thread. The error travels with the projects from one host to a second, with a similar but not identical build environment. This leads me to believe there is some edge case error somewhere in the project. I will however keep in mind that I may have set up my tools with an edge case fault on each of my favored workstations.

What I can and will do at this point is return to the working hello_word app, and manually add the prj.conf NRF_MODEM_LIB symbol, try building, and then manually add the child_image folder and Kconfig modifier file for Secure Partition Manager project there. Those are the two key changes I see you make in the second hello_world and later.

Kindly inform me and our audience if there are additional toolchain details I should include, to decipher from where this endless loop build arises.

Thanks again Didrik, and stay safe . . .

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Wed, 30 Mar 2022 13:24:30 GMT

[quote user="tedhavelka"]I am very interested to run your modified hello_world app on our nRF9160DK development board. More than curious to see whether we measure a similar 3uA with this application. But can you see any clue in above build process output which explains why `cmake` keeps repeating the first build steps?[/quote]

That is very weird. However, looking at the project again, I see that I made it for NCS v1.9.1, not 1.6.1 which was my intention.

Here is another version which hopefully works better: devzone.nordicsemi.com/.../hello_5F00_world_5F00_low_5F00_power.zip

Note that you must build it for nrf9160dk_nrf9160ns, as it enables the modem_lib.

But in general, the changes are only disabling SERIAL, in both the SPM and the application, and enabling the modem_lib to stop the modem from consuming power unnecessary.

[quote user="tedhavelka"]Again thank you for all your help on this extended, multi-part question and issue![/quote]

No problem. I am happy to be of help.

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Mon, 28 Mar 2022 20:03:30 GMT

Hi Didrik,

Thank you for the modified "hello_world" project. For some reason I not able to compile this Nordic + Zephyr based application. I am still using ncs SDK 1.6.1. My various compiler tools are recent enough to pass the early tool version checks. But I have never before seen the cyclic behavior I'm now getting as the build process parses all Kconfig dependencies. About every sixty six lines of build output the compiling appears to repeat itself. I have never seen this kind of erroneous behavior in a `west` based build:

ted@vibratsiya:~/projects/ncs/hello-world-1462$ west build -b nrf9160dk_nrf9160
-- west build: generating a build system
Including boilerplate (Zephyr base): /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake:37 (cmake_policy):
  The OLD behavior for policy CMP0079 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Application: /home/ted/projects/ncs/hello-world-1462
-- Zephyr version: 2.6.0-rc1 (/home/ted/projects/ncs/zephyr), build: v2.6.0-rc1-ncs1
-- Found Python3: /usr/bin/python3.8 (found suitable exact version "3.8.10") found components: Interpreter 
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf9160dk_nrf9160, Revision: 0.7.0
-- Cache files will be written to: /home/ted/.cache/zephyr
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-10.3-2021.10)
-- Found BOARD.dts: /home/ted/projects/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts
-- Generated zephyr.dts: /home/ted/projects/ncs/hello-world-1462/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/device_extern.h
Parsing /home/ted/projects/ncs/zephyr/Kconfig
Loaded configuration '/home/ted/projects/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_defconfig'
Merged configuration '/home/ted/projects/ncs/hello-world-1462/prj.conf'
Configuration saved to '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
Kconfig header saved to '/home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/autoconf.h'

warning: UART_CONSOLE (defined at drivers/console/Kconfig:47) was assigned the value 'y' but got the
value 'n'. Check these unsatisfied dependencies: SERIAL (=n), SERIAL_HAS_DRIVER (=n). See
http://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_CONSOLE.html and/or look up
UART_CONSOLE in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

-- The C compiler identification is GNU 10.3.1
-- The CXX compiler identification is GNU 10.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /opt/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc
CMake Deprecation Warning at /home/ted/projects/ncs/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Configuring done
CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1198 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1253 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /home/ted/projects/ncs/hello-world-1462/build
-- west build: building application
[0/1] Re-running CMake...
Including boilerplate (Zephyr base (cached)): /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake:37 (cmake_policy):
  The OLD behavior for policy CMP0079 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Application: /home/ted/projects/ncs/hello-world-1462
-- Zephyr version: 2.6.0-rc1 (/home/ted/projects/ncs/zephyr), build: v2.6.0-rc1-ncs1
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf9160dk_nrf9160, Revision: 0.7.0
-- Cache files will be written to: /home/ted/.cache/zephyr
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-10.3-2021.10)
-- Found BOARD.dts: /home/ted/projects/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts
-- Generated zephyr.dts: /home/ted/projects/ncs/hello-world-1462/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/device_extern.h
Parsing /home/ted/projects/ncs/zephyr/Kconfig
Loaded configuration '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
No change to configuration in '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
No change to Kconfig header in '/home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/autoconf.h'
CMake Deprecation Warning at /home/ted/projects/zephyr-based-2/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Configuring done
CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1198 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1253 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /home/ted/projects/ncs/hello-world-1462/build
[0/1] Re-running CMake...
Including boilerplate (Zephyr base (cached)): /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake:37 (cmake_policy):
  The OLD behavior for policy CMP0079 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Application: /home/ted/projects/ncs/hello-world-1462
-- Zephyr version: 2.6.0-rc1 (/home/ted/projects/ncs/zephyr), build: v2.6.0-rc1-ncs1
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf9160dk_nrf9160, Revision: 0.7.0
-- Cache files will be written to: /home/ted/.cache/zephyr
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-10.3-2021.10)
-- Found BOARD.dts: /home/ted/projects/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts
-- Generated zephyr.dts: /home/ted/projects/ncs/hello-world-1462/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/device_extern.h
Parsing /home/ted/projects/ncs/zephyr/Kconfig
Loaded configuration '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
No change to configuration in '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
No change to Kconfig header in '/home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/autoconf.h'
CMake Deprecation Warning at /home/ted/projects/zephyr-based-2/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Configuring done
CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1198 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1253 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /home/ted/projects/ncs/hello-world-1462/build
[0/1] Re-running CMake...
Including boilerplate (Zephyr base (cached)): /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake:37 (cmake_policy):
  The OLD behavior for policy CMP0079 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Application: /home/ted/projects/ncs/hello-world-1462
-- Zephyr version: 2.6.0-rc1 (/home/ted/projects/ncs/zephyr), build: v2.6.0-rc1-ncs1
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf9160dk_nrf9160, Revision: 0.7.0
-- Cache files will be written to: /home/ted/.cache/zephyr
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-10.3-2021.10)
-- Found BOARD.dts: /home/ted/projects/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts
-- Generated zephyr.dts: /home/ted/projects/ncs/hello-world-1462/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/device_extern.h
Parsing /home/ted/projects/ncs/zephyr/Kconfig
Loaded configuration '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
No change to configuration in '/home/ted/projects/ncs/hello-world-1462/build/zephyr/.config'
No change to Kconfig header in '/home/ted/projects/ncs/hello-world-1462/build/zephyr/include/generated/autoconf.h'
CMake Deprecation Warning at /home/ted/projects/zephyr-based-2/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Configuring done
CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1198 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /home/ted/projects/ncs/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/CMakeLists.txt:1253 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /home/ted/projects/ncs/hello-world-1462/build
[0/1] Re-running CMake...
Including boilerplate (Zephyr base (cached)): /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake
CMake Deprecation Warning at /home/ted/projects/ncs/zephyr/cmake/app/boilerplate.cmake:37 (cmake_policy):
  The OLD behavior for policy CMP0079 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  /home/ted/projects/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Application: /home/ted/projects/ncs/hello-world-1462
-- Zephyr version: 2.6.0-rc1 (/home/ted/projects/ncs/zephyr), build: v2.6.0-rc1-ncs1
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf9160dk_nrf9160, Revision: 0.7.0
-- Cache files will be written to: /home/ted/.cache/zephyr
-- Found dtc: /usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/gcc-arm-none-eabi-10.3-2021.10)
-- Found BOARD.dts: /home/ted/projects/ncs/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160.dts
^Cninja: error: rebuilding 'build.ninja': interrupted by user

One thing I notice is that `cmake` never seems to progress beyond the zero'th of one steps:

Dropping partition 'nrf_modem_lib_trace' since its size is 0.
-- Configuring done
CMake Warning (dev) at /home/ted/projects/zephyr-based/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/zephyr-based/zephyr/CMakeLists.txt:1198 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /home/ted/projects/zephyr-based/zephyr/cmake/linker/ld/target.cmake:33 (add_custom_command):
  Policy CMP0116 is not set: Ninja generators transform DEPFILEs from
  add_custom_command().  Run "cmake --help-policy CMP0116" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.
Call Stack (most recent call first):
  /home/ted/projects/zephyr-based/zephyr/CMakeLists.txt:1253 (configure_linker_script)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /home/ted/projects/zephyr-based/hello-world-1462-de-didrik/build
-- west build: building application
[0/1] Re-running CMake...

There are these triplet statements:

- Configuring done

. . .

- Generating done

[0/1] Re-running cmake...

I am very interested to run your modified hello_world app on our nRF9160DK development board. More than curious to see whether we measure a similar 3uA with this application. But can you see any clue in above build process output which explains why `cmake` keeps repeating the first build steps?

The first hello_world sample app you sent on 2022-03-11 builds and runs. I will review prj.conf and related diffs between the two hello_world versions you prepared and shared with me. Perhaps I can adapt the first one with the SPM child image and other diffs. There should be only one or a few differences between the two code samples.

Again thank you for all your help on this extended, multi-part question and issue!

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Mon, 28 Mar 2022 12:15:42 GMT

I've attached a hello_world example modified for low-power.

[quote user="tedhavelka"]This apparently due to a bug that affect mRF9160 current draw when the Nordic library API function nrf_modem_lib_dfu_handler() is not called.[/quote]

Note that you don't actually have to call any functions. Having the library enabled is enough.

Other than enabling the modem lib, the only other change I did was to disable UART (both in the application and the SPM).

devzone.nordicsemi.com/.../1462.hello_5F00_world.zip

With my DK and PPK, I got an average current draw of ~3uA.

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 24 Mar 2022 21:34:41 GMT

Hello Didrik,

I've disabled AT_HOST_LIBRARY, recompiled and flashed my modified aws_iot based app. The unnamed thread is now gone from Zephyr's reporting of threads. But in the lowest power mode I can achieve I still see the roughly 30Hz current spikes, some of the spikes to 4 mA and about fifty percent -- at random -- to 0.5 mA for an average of 85 microamps.

Disabling AT_HOST_LIBRARY makes no impact on lowest 9160 current draw I can achieve. I see that same as yet mysterious current spiking waveform in Nordic's Power Profiler v3.4.3.

At this point, if the threads are all sleeping, I don't know in what source file or which routines to set breakpoints in gdb, to catch the code that seems to be running. I've already turned off the two digital sensors on our custom board, and all other hardware pieces are analog, and from what I can tell are not able to produce a periodic or digital signal. That is, those parts are unlikely to draw current in the pulsed way shown in the latest waveform capture I posted a few days ago.

While I understand that Nordic Semi's aws_iot sample application is not designed to showcase the lowest power consumption of nRF9160, I am now concerned about being able to reach current draw in the ones of microamps. I've spent many days now investigating, testing code change, trouble-shooting hardawre and firmware and have not been able to get lower than ~65 microamps average current draw in our 9160 design. This low spec'd deep sleep current consumption is a design requirement for my team, and is one of the primary bases on which we chose the nRF9160 for a new product design.

The "hello_world" sample which you shared in an earlier post to this thread draws more current, between 2 and 3 mA. This apparently due to a bug that affect mRF9160 current draw when the Nordic library API function nrf_modem_lib_dfu_handler() is not called.

Forgive me if I repeat a question, but what would be a good fresh starting point for me to explore and test code that puts the nRF9160 in it's full deep sleep mode? I am about to revisit your hello_world project, enable nrf_modem_lib_dfu_handler() there if I can, and see what current draw occurs.

- Ted

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 24 Mar 2022 18:25:33 GMT

Hi Didrik,

Regarding ZephyrRTOS_Plugin.so, I actually found that shared object file in the very path you share. So I am good there, and presently I am running JLinkGDBServer version 7.60. This version of a gdb server however does not appear to have thread awareness. When at the gdb prompt, of a session connected to my running Zephyr 2.6.0 based app, I issue the command `thread apply all bt` I do not see the six threads that gdb should detect and which Zephyr is actually running, or has queued, and reports itself.

According to Zephyr 2.6.0 release notes Segger's JLinkGDBServer version 7.11. 7.20 and newer support thread awareness. Again I'm using Segger's gdb server version 7.60. In my app's prj.conf I enable:

205 # 2021-11-11 - Zephyr thread analyzer work:
206 CONFIG_THREAD_ANALYZER=y
207 CONFIG_THREAD_ANALYZER_USE_PRINTK=y
208 CONFIG_THREAD_ANALYZER_AUTO=n
209 CONFIG_THREAD_NAME=y
  . . .
215 CONFIG_DEBUG_THREAD_INFO=y
216 CONFIG_THREAD_STACK_INFO=y

and yet I'm not able to access threads in my gdb debugging sessions. Is there some further Kconfig symbol I have missed to enable thread aware debugging?

Regarding to disable Nordic's AT host code, I am about to attempt this. Your suggestion involves setting a Kconfig symbol to 'n' or no. In doing this I will disable Nordic modem code at compile time, but I have been using at_cmd_write() at run time to issue configuring commands such as AT+CPSMS to the LTE modem. I'll lose this configurability by making the Kconfig change you describe. Even if this works to bring current lower or to the lowest nRF9160 current consumption specification I will most likely need a means to disable the AT host code dynamically, so I can use it at start up time and brief wake periods, then turn it off for longer deep sleep periods.

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Thu, 24 Mar 2022 12:06:40 GMT

[quote user="tedhavelka"]As for the above mentioned `RTOSPlugin_Zephyr.dll` this looks like a Windows targeted library file. I'm not sure I can install and run that as part of a Linux application.[/quote]

Yes, the .dll is for Windows, but there is an equivalent file for Linux. On one of my colleagues' computer, who uses Linux, it's in /opt/SEGGER/JLink/GDBServer/RTOSPlugin_Zephyr.so.

[quote user="tedhavelka"]What is most interesting to me is gdb's identifying remark that we are looking at function `at_host_work_q`.[/quote]

That makes sense. The at_host library (which reads AT commands from the UART, and forwards them to the modem) uses its own workqueue, which in turn has its own thread. When enabled, the library starts up before the application reaches main(), and runs in the background, which explains why we have not found it earlier.

As you don't use UART, removing the AT host shouldn't be an issue: CONFIG_AT_HOST_LIBRARY=n.

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Thu, 24 Mar 2022 00:04:24 GMT

Hello Didrik,

Thank you for the link to the VSCode configuration and use tutorial video series. I am following these videos to understand and confirm my Ubuntu based installation of VSCode. As for the above mentioned `RTOSPlugin_Zephyr.dll` this looks like a Windows targeted library file. I'm not sure I can install and run that as part of a Linux application.

So I am also studying a Memfault gdb tutorial and have come across something I hope is the start of a path to the mystery, 25Hz periodic running code in my Zephyr based, aws_iot based application. I've reduced my main() function to starting just three things: (1) cJSON library initialization, (2) nrf_modem_lib_dfu_handler(), and (3) custom command line interface (CLI) thread. Just after these three start calls, I call Zephyr's API to print Zephyr threads and see:

   1) 'at_cmd_socket_thread'     stack size 1472 bytes, stack used 432 bytes, 29%
   2) 'thread_simple_cli'        stack size 4096 bytes, stack used 1768 bytes, 43%
   3) 'time_thread'              stack size 1024 bytes, stack used 240 bytes, 23%
   4) '0x20015458'               stack size 1024 bytes, stack used 168 bytes, 16%
   5) 'sysworkq'                 stack size 2048 bytes, stack used 168 bytes, 8%
   6) 'idle 00'

Note the persistent showing of the unnamed thread, now at 0x20015458. I expect the address here to change when I comment out larger blocks of my application code. In an attached gdb session I've run the command to show the disassembly which begins at this address:

(gdb) disassemble 0x20015458
Dump of assembler code for function at_host_work_q:
   0x20015458 <+0>:	strb	r0, [r6, r5]
   0x2001545a <+2>:	movs	r0, #1
   0x2001545c <+4>:	strb	r0, [r6, r5]
   0x2001545e <+6>:	movs	r0, #1
   0x20015460 <+8>:	strb	r0, [r6, r5]
   0x20015462 <+10>:	movs	r0, #1
   0x20015464 <+12>:	lsls	r0, r0, #8
   0x20015466 <+14>:	movs	r2, r1
   0x20015468 <+16>:	movs	r0, r0
   0x2001546a <+18>:	movs	r0, r0
   0x2001546c <+20>:	movs	r0, r0
   0x2001546e <+22>:	movs	r0, r0
   0x20015470 <+24>:	movs	r0, r0
   0x20015472 <+26>:	movs	r0, r0
   0x20015474 <+28>:	movs	r0, r0
   0x20015476 <+30>:	movs	r0, r0
   0x20015478 <+32>:	movs	r0, r0
   0x2001547a <+34>:	movs	r0, r0
   0x2001547c <+36>:	movs	r0, r0
   0x2001547e <+38>:	movs	r0, r0
   0x20015480 <+40>:	movs	r0, r0
   0x20015482 <+42>:	movs	r0, r0
   0x20015484 <+44>:	movs	r0, r0
   0x20015486 <+46>:	movs	r0, r0
   0x20015488 <+48>:	movs	r0, r0
   0x2001548a <+50>:	movs	r0, r0
   0x2001548c <+52>:	movs	r0, r0
   0x2001548e <+54>:	movs	r0, r0
   0x20015490 <+56>:			; <UNDEFINED> instruction: 0xffffffff
   0x20015494 <+60>:			; <UNDEFINED> instruction: 0xffffffff

The disassembly actually continues on, I've included only about twenty percent here. The last two lines are unknown instructions, so I'm not convinced that there is truly one hundred plus lines of assembly code for whatever thread or routine begins at address 0x20015458.

What is most interesting to me is gdb's identifying remark that we are looking at function `at_host_work_q`. I think a work queue is a zephyr construct. So while in this low power testing version of my app I have most aws_iot code disabled, could some code that's eventually set up at run time and or called by nrf_modem_lib_dfu_handler() be executing at a frequency of about 25 Hz?

In my own CLI thread I found that I obtained a good responsiveness to human typing by checking for character input twenty times a second. That is, I set my CLI thread's default sleep period to 50 milliseconds. The LTE modem AT command handler has some similar interactive features to my much simpler CLI, so is it possible that the AT command handler is still periodically looking for commands even while I have slept all other threads, and issued an AT+CPSMS= command to the modem?

I'll continue on with studies of the materials you have linked for me. I'll also search for AT handler source code in Nordic's ncs v1.6.1. I think that code is on hand here. Thank you again for your help thus far. Let me know whether the above gdb output gives any recognizable clue as to what code is keeping my application from entering the full deep sleep mode and lowest current draw of about 1.4 microamps.

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Wed, 23 Mar 2022 14:56:44 GMT

[quote user="tedhavelka"]In your recent response you mention that VSCode has a gdb plug-in, and would be configured to be thread-aware for Zephyr debugging support. I have VSCode now installed, but am not able to get gdb running nor showing a menu or button interface for detected threads. [/quote]

If you haven't seen it already, I would recommend this YouTube playlist on how to install and use VS Code with the nRF Connect SDK: https://www.youtube.com/playlist?list=PLx_tBuQ_KSqEt7NK-H7Lu78lT2OijwIMl

One of the videos is about debugging, but you might want to look through the other videos as well, to double check that you have set everything up correctly.

[quote user="tedhavelka"]

It looks like I must precede my debugging commands to gdb with the token `mon` -- short for monitor? -- in order to do things like halt the firmware and "go" or run again.

Question (1) can you recommend a good tutorial on the `mon` supported commands for ARM Cortex-M family parts?

[/quote]

It's been a while since I used GDB manually myself, but I don't think I used 'mon' for much more than 'mon reset' and 'mon halt'. I don't know about any good tutorials, but I found a list of the monitor commands supported by Segger: https://wiki.segger.com/J-Link_GDB_Server#Supported_remote_.28monitor.29_commands

For thread aware debugging to work, you must add a plugin that is able to read and parse the information about the threads. E.g. when I start debugging the philosophers sample in VS Code, this is how JLinkGDBServerCL is started:

Launching gdb-server: "C:\\Program Files (x86)\\SEGGER\\JLink\\JLinkGDBServerCL.exe" -singlerun -nogui -if swd -port 50000 -swoport 50001 -telnetport 50002 -device nRF9160_xxAA -select usb=960060612 -rtos "C:\\Program Files (x86)\\SEGGER\\JLink\\GDBServer\\RTOSPlugin_Zephyr.dll"

[quote user="tedhavelka"]The result I see from `blinky` is an average current draw around 3.0 mA, with a fair amount of noise.[/quote]

The 3mA current draw is a known issue: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/known_issues.html#other-issues

(Sorry, I should have remembered this).

The solution is to enable the modem library (CONFIG_NRF_MODEM_LIB=y).

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Tue, 22 Mar 2022 19:34:25 GMT

Hello Didrik,

I've reviewed my project's Kconfig symbols summary in the build artifacts directory, `ncs/myproject/build` and find that those two out-of-tree
Zephyr sensors libraries do not trigger any threads to be called:

ted@localhost$ grep -nr TRIGGER_OWN_THREAD ./*
\./build/zephyr/.config.old:1626:# CONFIG_IIS2DH_TRIGGER_OWN_THREAD is not set
./build/zephyr/.config.old:1639:# CONFIG_LIS2DH_TRIGGER_OWN_THREAD is not set
./build/zephyr/.config:1626:# CONFIG_IIS2DH_TRIGGER_OWN_THREAD is not set
./build/zephyr/.config:1639:# CONFIG_LIS2DH_TRIGGER_OWN_THREAD is not set

ted@localhost$

I read through this file as well to be sure, and to see what related symbols are defined or not defined in the few lines before, between and after these "trigger own thread" symbols. As I am not yet using hardware interrupt lines from the IIS2DH or other sensor I have not written any ISR for such hardware based interrupts for these sensors.

Regarding the known current draw .hex file in your current measurements guide current measurements guide, I have not tried running that specific .hex file. I tried something very similar by returning to Nordic's `ncs/nrf/samples/basic/blinky` Zephyr based app, building and running that on our custom board. The result I see from `blinky` is an average current draw around 3.0 mA, with a fair amount of noise. I have to make some adaptation to the blinky app in order to turn off some of our custom peripherals external to the nRF9160.

Interestingly I see a similar cerca 3.0 mA current draw from my own application, specifically when I disable not only my own threads but also the call to the aws_iot library routine named `nrf_modem_lib_dfu_handler()`. You may recall that my custom firmware is based partly on Nordic's aws_iot sample app. Only in these recent low power tests have I started to comment out calls to aws_iot library functions. When I comment out and no longer call `nrf_modem_lib_dfu_handler()` I lose the AT command parser for the LTE modem, and I appear to lose a bunch other control over the modem's behavior and power consumption.

So I am not sure whether the pre-built hex file in your guide would help show me whether our board can draw that minimal, deep sleep spec'd current of about 1.4uA.

In your recent response you mention that VSCode has a gdb plug-in, and would be configured to be thread-aware for Zephyr debugging support. I have VSCode now installed, but am not able to get gdb running nor showing a menu or button interface for detected threads. I've also invoked a gdb connection to our nRF9160 firmware at the command line with `west -v debug`. I can connect to the ARM Cortex-M33 at a Linux command line with this west invocation. It looks like I must precede my debugging commands to gdb with the token `mon` -- short for monitor? -- in order to do things like halt the firmware and "go" or run again.

Question (1) can you recommend a good tutorial on the `mon` supported commands for ARM Cortex-M family parts?

I've done some searching for about an hour, and have some basic gdb experience. Nonetheless I have not found any tutorial, how-to article or blog or forum posts which go into a practical working detail of how to interact with gdb at command line, and obtain a list of Zephyr registered threads. Seems like there is a large debugging tool set here, but no instructions or guide on how to get started and make good use of them.

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Tue, 22 Mar 2022 13:50:02 GMT

[quote user="tedhavelka"]To clarify my first question from above, can I be confident that I have correctly powered down all high frequency clocks in the 9160 SiP when I measure only 65 microamps to 85 microamps average current draw over a minute's time?[/quote]

Yes, they are not running. If they had been running the high frequency clocks would have drawn more current.

[quote user="tedhavelka"]I'll watch for further help on the question of the roughly 25Hz current use spike activity.[/quote]

I've talked with one of our current consumption experts, and he's ideas was that it could be either GPIOTE IN event (edge detection on a GPIO pin), or the UART ENABLE base current (with RX disabled).

Looking at the UART driver implementation, it looks like the driver disables the peripheral properly, so I don't think the current draw comes from there. However, the GPIO edge detection might have been set up by one of the sensor drivers you have included in your project.

Also, looking at the code of the drivers, it looks like both can create a thread, without giving it a name, if CONFIG_<sensor>_TRIGGER_OWN_THREAD is set. Is either of those two configs set in your project?

Also, did you meassure the current draw of the .hex file in the current meassurement blog post?

You can also use the blinky sample with CONFIG_SERIAL=n to verify your current meassurement setup. By running an application with a known current consumption on the nRF9160, we can see check if the extra current consumption comes from somewhere else on the board.

RE: To identify, adjust sleep period of sample app threads?

tedhavelka — Mon, 21 Mar 2022 17:27:18 GMT

Good morning Didrik,

Thank you for fast reply to my latest questions on nRF9160 current draw and PSM active and inactive periods. To clarify my first question from above, can I be confident that I have correctly powered down all high frequency clocks in the 9160 SiP when I measure only 65 microamps to 85 microamps average current draw over a minute's time?

I'll watch for further help on the question of the roughly 25Hz current use spike activity.

- Ted

RE: To identify, adjust sleep period of sample app threads?

Didrik Rokhaug — Mon, 21 Mar 2022 16:39:15 GMT

[quote user="tedhavelka"]Question (1): is an average current of ~85 microamps indicative of an nRF9180 SICA B1A running with all UARTs and high speed clocks off?[/quote]

Yes, if UART RX or HF clocks were running, you should see a power draw of >500uA.

[quote user="tedhavelka"]

Question (3) - When firmware enables PSM mode in the nRF9160 modem, is the "wake period + sleep period" entered immediately?

Question (4) - When the new PSM times are configured, does the PSM mode begin by keep the modem on for its active period, or does it begin by keeping the modem in power savings mode for its suspended, low power period? E.g. which part of the power cycle occurs first?

[/quote]

To send data, or communicate with the network, you need an RRC connection. How long you stay in RRC Connected mode depends on the network. After the RRC connection has been inactive for a while, the device is released from the RRC connection and enters RRC Idle mode. How long you stay here depends on the Active Time, and how often you must listen for incomming data depends on the eDRX settings. After the Active Time finishes, the device enters PSM and turn the radio completely off.

[quote user="tedhavelka"]Question (2) is there a clue in the current spikes, appearing at about 25Hz, and intermittently peaking at 4mA and alternately 0.5mA? Any part of SICA B1A hardware consume power in this way?[/quote]

I'll have to come back to you on this.