NVS in non secure application

[Bernhard]

Hello,

I am relatively new to the nRF Connect SDK and I'm developing an application for nRF9160DK on toolchain version 2.0.2.

I am working on a non-secure application and trying to integrate the NVS sample, but can't get it working with a non-secure build (also the sample is not working).
From my point of view everything should be fine since the nvs_storage is located inside of the nonsecure_storage, but application is not starting up.
When I debug the application it get's stuck at "spu_regions_flash_config_non_secure" (target_cfg.c line 554).

I am grateful for every hint.

Best regards,
Bernhard

[Sigurd Hellesvik]

Hi

Are you able to build and run the NVS sample without changes for "nrf9160dk_nrf9160_ns"?

Regards,
Sigurd Hellesvik

[Bernhard]

I am able to build and flash it but it doesnt start, same sample with secure build runs as expected.

[Sigurd Hellesvik]

Hi,

Do you have debug options enabled when you build?

Regards,
Sigurd Hellesvik

[Bernhard]

Indeed, that solved the problem.

Why is that? I build the secure application also with enabled debug options.

Also I noticed that the option is changing the program flow a lot more than expected, the timing is different now (for example printk messages are now sent after the initial shell prompt, while with enabled debug options they were sent first).

I thought that the option is more or less neutral to the application, even as I am searching now I can not find a description of this effect.

[Sigurd Hellesvik]

Hi,

Good to hear that it solved the problem!

For the Debug Options, see the docs on Debugging an application.
This sets the two configurations CONFIG_DEBUG_OPTIMIZATIONS and CONFIG_DEBUG_THREAD_INFO.
If you look at these options, you can see which other options they select. Maybe some of these are messing with your application somehow?

You could try to only enable CONFIG_DEBUG_OPTIMIZATIONS manually, to see if it makes a difference.

Also try to use Ozone to debug, as it is usually better at debugging Threads than GDB.

Regards,
Sigurd Hellesvik