Need help understanding 9160 flash programming and flash memory management.

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.

Parents
  • I installed 'west' and 'cmake' and was able to get the partition_manger_report you suggested:

      flash_primary (0x100000 - 1024kB):
    +-------------------------------------------+
    +---0x0: tfm_secure (0x8000 - 32kB)---------+
    | 0x0: tfm (0x8000 - 32kB)                  |
    +---0x8000: tfm_nonsecure (0xf8000 - 992kB)-+
    | 0x8000: app (0xf8000 - 992kB)             |
    +-------------------------------------------+

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

      sram_primary (0x40000 - 256kB):
    +--------------------------------------------------+
    +---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 did a bit of digging in the build folders and found tfm_secure.hex, tfm_nonsecure.hex, and tfm_merged.hex.  I assume tfm_merged.hex is what gets programmed into nRF9160, and the 0s and 1s in tfm_secure.hex is some magic code generated as part of setting up the project.  I don't know if that code ever runs, or what it does, but I can ignore it for now because it chews up only 32kb of flash.

    Either way, it would appear that all the partition information specified in the board.dts file is totally ignored. And if that understanding is correct, then perhaps that's all I need to know for now.

  • Hi!

    Håkon is out of office, so I'm replying instead.

    Spi said:
    Either way, it would appear that all the partition information specified in the board.dts file is totally ignored. And if that understanding is correct, then perhaps that's all I need to know for now.

    Correct, I think the key here is this note in the PartitionManager docs:

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html#partition-manager

Reply Children
Related