Problem executing simple program on Thingy91

RE: Problem executing simple program on Thingy91

Øyvind — Mon, 23 Jun 2025 07:57:16 GMT

Hello, sorry for the delayed answer.

I think looking at the Partition manager documentation and Building and configuring TF-M should provide some information on the misc. partitions, as most of this is handled in the build system and the partition manager script.

There is no good explanation on what does empty_0 mean in pm_static? But from our Nordic Semiconductor AI it states:

In the context of Nordic Semiconductor's nRF Connect SDK and Partition Manager, an EMPTY_0 partition in a pm_static.yml file (or in the generated partition map) represents an unallocated or unused region of flash memory. These "EMPTY" partitions are automatically created by the Partition Manager to fill gaps between other defined partitions, often due to alignment requirements or reserved space.

Key points about EMPTY_0:

It is a placeholder for unused flash space.

Its presence is often due to alignment constraints (e.g., partitions needing to start at specific boundaries).

You can rename EMPTY_0 to something more descriptive (like app_data) if you want to use that space for your own data storage.

If you want to ensure this region remains available and does not move due to future configuration changes, you should lock down your memory layout by using a static partition configuration (pm_static.yml) copied from your build's partitions.yml file.

The address and size of EMPTY_0 can be found programmatically using symbols defined in pm_config.h (included with #include <pm_config.h>).

For example, as explained by a Nordic engineer:

You can also change the 'EMPTY_0' name in your pm_static file to a more descriptive name, such as 'app_data'. The size and address of this partition can be found programmatically using the symbols defined in pm_config.h (included with #include <pm_config.h>)
Write user data to NVM

And from the official documentation:

There can only be one unoccupied gap per region.
Configuring static partitions

In summary, EMPTY_0 is simply a label for unused flash space, and you are free to repurpose it as needed in your application.

RE: Problem executing simple program on Thingy91

AdBee — Wed, 04 Jun 2025 15:06:54 GMT

I solved my problem by moving my "user_partition" to the "nonsecure_storage" sector. My partition now looks like this:

  flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x69000 - 420kB)-----+
+---0xc000: tfm_secure (0xc000 - 48kB)------------+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x68e00 - 419kB)-+
| 0xc200: tfm (0xbe00 - 47kB)                     |
+---0x18000: tfm_nonsecure (0x5b000 - 364kB)------+
| 0x18000: app (0x50000 - 320kB)                  |
| 0x68000: nvs_storage (0x6000 - 24kB)            |
| 0x75000: mcuboot_secondary (0x69000 - 420kB)    |
| 0xde000: EMPTY_0 (0x2000 - 8kB)                 |
+---0xe0000: nonsecure_storage (0x20000 - 128kB)--+
| 0xe0000: user_partition (0x1e000 - 120kB)       |
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  otp (0x2f4 - 756B): 
+------------------------------+
| 0xff8108: otp (0x2f4 - 756B) |
+------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------------+
+---0x20000000: mcuboot_sram (0x8000 - 32kB)-------+
+---0x20000000: sram_secure (0x8000 - 32kB)--------+
| 0x20000000: tfm_sram (0x8000 - 32kB)             |
+---0x20008000: sram_nonsecure (0x38000 - 224kB)---+
+---0x20008000: nrf_modem_lib_sram (0x4568 - 17kB)-+
| 0x20008000: nrf_modem_lib_ctrl (0x4e8 - 1kB)     |
| 0x200084e8: nrf_modem_lib_tx (0x2080 - 8kB)      |
| 0x2000a568: nrf_modem_lib_rx (0x2000 - 8kB)      |
+--------------------------------------------------+
| 0x2000c568: sram_primary (0x33a98 - 206kB)       |
+--------------------------------------------------+

I am still a bit confused about some partitions though, could you explain them to me ?

First I'd like to know why there is a "nvs_storage" partition which appeared in the tfm_nonsecure sector. I didn't explicitly requested this, and this is not the partition that is being mounted on my system (it is "user_partition" which works fine).

Secondly I'd like to know what the EMPTY_0 partition is for. This partition is set by default in the partitions.pm file so I kept it in my custom pm_static.yml file, but I'd like to why it's there.

Here is my pm_static.yml file:

app: {address: 0x18000, size: 0x5b000}
mcuboot:
  address: 0x0
  placement:
    before: [mcuboot_primary]
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  placement:
    align: {start: 0x1000}
    before: [mcuboot_primary_app]
  size: 0x200
mcuboot_primary:
  address: 0xc000
  size: 0x69000
  span: [tfm, mcuboot_pad, app]
mcuboot_primary_app:
  address: 0xc200
  size: 0x68e00
  span: [app, tfm]
mcuboot_secondary:
  address: 0x75000
  placement:
    after: [mcuboot_primary]
    align: {start: 0x1000}
  share_size: [mcuboot_primary]
  size: 0x69000
EMPTY_0:
  address: 0xde000
  size: 0x2000
user_partition:
  address: 0xe0000
  placement:
    after: [EMPTY_0]
    align: {start: 0x1000}
  size: 0x1e000
settings_storage:
  address: 0xfe000
  placement:
    after: [user_partition]
  size: 0x2000
nonsecure_storage:
  address: 0xe0000
  size: 0x20000
  span: [user_partition, settings_storage]
tfm_secure:
  address: 0xc000
  size: 0xc000
  span: [mcuboot_pad, tfm]
tfm_nonsecure:
  address: 0x18000
  size: 0x5b000
  span: [app]
tfm:
  address: 0xc200
  size: 0xbe00

mcuboot_sram:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id001
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id001
sram_secure:
  address: 0x20000000
  end_address: 0x20008000
  orig_span: &id004
  - tfm_sram
  region: sram_primary
  size: 0x8000
  span: *id004
tfm_sram:
  address: 0x20000000
  end_address: 0x20008000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x8000
sram_nonsecure:
  address: 0x20008000
  end_address: 0x20040000
  orig_span: &id003
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x38000
  span: *id003
nrf_modem_lib_sram:
  address: 0x20008000
  end_address: 0x2000c568
  orig_span: &id002
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x4568
  span: *id002
nrf_modem_lib_ctrl:
  address: 0x20008000
  end_address: 0x200084e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - tfm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_tx:
  address: 0x200084e8
  end_address: 0x2000a568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2080
nrf_modem_lib_rx:
  address: 0x2000a568
  end_address: 0x2000c568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
sram_primary:
  address: 0x2000c568
  end_address: 0x20040000
  region: sram_primary
  size: 0x33a98

Relevant prj.conf configurations:

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y

Thank you,

AdBee

RE: Problem executing simple program on Thingy91

AdBee — Wed, 04 Jun 2025 12:17:57 GMT

Hello,

Did you set CONFIG_THINGY91_STATIC_PARTITIONS_FACTORY=n along with CONFIG_THINGY91_NO_PREDEFINED_LAYOUT=y?

I didn't indeed. Doing this seems to have troubleshot the problem, thank you.

Running west build -t partition_manager_report gets me:

flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x69000 - 420kB)-----+
+---0xc000: tfm_secure (0xc000 - 48kB)------------+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x68e00 - 419kB)-+
| 0xc200: tfm (0xbe00 - 47kB)                     |
| 0x18000: app (0x5d000 - 372kB)                  |
+---0x18000: tfm_nonsecure (0x5b000 - 364kB)------+
| 0x75000: mcuboot_secondary (0x69000 - 420kB)    |
| 0xde000: user_partition (0x1e000 - 120kB)       |
| 0xfc000: EMPTY_0 (0x2000 - 8kB)                 |
+---0xfe000: nonsecure_storage (0x2000 - 8kB)-----+
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  otp (0x2f4 - 756B): 
+------------------------------+
| 0xff8108: otp (0x2f4 - 756B) |
+------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------------+
+---0x20000000: mcuboot_sram (0x8000 - 32kB)-------+
+---0x20000000: sram_secure (0x8000 - 32kB)--------+
| 0x20000000: tfm_sram (0x8000 - 32kB)             |
+---0x20008000: sram_nonsecure (0x38000 - 224kB)---+
+---0x20008000: nrf_modem_lib_sram (0x4568 - 17kB)-+
| 0x20008000: nrf_modem_lib_ctrl (0x4e8 - 1kB)     |
| 0x200084e8: nrf_modem_lib_tx (0x2080 - 8kB)      |
| 0x2000a568: nrf_modem_lib_rx (0x2000 - 8kB)      |
+--------------------------------------------------+
| 0x2000c568: sram_primary (0x33a98 - 206kB)       |
+--------------------------------------------------+

At heart, I took the default partitions and added a custom one for NVS that I called "user_partition". Since a scratch partition for MCUBOOT shouldn't be absolutely needed depending on the FOTA swap policy, I decided to remove it to make room for "user_partition".

I'm now getting this error at runtime when trying to mount the NVS partition:

[00:00:00.391,296] <err> os: ***** SECURE FAULT *****
[00:00:00.397,033] <err> os:   Address: 0xe0ff8
[00:00:00.402,313] <err> os:   Attribution unit violation
[00:00:00.408,477] <err> os: r0/a1:  0x20011518  r1/a2:  0x000e0ff8  r2/a3:  0x000e1000
[00:00:00.417,236] <err> os: r3/a4:  0x20011517 r12/ip:  0x0001cad5 r14/lr:  0x0001cb23
[00:00:00.425,994] <err> os:  xpsr:  0x81000000
[00:00:00.431,274] <err> os: Faulting instruction address (r15/pc): 0x0002de86
[00:00:00.439,239] <err> os: >>> ZEPHYR FATAL ERROR 41: Unknown error on CPU 0
[00:00:00.447,204] <err> os: Current thread: 0x2000d318 (unknown)
[00:00:00.454,040] <err> os: Halting system

which is pretty explicit about me violating the NS and/or trusted Firmware setup. Since I'm not very familiar with the concept, I am currently going through the documentation to see how I could fix this.

Have a good day.

RE: Problem executing simple program on Thingy91

Øyvind — Mon, 02 Jun 2025 20:13:37 GMT

Hello AdBee,

My apologies for the late reply.

[quote user="AdBee"]I don't think there is a sample to demonstrate this functionnality, or at least I didn't find it.[/quote]

No, there is no specific sample for this, but if you look at the samples that are using e.g. nrf_modem_at_printf() they will show the correct way to include the files.

This is due to the build system and how CMakeLists.txt work in the background, removing parts of the path when found in a "include" folder. That said, the documentation for the AT commands should show how to use the AT commands.

[quote user="AdBee"]Then tried to put a custom pm_static.yml file in my project directory, and following your doc I put[/quote]

Did you set CONFIG_THINGY91_STATIC_PARTITIONS_FACTORY=n along with CONFIG_THINGY91_NO_PREDEFINED_LAYOUT=y?

Could you share your pm_static file?

RE: Problem executing simple program on Thingy91

AdBee — Wed, 28 May 2025 08:28:37 GMT

Hello,

I have been trying to implement a custom static partition following your leads, but with no success.

First I ran west build -t partition_manager_report with the default thingy/nrf9160/ns board:

  flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x69000 - 420kB)-----+
+---0xc000: tfm_secure (0xc000 - 48kB)------------+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x68e00 - 419kB)-+
| 0xc200: tfm (0xbe00 - 47kB)                     |
| 0x18000: app (0x5d000 - 372kB)                  |
+---0x18000: tfm_nonsecure (0x5b000 - 364kB)------+
| 0x75000: mcuboot_secondary (0x69000 - 420kB)    |
| 0xde000: mcuboot_scratch (0x1e000 - 120kB)      |
| 0xfc000: EMPTY_0 (0x2000 - 8kB)                 |
+---0xfe000: nonsecure_storage (0x2000 - 8kB)-----+
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  otp (0x2f4 - 756B): 
+------------------------------+
| 0xff8108: otp (0x2f4 - 756B) |
+------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------------+
+---0x20000000: mcuboot_sram (0x8000 - 32kB)-------+
+---0x20000000: sram_secure (0x8000 - 32kB)--------+
| 0x20000000: tfm_sram (0x8000 - 32kB)             |
+---0x20008000: sram_nonsecure (0x38000 - 224kB)---+
+---0x20008000: nrf_modem_lib_sram (0x4568 - 17kB)-+
| 0x20008000: nrf_modem_lib_ctrl (0x4e8 - 1kB)     |
| 0x200084e8: nrf_modem_lib_tx (0x2080 - 8kB)      |
| 0x2000a568: nrf_modem_lib_rx (0x2000 - 8kB)      |
+--------------------------------------------------+
| 0x2000c568: sram_primary (0x33a98 - 206kB)       |
+--------------------------------------------------+

So far so good.

Then tried to put a custom pm_static.yml file in my project directory, and following your doc I put

CONFIG_THINGY91_NO_PREDEFINED_LAYOUT=y

in my prj.conf file.

Running again west build -t partition_manager_report, I found the exact same result than previously, meaning that my pm_static.yml file was not taken into account.

I tried to move

CONFIG_THINGY91_NO_PREDEFINED_LAYOUT=y

to my sysbuild/mcuboot.conf file with no greater success.

I also added

SB_CONFIG_PARTITION_MANAGER=y

to my sysbuild.conf file which didn't help.

Lastly, I tried to switch the board from thingy91/nrf9160/ns to thingy91/nrf9160 but at this point the project didn't even compile (the <nrf_modem.h> library that I referenced for AT commands was not found)

What am I supposed to do ?

Ty,

AdBee

RE: Problem executing simple program on Thingy91

AdBee — Tue, 27 May 2025 08:11:16 GMT

Yes, I see what you man, which can be somewhat confusing. The best way is often to look at our samples in our SDK, but of course the documentation should reflect the code base. I will report internally.

I don't think there is a sample to demonstrate this functionnality, or at least I didn't find it.

Have you successfully been able to send AT commands programmatically?

Yes with the nrf_modem_at_printf() function and the correct include it appears to work.

The only remaining question I have is about the absence of early logs. I assume it is because the hook that redirects outputs from the nRF9160 to the nRF52840 serial is set after some delay rather than at program start. Correct ?

Thank you for your support,

AdBee

RE: Problem executing simple program on Thingy91

Øyvind — Mon, 26 May 2025 15:33:58 GMT

Hello, my apologies for the late reply.

[quote user="AdBee"] The correct way to import it is to call #include <nrf_model_at.h>. I would suggest updating this doc and this one which are misleading about it.[/quote]

Yes, I see what you man, which can be somewhat confusing. The best way is often to look at our samples in our SDK, but of course the documentation should reflect the code base. I will report internally.

[quote user="AdBee"]I am trying to interact with the LTE-M/GNSS module by using AT-commands.[/quote]

Have you successfully been able to send AT commands programmatically?

[quote user="AdBee"]

Does the existence of the later file means that pm_static files are not used by default, but only if configs such as CONFIG_THINGY91_STATIC_PARTITIONS_FACTORY are provided ?

[/quote]

The build system should pick up on the file automatically. Have a look at Configuring static partitions in the partition manager. This is a KConfig symbol defined in nrf/boards/nordic/thingy91/Kconfig

config THINGY91_STATIC_PARTITIONS_FACTORY
	bool "Factory Thingy:91 partition layout"
	help
	   The default Thingy:91 partition layout used in the factory firmware. This ensures
	   firmware updates are compatible with Thingy:91 when flashing firmware over USB or over
	   the air.

Kind regards,
Øyvind

RE: Problem executing simple program on Thingy91

AdBee — Mon, 26 May 2025 11:03:01 GMT

Any update ?

EDIT: With regard to my last question, I found out that the nrfxlib library is already compiled in the packaged v2.9.0 SDK (as "west list" reveals). The correct way to import it is to call #include <nrf_model_at.h>. I would suggest updating this doc and this one which are misleading about it.

RE: Problem executing simple program on Thingy91

AdBee — Fri, 23 May 2025 10:20:00 GMT

I have an additional question.

I am trying to interact with the LTE-M/GNSS module by using AT-commands.

First I flashed the AT-Client module and verified that I could send AT command through the serial terminal.

Now I am trying to send said AT-commands programmatically.

Taking inspiration from the AT Client sample and this page here is what I have:

#include <modem/nrf_modem_lib.h>
#include <stdio.h>
#include <string.h>
#include <zephyr/kernel.h>
#include <nrfxlib/nrf_modem/include/nrf_modem_at.h>
#include <zephyr/drivers/clock_control.h>
#include <zephyr/drivers/clock_control/nrf_clock_control.h>
#include <zephyr/drivers/uart.h>

/* To strictly comply with UART timing, enable external XTAL oscillator */
void enable_xtal(void) {
  struct onoff_manager *clk_mgr;
  static struct onoff_client cli = {};

  clk_mgr = z_nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_HF);
  sys_notify_init_spinwait(&cli.notify);
  (void)onoff_request(clk_mgr, &cli);
}

int main(void) {
  int err;

  printk("The AT host sample started\n");

  err = nrf_modem_lib_init();
  if (err) {
    printk("Modem library initialization failed, error: %d\n", err);
    return 0;
  }
  enable_xtal();
  printk("Ready\n");
  err = nrf_modem_at_printf("AT+CFUN?");
  printk("%d\n", err);
}

Unfortunately I am having an error while linking the library:

/path/to/home/repos/sandbox/at_client_sample/src/main.c:12:10: fatal error: nrfxlib/nrf_modem/include/nrf_modem_at.h: No such file or directory
   12 | #include <nrfxlib/nrf_modem/include/nrf_modem_at.h>

I am unfamiliar with the build pipeline in the nrf toolchain and how I am supposed to properly do this, but I assume I might as well compile the nrfxlib library myself and then reference it as an external library in the CMakeLists.txt. So I ran:

cd ~/ncs/v2.9.0/nrfxlib
cmake .

And got:

CMake Error at CMakeLists.txt:14 (add_subdirectory_ifdef):
  Unknown CMake command "add_subdirectory_ifdef".

Since the command was not recognized, I though my cmake version might be outdated, but from my googling "add_directory_ifdef" isn't a native Cmake command but rather something defined by Zephyr/the NRF toolchain. I am a little puzzled at what to do. Any input ?

RE: Problem executing simple program on Thingy91

AdBee — Tue, 20 May 2025 08:32:16 GMT

Could you provide logs from the application of what you are describing? This does not sound correct. What program are you running on the device?

Sure. I am running this very basic program which logs the version of the app and then logs "HI" forever.

#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/logging/log.h>
#include <zephyr/sys/printk.h>

#include "app_version.h"

LOG_MODULE_REGISTER(MAIN, CONFIG_APP_LOG_LEVEL);

int main(void) {
  k_sleep(K_MSEC(100));

  LOG_INF("Hello World! %s\n", CONFIG_BOARD_TARGET);
  LOG_INF("START VERSION %s \n", APP_VERSION_STRING);

  while (true) {
    k_sleep(K_MSEC(1000));
    LOG_INF("HI \n");
  }

  // Run forever
  k_sleep(K_FOREVER);
}

This is what I see when I first flash the program:

*** Booting My Application v0.1.0-unstable-eaf0d677a29f ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:00.370,269] <inf> MAIN: Hello World! thingy91/nrf9160/ns

[00:00:00.376,708] <inf> MAIN: START VERSION 0.1.0-unstable 

[00:00:01.383,026] <inf> MAIN: HI 

[00:00:02.386,993] <inf> MAIN: HI 

[00:00:03.390,960] <inf> MAIN: HI 

[00:00:04.394,927] <inf> MAIN: HI 

[00:00:05.398,895] <inf> MAIN: HI

And this is what I see when I switch the device off/on:

[00:03:42.256,561] <inf> MAIN: HI 

[00:03:43.260,528] <inf> MAIN: HI 

    <-- Restart here 

[00:00:02.387,359] <inf> MAIN: HI 

[00:00:03.391,326] <inf> MAIN: HI 

[00:00:04.395,294] <inf> MAIN: HI

In this version the early logs don't print.

Now I am aware that log printing cannot be trusted 100% since they are not processed by the main thread but by the one that runs the default work_queue. On occasions there may be some delay/some loss (though I have CONFIG_LOG_MODE_IMMEDIATE=y in my .conf file which should somehow help a little). Still I have never witnessed an absence of early logs with a program that simple and that runs on such a low frequency when working with my previous nRF52840 project. So I am a bit surprised here.

The Thingy:91 uses its own partition layout, have a look at Partition layout. This uses e.g. nrf\boards\nordic\thingy91\thingy91_pm_static_lwm2m_carrier.yml

You could have a look at nrf\boards\nordic\thingy91\thingy91_nrf9160_partition_conf.dts

From my understanding, the pm_static files override the partitions that are defined in .dts files. Does the existence of the later file means that pm_static files are not used by default, but only if configs such as CONFIG_THINGY91_STATIC_PARTITIONS_FACTORY are provided ?

Say that I provide a custom pm_static file with CONFIG_THINGY91_NO_PREDEFINED_LAYOUT. Since I am using an external programmer and not the USB, I can overwrite the whole partition (size 0x100000) safely, right ? Won't this mess up the "connectivity bridge" that is deployed on the nRF52840 ? To what point does the "connectivity bridge" make assumptions about the partitions of the nRF9160 ?

Thank you for your support,

AdBee

RE: Problem executing simple program on Thingy91

Øyvind — Tue, 20 May 2025 06:00:07 GMT

[quote user="AdBee"]1/ When I switch off/on the device using the SW1 switch, my program doesn't restart from scratch as expected, but rather seems to resume to where it was. How is it ? [/quote]

Could you provide logs from the application of what you are describing? This does not sound correct. What program are you running on the device?

[quote user="AdBee"]How can I customize partitions in this environment ?[/quote]

The Thingy:91 uses its own partition layout, have a look at Partition layout. This uses e.g. nrf\boards\nordic\thingy91\thingy91_pm_static_lwm2m_carrier.yml

You could have a look at nrf\boards\nordic\thingy91\thingy91_nrf9160_partition_conf.dts

/*
 * Default Flash planning for thingy91_nrf9160.
 *
 * Zephyr build for nRF9160 with ARM TrustZone-M support,
 * implies building Secure and Non-Secure Zephyr images.
 *
 * Secure image will be placed, by default, in flash0
 * (or in slot0, if MCUboot is present).
 * Secure image will use sram0 for system memory.
 *
 * Non-Secure image will be placed in slot0_ns, and use
 * sram0_ns for system memory.
 *
 * Note that the Secure image only requires knowledge of
 * the beginning of the Non-Secure image (not its size).
 */

Let me know how that works for you.

Kind regards,
Øyvind

RE: Problem executing simple program on Thingy91

AdBee — Mon, 19 May 2025 12:39:57 GMT

Hello,

Thank you for your fast reply.

I think by using the thingy91/nrf9160 board instead of the thingy/nrf9160/ns, I may have overwritten some useful default partitions.

Following your link, I reinstalled all default images using the nRFConnect for Desktop, reflashed my own code with the thingy/nrf9160/ns board and it appears that it solved my problem.

I have further questions though:

1/ When I switch off/on the device using the SW1 switch, my program doesn't restart from scratch as expected, but rather seems to resume to where it was. How is it ? Is there a bootloader configuration that somehow saves PC and other registers ? Is it possible to change this behavior so that my program actually restarts at every power on ? It is unclear to me how the peripherals behave when their parameters are not explicitly set by my init functions.

2/ With regards to the partitions: I am used to customize them in a pm_static file to enable features such as nvs or BLE settings. But with this "ns" setup it seems that a lot of things are done under the hood that I shouldn't break. How can I customize partitions in this environment ?

Thank you for your time,

AdBee

RE: Problem executing simple program on Thingy91

Øyvind — Mon, 19 May 2025 10:45:19 GMT

Hello,

The Nordic Thingy:91 USB connector is connected to the USB interface of the nRF52840 SoC. This enables PC communication and battery charging. The nRF52840 comes preprogrammed with the Connectivity Bridge application which acts as a USB composite device, exposing two UART interfaces to a USB host as two CDC ACM devices.

Did you reprogram the nRF52840? I.e. build for thingy91/nrf52840?

Also, I see that you are building you project for the thingy91/nrf9160 and not the thingy91/nrf9160/ns. The latter is needed in order to communicate with the nRF91 modem from the application core. See Developing with the Thingy:91 for more information.

Kind regards,
Øyvind