Partitioning issues on thingy91_nrf9160_ns with nRF connect 1.7.0

Hi,

I have some troubles with partitioning while using thingy91_nrf9160_ns. I have some FLASH overflow when compiling it with west using 1.7.0 library, while everything fits when I use 1.6.0. After some investigation it seemed that it turned MCUBoot on and split memory into half - for the primary and secondary partition.

To provide some minimal working example, I tried it also on your code:
samples/nrf9160/modem_shell where it is said quite explicitly in prj.conf file:

# BOOTLOADER_MCUBOOT reduces usable flash size by half so it's disabled by default
# This means application FOTA is disabled. Modem FOTA works without these.
CONFIG_BOOTLOADER_MCUBOOT=n
CONFIG_IMG_MANAGER=n
CONFIG_IMG_ERASE_PROGRESSIVELY=n

but then these configs are enabled again in boards/thingy91_nrf9160_ns.conf, so I removed these configs:

# For APP FOTA
#CONFIG_BOOTLOADER_MCUBOOT=y
#CONFIG_IMG_MANAGER=y
#CONFIG_IMG_ERASE_PROGRESSIVELY=y

And building with this settings I got again all this MCUBoot partitions:

+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x69000 - 420kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x68e00 - 419kB)-+
| 0xc200: spm (0xc000 - 48kB)                     |
| 0x18200: app (0x5ce00 - 371kB)                  |
+-------------------------------------------------+
| 0x75000: mcuboot_secondary (0x69000 - 420kB)    |
| 0xde000: mcuboot_scratch (0x1e000 - 120kB)      |
| 0xfc000: EMPTY_0 (0x2000 - 8kB)                 |
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+


I tried to define pm_static.yml in my project dir and point some file with PM_STATIC_YML_FILE, but it didn't work for me at all.

What finally worked was simultanously setting CONFIG_BOOTLOADER_MCUBOOT=n and deleting "zephyrproject/nrf/boards/arm/thingy91_nrf9160/pm_static.yml" file. It looks that the mentioned file shadows in some way static partitions defined in my project and is used by PM to do the partitioning by default.

Deleting some file from the SDK before every build is of course quite ugly, so I would like to know if there is any nicer way to get back to the old partitioning with nRF connect 1.7.0?

Regards,
Michał

Parents
  • Hi,

     

    I tried to define pm_static.yml in my project dir and point some file with PM_STATIC_YML_FILE, but it didn't work for me at all.

    What finally worked was simultanously setting CONFIG_BOOTLOADER_MCUBOOT=n and deleting "zephyrproject/nrf/boards/arm/thingy91_nrf9160/pm_static.yml" file. It looks that the mentioned file shadows in some way static partitions defined in my project and is used by PM to do the partitioning by default.

    Deleting some file from the SDK before every build is of course quite ugly, so I would like to know if there is any nicer way to get back to the old partitioning with nRF connect 1.7.0?

    In order to fit everything in flash for the thingy91 board, curl is disabled in the project settings:

    https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/modem_shell/boards/thingy91_nrf9160_ns.conf#L12

     

    This gave a headroom of around 20k flash at my end atleast:

    [319/324] Linking C executable zephyr/zephyr.elf
    Memory region         Used Size  Region Size  %age Used
               FLASH:      360704 B     380416 B     94.82%
                SRAM:      104032 B     170776 B     60.92%
            IDT_LIST:          0 GB         2 KB      0.00%
    

     

    Deleting the pm_static in the board file directly will be problematic if you use mcuboot to program, ie. you're not programming the thingy91 via SWD connector.

     

    Kind regards,

    Håkon

Reply
  • Hi,

     

    I tried to define pm_static.yml in my project dir and point some file with PM_STATIC_YML_FILE, but it didn't work for me at all.

    What finally worked was simultanously setting CONFIG_BOOTLOADER_MCUBOOT=n and deleting "zephyrproject/nrf/boards/arm/thingy91_nrf9160/pm_static.yml" file. It looks that the mentioned file shadows in some way static partitions defined in my project and is used by PM to do the partitioning by default.

    Deleting some file from the SDK before every build is of course quite ugly, so I would like to know if there is any nicer way to get back to the old partitioning with nRF connect 1.7.0?

    In order to fit everything in flash for the thingy91 board, curl is disabled in the project settings:

    https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/modem_shell/boards/thingy91_nrf9160_ns.conf#L12

     

    This gave a headroom of around 20k flash at my end atleast:

    [319/324] Linking C executable zephyr/zephyr.elf
    Memory region         Used Size  Region Size  %age Used
               FLASH:      360704 B     380416 B     94.82%
                SRAM:      104032 B     170776 B     60.92%
            IDT_LIST:          0 GB         2 KB      0.00%
    

     

    Deleting the pm_static in the board file directly will be problematic if you use mcuboot to program, ie. you're not programming the thingy91 via SWD connector.

     

    Kind regards,

    Håkon

Children
  • Hi,

    I'm afraid that unfortunately you misunderstood my point. Your modem shell example builds well for me too, the only point was to show that I cannot change the memory layout disabling the mcuboot config. So, is there any way to change it? While I'm quite convinced that programming a board using mcuboot is a nice feature, it doesn't leave a lot of memory to program it - you managed to fit some example in it (after disabling curl), but for anything more complex it might be problematic, so I think it would be a nice thing to allow user to use some easy way to get back to the old partitioning.

    Kind regards,
    Michał

  • Hi Michał,

     

    Since the thingy:91 does not have a dedicated programmer on-board, most users depend on using mcuboot for programming the device. As such, the pm_static.yml is set in the board itself to avoid scenarios where the static partition layout differs from what mcuboot expects.

    For your use-case, it sounds like you want to create your own board, matching your wanted hardware and application behavior.

     

    Kind regards,

    Håkon

Related