Need help understanding 9160 flash programming and flash memory management.

[Spi]

I have the nRF9160 DK and I've been able to program it without problems using Visual Studio Code by simply clicking the 'Flash' option in the 'ACTIONS' side menu. The problem is that I don't actually know what happens when I do that; is it strictly done using SWD interface? What has me a bit confused is that each reset cycle results in "*** Booting nRF Connect SDK v2.5.0 ***" being spit out the console UART, so I assume mcuboot came pre-flashed in the nRF9160 (starting at flash address 0) on the DevKit?  Does the 'zephyr,code-partiton' section in the 'chosen' node of the board .dts file tell both the linker and the flash programmer where to write compiled binaries (when the 'Flash' menu is clicked)?  In nrf9160dk_nrf9160_common.dtsi, slot0_ns_partition and slot0_partition have different addresses; does that mean that the pre-programmed MCUBOOT knows to look in both of these locations (0x10000 and 0x50000, plus secondary image locations 0x80000 and 0xc0000?) when it's searching for valid application code after reset?  Finally (for now), if we only ever use SWD interface for programming flash, i.e. no over-the-air firmware update, is it okay to only define a slot0_partition in the flash0 section, i.e. can we get rid of the slot1_partition?  And do we need partitions for both slot0_partition and slot0_ns_partition if all our code is nonsecure?  And finally finally (for now), is there a reason why the secure image size partition is 0x40000 (256K) and the non-secure partition size is only 0x30000 (192K)? Or are those just example values to allow for 4 application images plus mcuboot within the 1 MB total flash space?

Thanks in advance.

[Hakon]

Hello,

What has me a bit confused is that each reset cycle results in "*** Booting nRF Connect SDK v2.5.0 ***" being spit out the console UART, so I assume mcuboot came pre-flashed in the nRF9160 (starting at flash address 0) on the DevKit?

No, the MCUboot is not pre-flashed on the DK. The DK has an on-board debugger, so that's not necessary. The thingy:91 is a different story.

Does the 'zephyr,code-partiton' section in the 'chosen' node of the board .dts file tell both the linker and the flash programmer where to write compiled binaries (when the 'Flash' menu is clicked)?

Yes, I believe that is the case for singe image builds. For multi image builds, partition manager is used.

does that mean that the pre-programmed MCUBOOT knows to look in both of these locations (0x10000 and 0x50000, plus secondary image locations 0x80000 and 0xc0000?)

No, when using MCUboot, the partitions are specified by the partition manager script. You can change the partition layout in a pm_static.yml file, that will tell the partition manager where to place the regions in flash. I recommend you read about the partition manager in the link above.

And do we need partitions for both slot0_partition and slot0_ns_partition if all our code is nonsecure?

Yes, this is necessary when using the nrf9160.

And finally finally (for now), is there a reason why the secure image size partition is 0x40000 (256K) and the non-secure partition size is only 0x30000 (192K)? Or are those just example values to allow for 4 application images plus mcuboot within the 1 MB total flash space?

I recommend that you look at the partition manager report for your build;

west build -t partition_manager_report

to see where things are actually being placed.

[Spi]

Thank you Hakon, although unfortunately your answers created follow-up questions:

1) You said, "No, the MCUboot is not pre-flashed on the DK. The DK has an on-board debugger, so that's not necessary. The thingy:91 is a different story." If that's the case, from where does the "*** Booting nRF Connect SDK v2.5.0 *** debug console string come each time the nRF9160DK board resets?

2. You said, "Yes, I believe that is the case for singe image builds. For multi image builds, partition manager is used."  I'm still confused. The nRF9160DK.dts specifies a 64K 'boot_partition', but without mcuboot, what happens to this 64K of memory.  I experimented to see how changing values in the flash0 partition starting addresses for slot0_ns_partition, i.e. changed from 0x50000 to 0x40000, and after a rebuild, the resultant zephyr.map file didn't change.  The map file suggests that the code is actually located at 0x8000 (__rom_region_start = 0x8000), which confuses me because it doesn't correspond to anything in the.dts file, nor does it match the expected actual flash start location of 0x00000000.  So again, I don't understand how the partitions in the flash0 section of my board .dts file affect anything when it comes to linking and/or board flashing.

3. You said, "Yes, this is necessary when using the nrf9160."  Continuing with my lack of understanding from point #2, if all my code is non-secure, what is the purpose of the slot0_partition? What goes there?

4. You said, "I recommend that you look at the partition manager report for your build; west build - t partition_manager_report ...".  One of the problems of having VS Code performing all the zephyr "magic" is that I don't know how to manually invoke "west".  I can see it being invoked as part of the VS Code "Build" process, but "west" is not recognized by either Power Shell or Command Prompt.  I'm guessing it's perhaps a path issue, but I can't find a west.* executable file anywhere so don't know how to get around that.

Is there any documentation that attempts to explain any of this stuff?  I don't see any mention of any of this in Section 4.2 (Memory map) of nRF9160 Product Specification 2.1.

The impetus for these questions is that our application will be using on-chip flash for saving periodic status information so I need to know where the application code begins/ends and therefore which parts of flash are available for data storage.

Thanks again in advance, and sorry for so many questions.