MCUBoot: Not enough free space to run swap upgrade - With plenty space

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Tue, 22 Aug 2023 10:22:02 GMT

Hi,

It looks like the issue is with NCS v2.2.0. I was able to get your sample to work in NCS V2.3.0.

I spent some time before I had a leave from the office last week trying to investigate what the cause was but I isolate it as I saw other issues than what you've described earlier in the ticket when attempting to recreate it (the error mentioned here). I had to wait for Sigurd (the Author of the sample you've based your code on) to return from vacation to get some verifications regarding the sample which was not until today.

Here is what I did to get it to work in NCS v2.3.0. It's nothing major, and the attached zip is basically https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/smp/mcuboot_smp_uart_feat_external_flash with the additional filler code you've added to your project.

devzone.nordicsemi.com/.../Archie_5F00_sample_5F00_w_5F00_Andreas_5F00_mod_5F00_NCSv2.3.0.zip

Built the new firmware with NCS v2.3.0 and toolchain v2.3.0 
Removed configurations that are integrated in mcuboot (os_mgmt etc)

1: Built and flashed build_original
west build -d build_original -b nrf52840dk_nrf52840 -p
west flash d build_original --recover

2: Made modificaitons in the print in between updates

3: Built the build_updated
west build -d build_updated -b nrf52840dk_nrf52840 -p

4: Check the status on the DK running the original firmware
- Connect to a terminal, reset the board and observe the original firmware is running
- Disconnect from the terminal
- Check mcumgr image list status using 'mcumgr --conntype serial --connstring "/dev/ttyACM0,baud=115200" image list'. replace /dev/ttyACM0 with relevant COM for Windows. In my case COM8
- See that there is only one item in slot 0 and nothing in slot1

C:\Nordic\SDKs\ncs\my_projects\case_reproduction\310017\mcuboot_smp_uart_feat_external_flash>mcumgr --conntype serial --connstring "COM8,baud=115200" image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: 87a2f48c791c342495a8c96c1b2a085de9f1e3c0cd3d011f82d626f1a66b11fa
Split status: N/A (0)

- If there is something in slot 1, erase with mcumgr --conntype serial --connstring "/dev/ttyACM0,baud=115200" image erase 


5: Upload the new umage with mcumgr --conntype serial --connstring "/dev/ttyACM0,baud=115200" image upload <project_location>/build_updated/zephyr/app_uppdate.bin

C:\Nordic\SDKs\ncs\my_projects\case_reproduction\310017\mcuboot_smp_uart_feat_external_flash>mcumgr --conntype serial --connstring "COM8,baud=115200" image upload build_updated\zephyr\app_update.bin
 906.82 KiB / 906.82 KiB [===============================================================================] 100.00% 2.42 KiB/s 6m15s
Done


6: Recheck mcumgr status with image list. Exect to see two different hashes in slot 0 and 1 
C:\Nordic\SDKs\ncs\my_projects\case_reproduction\310017\mcuboot_smp_uart_feat_external_flash>mcumgr --conntype serial --connstring "COM8,baud=115200" image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: 87a2f48c791c342495a8c96c1b2a085de9f1e3c0cd3d011f82d626f1a66b11fa
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags:
    hash: 1ffedec40d7e03c6645b33c506c06a55fe1cd876845657abbcda44366d372076
Split status: N/A (0)

7: Flag with test:
C:\Nordic\SDKs\ncs\my_projects\case_reproduction\310017\mcuboot_smp_uart_feat_external_flash>mcumgr --conntype serial --connstring "COM8,baud=115200" image test 1ffedec40d7e03c6645b33c506c06a55fe1cd876845657abbcda44366d372076
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: 87a2f48c791c342495a8c96c1b2a085de9f1e3c0cd3d011f82d626f1a66b11fa
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags: pending
    hash: 1ffedec40d7e03c6645b33c506c06a55fe1cd876845657abbcda44366d372076
Split status: N/A (0)

8: Connect to a terminal and restart the DK
*** Booting Zephyr OS build v3.2.99-ncs2 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0x10000
*** Booting Zephyr OS build v3.2.99-ncs2 ***
[00:00:00.001,708] <inf> app: This is the updated customer firmware

9: See that images has been swapped with image list
C:\Nordic\SDKs\ncs\my_projects\case_reproduction\310017\mcuboot_smp_uart_feat_external_flash>mcumgr --conntype serial --connstring "COM8,baud=115200" image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active
    hash: 1ffedec40d7e03c6645b33c506c06a55fe1cd876845657abbcda44366d372076
 image=0 slot=1
    version: 0.0.0
    bootable: true
    flags: confirmed
    hash: 87a2f48c791c342495a8c96c1b2a085de9f1e3c0cd3d011f82d626f1a66b11fa
Split status: N/A (0)

Did you ever observe

Kind regards,
Andreas

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Mon, 21 Aug 2023 12:22:06 GMT

Hi Andreas,

Any news on this?

Best,

ARchie

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Mon, 31 Jul 2023 07:27:35 GMT

Hi Archie,

No worries about the delayed response time from your end. I've just come back from holidays and will be looking into the sample starting today.

Kind regards,
Andreas

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Wed, 19 Jul 2023 14:29:22 GMT

Hello,

Sorry for the delay I have attached a minimal example, more information is in the readme.

Please let me know if you have any questions.

Best,

Archie

devzone.nordicsemi.com/.../archie_5F00_example.zip

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Mon, 10 Jul 2023 13:54:54 GMT

Hi again,

Apologies for the slow response time and the inconvenience caused by that. We're currently a bit reduced due to the main summer vacation here in Norway so response time is longer than usual. If the issue you're experiencing still persists, could you provide me with a minimal sample in a zip so I can attempt to reproduce the issue and see if I can spot something before I leave for vacation myself? I will see if I can find someone who can handle the case while I'm out of office, but I would expect that there will be some more waiting time until I return from vacation myself.

Kind regards,
Andreas

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Thu, 29 Jun 2023 14:37:07 GMT

Hi Andreas,

We get the same issue.

Best,

Archie

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Thu, 29 Jun 2023 09:28:34 GMT

Hi Archie,

What happens if you use dynamic partitioning (no static pm) when building and flashing the new firmware? As long as the original applications secondary and primary is large enough to fit the image, I would assume that this should work.

Kind regards,
Andreas

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Tue, 27 Jun 2023 11:19:31 GMT

Lowering littlefs gives me this layout (which is now in the pm_static):

  external_flash (0x800000 - 8192kB): 
+---------------------------------------------+
| 0x0: mcuboot_secondary (0x72000 - 456kB)    |
| 0x72000: littlefs_storage (0x10000 - 64kB)  |
| 0x82000: external_flash (0x77e000 - 7672kB) |
+---------------------------------------------+

  flash_primary (0x80000 - 512kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xe000 - 56kB)                    |
+---0xe000: mcuboot_primary (0x72000 - 456kB)-----+
| 0xe000: mcuboot_pad (0x200 - 512B)              |
+---0xe200: mcuboot_primary_app (0x71e00 - 455kB)-+
| 0xe200: app (0x71e00 - 455kB)                   |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

Reports the same after the single character change.

Same memory usage the previous builds.

The outcome is the same, with the same app code. It doesn't seem to be the littlefs partition causing any issues.

Just did another test trying to load a 370k image on while running the 401k image and that didn't work. Nor did the other way around.

Best,

Archie

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Tue, 27 Jun 2023 10:27:13 GMT

Hi Andreas,

Full App Size (Bigger Build):

Memory region         Used Size  Region Size  %age Used
           FLASH:      413140 B     466432 B     88.57%
             RAM:      125092 B       128 KB     95.44%
        IDT_LIST:          0 GB         2 KB      0.00%

With a single character added to tell builds apart:

Memory region         Used Size  Region Size  %age Used
           FLASH:      413144 B     466432 B     88.58%
             RAM:      125092 B       128 KB     95.44%
        IDT_LIST:          0 GB         2 KB      0.00%

Size of app_update.bin according to Windows:

404 KB (413,992 bytes)

MCUBoot Logs say:

[00:00:02.179,748] <wrn> mcuboot: required 421888 bytes but only 413696 are available

Will try lowering the littlefs partition and get back to you.

Best,

Archie

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Mon, 26 Jun 2023 15:05:19 GMT

Can you verify the size of the image when it is built? Either from the build output log or memory report? As far as I have seen it is implied to be 421888bytes from the device log, but not a explicit number stating its size

Regarding the external flash being negative. I have a suspicion that the negative size on the external flash might be related to the issue. Since the secondary partition is located on the external flash, there are reasons to believe that the issues are coupled. Are you able to resolve that issue and then check in if that changes anything w.r.t accepting a larger app image than the firmware you succeeded with?

In addition, I recommend you to have a look at https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/smp. This repo contains some minimal samples illustrating how to do that specific thing (and not much else) in an application. The smp_uart_feat_external_flash sample should be relatively easy to port to using BLE instead of UART and to your custom based 52833

In the meanwhile I will continue looking into other things that may cause this issue

Kind regards,
Andreas

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Mon, 26 Jun 2023 08:38:41 GMT

Hi Andreas,

Great thank you. Let me know if you need any more information.

Many Thanks,

Archie

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Thu, 22 Jun 2023 13:28:30 GMT

Hi Archie,

Thank you for providing this. I will have a look at the files provided. This is just a heads up that it might take some time, but I'll do my best to get back to you no later than early during the coming work week

Kind regards,
Andreas

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

ArchieA_C — Wed, 21 Jun 2023 16:00:53 GMT

Hi Andreas,

Here is the original map:

  external_flash (0x802000 - 8200kB): 
+-----------------------------------------------+
| 0x0: mcuboot_secondary (0x72000 - 456kB)      |
| 0x72000: littlefs_storage (0x790000 - 7744kB) |
| 0x802000: external_flash (-0x2000 - -8192B)   |
+-----------------------------------------------+

  flash_primary (0x80000 - 512kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xe000 - 56kB)                    |
+---0xe000: mcuboot_primary (0x72000 - 456kB)-----+
| 0xe000: mcuboot_pad (0x200 - 512B)              |
+---0xe200: mcuboot_primary_app (0x71e00 - 455kB)-+
| 0xe200: app (0x71e00 - 455kB)                   |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

Here is after changing one character in a log:

  external_flash (0x802000 - 8200kB): 
+-----------------------------------------------+
| 0x0: mcuboot_secondary (0x72000 - 456kB)      |
| 0x72000: littlefs_storage (0x790000 - 7744kB) |
| 0x802000: external_flash (-0x2000 - -8192B)   |
+-----------------------------------------------+

  flash_primary (0x80000 - 512kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xe000 - 56kB)                    |
+---0xe000: mcuboot_primary (0x72000 - 456kB)-----+
| 0xe000: mcuboot_pad (0x200 - 512B)              |
+---0xe200: mcuboot_primary_app (0x71e00 - 455kB)-+
| 0xe200: app (0x71e00 - 455kB)                   |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

Why external flash is negative is a different issue but doesn't seem to affect this.

Here is the pm_static.yml that I got from the original builds partition.yml and then used to build the new image:

app:
  address: 0xe200
  end_address: 0x80000
  region: flash_primary
  size: 0x71e00
external_flash:
  address: 0x802000
  end_address: 0x800000
  region: external_flash
  size: -0x2000
littlefs_storage:
  address: 0x72000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x802000
  placement:
    before:
    - tfm_storage
    - end
  region: external_flash
  size: 0x790000
mcuboot:
  address: 0x0
  end_address: 0xe000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xe000
mcuboot_pad:
  address: 0xe000
  end_address: 0xe200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xe000
  end_address: 0x80000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0x72000
  span: *id001
mcuboot_primary_app:
  address: 0xe200
  end_address: 0x80000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x71e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x72000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0x72000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

Used nRF Device Manger on iOS to upload the new image and got the following log after it restarted my device:

*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.253,753] <inf> mcuboot: Starting bootloader
[00:00:00.254,882] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x1, image_ok=0x1
[00:00:00.255,187] <inf> mcuboot: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
[00:00:00.255,187] <inf> mcuboot: Boot source: none
[00:00:00.255,645] <inf> mcuboot: Swap type: test
[00:00:02.177,764] <inf> mcuboot: Starting swap using move algorithm.
[00:00:02.177,795] <wrn> mcuboot: Not enough free space to run swap upgrade
[00:00:02.177,795] <wrn> mcuboot: required 421888 bytes but only 413696 are available
[00:00:02.177,825] <dbg> mcuboot: boot_write_copy_done: writing copy_done; fa_id=3 off=0x71fe0 (0x7ffe0)
[00:00:02.178,039] <inf> mcuboot: Bootloader chainload address offset: 0xe000
[00:00:02.178,070] <inf> mcuboot: Jumping to the first image slot

Here are all the configs related to the BT SMP taken from the smp_svr sample:

CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_REASSEMBLY_BT=y
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y
CONFIG_OS_MGMT_MCUMGR_PARAMS=y
CONFIG_MCUMGR_GRP_ZEPHYR_BASIC=y
CONFIG_MCUMGR_GRP_BASIC_CMD_STORAGE_ERASE=y
CONFIG_BT_DEVICE_APPEARANCE=768
CONFIG_BT_ATT_ENFORCE_FLOW=n
CONFIG_BT_MAX_PAIRED=3
CONFIG_BT_LONG_WQ_STACK_SIZE=2048
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_MCUMGR_BUF_SIZE=2475
CONFIG_MCUMGR_SMP_WORKQUEUE_STACK_SIZE=4608
CONFIG_BT_CTLR_LE_PING=n
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

I have just got it to work with smaller images of 370kB vs 401kB using the same pm_static.yml. However, I'm unsure why there is an issue giving that 401kB is less than 455kB which is what partition manager reports my app partition to be.

Many Thanks,

Archie

RE: MCUBoot: Not enough free space to run swap upgrade - With plenty space

AHaug — Wed, 21 Jun 2023 12:37:20 GMT

Hi,

[quote user=""]However, I should have more than 401408 bytes available which is seen here:[/quote]

Is this memory report from the original firmware or the new firmware?

[quote user=""]I have tried creating a pm_static.yml, I have also tried adding in partition as suggested in this thread but that didn't fix it. [/quote]

What did you put in the pm_static.yml? The mapping from the original firmware or the new firmware? The static for the new firmware should be identical (or at least start addresses for the partitions should be identical) as in the original firmware for MCUboot to know where to start the application from, and from where to fetch the new image from

If you can attach the partition map from both versions of your application it might give me some more hints w.r.t. why it complains that there are no room for the application. If they are identical then I will have to investigate some more

Kind regards,
Andreas