MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Tue, 20 Aug 2024 10:46:54 GMT

[quote user="FinnBiggs"]How did you know that the overflow was coming from the mcuboot partition, and not one of the others?[/quote]

First and foremost experience.

Secondly, if you change the app, the overflow stays the same, so it must be something else, and for the nRF52840, that can only be MCUboot.

But if you read closely in the build log, you can see that the paths close before the flash overflow error, you will see the path to MCUboot ncs/bootloaders/mcuboot/boot/zephyr.

[quote user="FinnBiggs"]On that same note, why would the required size for that partition change?[/quote]

Default size is 0xC000, which is true for the default MCUboot configuration, plus eventual board-specific MCUboot configurations.

If you add more functionality to MCUboot, you may get a bigger MCUboot app.
This is typically adding exeternal flash drivers, or Serial Recovery functionality.

The flash overflow issue has two different solutions:

Increasing MCUboot partition size.
Reducing MCUboot app size by disabling stuff in Kconfig
- See for example prj_minimal.conf
- At some point you will have optimied away everything you do not need, at which case the other option is the only left.

The latter is technically more clean if possible, but harder.

Another point to make here is:
MCUboot will inherit configurations from board files.
This means that you could get into a state where MCUboot works for nRF52840 but fails for the Xiao.

And this is a good seg-way to the issue.

I propose the following steps, all for the Xiao:

Verify that MCUboot is the error
1. Build without and with MCUboot. Does it work without?
Compare the following files between Xiao and nRF52840DK:
1. build/mcuboot/zephyr/zephyr.dts
2. build/mcuboot/zephyr/.config
3. Feel free to send me those files as well, and I can have a look.
When comparing above, we can expect some differences based on the boards. But keep a lookout for differing configs that are not board specific.
1. A common thing is that some boards have logging configs in board config, such as enabling RTT, USB or UART or other stuff. And those are not nessecarily useful for MCUboot.
2. I can also mention that MCUboot is known to be a bit unstable with RTT.
Try to fix things you found and see what happens

If those steps does not work, I have the following questions for another potential path:

[quote user="FinnBiggs"]a JLink probe to recover back into its bootloader mode.[/quote]

What is the "bootloader mode" here?

[quote user="FinnBiggs"]I'm extremely grateful for all the help you've provided on these last few responses. Can I send a cake or a box of pastries to your office as a thank you?[/quote]

Thanks for the offer, but I decline.
Still, it warms my heart to be able to help and to have thankful customers! It is what makes this job fun!

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

FinnBiggs — Tue, 20 Aug 2024 01:24:35 GMT

Hi Sigurd,

I have good and bad news.

The good news: your changes work perfectly on the Dev Kit.

The bad news: the Xiao version fails with no build errors, serial/console output, or RTT output. For Xiao, this application builds correctly, but does not boot, and requires a JLink probe to recover back into its bootloader mode.

I have no idea where to go from here - there's not a ton of information I can send to you because I can't get any output from this application on my target hardware.

--------------------

[quote userid="106736" url="~/f/nordic-q-a/113318/mcuboot-exfat-usb-filesystem-and-flash-region-overflows/498878"]So if I missed any questions about theory, please let me know and I will explain.[/quote]

There's one aspect of your process where I got lost:

How did you know that the overflow was coming from the mcuboot partition, and not one of the others?

On that same note, why would the required size for that partition change?

--------------------

I'm extremely grateful for all the help you've provided on these last few responses. Can I send a cake or a box of pastries to your office as a thank you?

Cheers,

- Finn

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Mon, 19 Aug 2024 13:53:38 GMT

I must confess that I did not read all your explanations. So if I missed any questions about theory, please let me know and I will explain.

However, I think I fixed the issue at hand.
First, I will say that I just tested on the DK so far. I do got an Xiao laying around somewhere, but i think and hope that when we have solved the DK issue the Xiao will be good as well.

BOOT_MAX_IMG_SECTORS=____ - too small?

This error message will also appear if the flash driver does not fail.
This is a bug that is fixed in newer versions of MCUboot.

But still, we need to know why the driver does not work. It is likely configured wrong.

To find this, I built a working sample for the NRF52840DK, and tested this to make sure.

With two samples, I can compare configurations.
Since it fails in MCUboot I will compare MCUboot configurations.
So for each sample I compare the following files:

build/mcuboot/zephyr/zephyr.dts
build/mcuboot/zephyr/.config

With this, I found that in .config, your sample is missing CONFIG_NORDIC_QSPI_NOR, so I added that.

And for DTS, I found that "nordic,pm-ext-flash = &mx25r64;" is missing altogether.
So I added "aosihfjkasbfjkbsakj" to the overlay file. And this did not give a build error, meaning that the file itself is not parsed.

We can fix this in two ways:

Either move the file to child_image/mcuboot/nrf52840dk_nrf52840.overlay.
- I think this should work at least
Or to add the path of the mcuboot overlay to the build script.
- This is the method I used
- This must use the full path, cause unintuitively it will use the relative path from https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/ and not from your app.

devzone.nordicsemi.com/.../mass_5F00_pm_5F00_dfu_5F00_urd_5F00_2024_2D00_08_2D00_19.zip

This fixes the "mcuboot cannot find external flash" issue. I think that is the one issue you had here right?

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Thu, 15 Aug 2024 13:05:40 GMT

Thanks for the info.
I will get back to you tomorrow or Monday on this

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

FinnBiggs — Thu, 15 Aug 2024 02:20:16 GMT

Hi Sigurd,

Sorry to give you extra work! You're right, I forgot to attach my restructured project. My bad.

I also did considerable cleanup work in the config files, and I'll include it at the end of this post.

The build system now finds the child image.

-------------

I don't think I was confused about the partitions' purpose, but they couldn't increase in size from what I had without separating the mcuboot primary and secondary into different regions, which I was uncertain was permitted.

The partitions in my previous structure fully occupied the 1MB flash_primary region, so to expand any one partition, the others would have to shrink or relocate.

Luckily, the mcuboot primary and secondary CAN be separated (into flash_primary & external flash)!

-------------

[quote userid="106736" url="~/f/nordic-q-a/113318/mcuboot-exfat-usb-filesystem-and-flash-region-overflows/498220"]The flash overflow is in mcuboot. This means that moving or resizing mcuboot_primary/mcuboot_secondary will not matter too much. As long as there is space for the app inside them ofc.[/quote]

I'm very curious - what informed you that the overflow was arising from mcuboot?

-------------

[quote userid="106736" url="~/f/nordic-q-a/113318/mcuboot-exfat-usb-filesystem-and-flash-region-overflows/498220"]Then I removed most things from pm_static.yml.[/quote]

Very cool, thanks! I'm a fan of dynamic partitioning when it works 🙂

-------------

[quote userid="106736" url="~/f/nordic-q-a/113318/mcuboot-exfat-usb-filesystem-and-flash-region-overflows/498220"]Let me know how this works on your side.[/quote]

Good news: this solves the flash overflow!

Bad news: on dev kit, this breaks the DFU capability of the application in what seems to be a fairly complex way. (More in next section). It also causes the xiao boards to lock up, requiring a JLink erase and fresh flash of the xiao-ble-sense bootloader to recover.

-------------

Once again, I took a serious amount of notes in trying to get to an answer, and although I'll include them in the zip file, it'll be better to highlight key findings in this post.

When I build and flash your project (using SDK v2.5.0 - (is this right?)), I get the following behavior:

*** Booting nRF Connect SDK v2.5.0 ***
I: Starting bootloader
W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=64 - too small?
E: Image in the primary slot is not valid!
E: Unable to find bootable image

Though I can build, I can't boot the provided application.

This took me on a fun series of tests. If 64 is too small, why not try bigger? I tried all of the following:

    CONFIG_BOOT_IMG_SECTORS = {
        absent (default), 
        64, 
        128, 
        256, 
        512, 
        1024,
        4096,
        8192, (this and all below are "BOOT_IMG_MAX_SECTORS=(number) - too small?"), 
        16384, (Ram overflow) (ld.bfd.exe: region `RAM' overflowed by 18368 bytes)
        -- (binary search back down to "can fit") --
        12288 (too small),
        14336 (too small),
        15360 (`RAM' overflowed by 1984 bytes),
        14848 (too small)
    }
At which point I discontinued this effort.

No number of sectors let me boot my application.

-------------

When an easy fix didn't appear, I turned to google to help ID the error.

Results about this problem are fairly sparse, but I did find this devZone post:

Device Firmware Update (DFU) with MCUBoot bootloader showing Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small?

That thread suggested a good number of sectors (256, which I validate as a good size in my notes), which I fixed for the rest of the debugging.

Another devzone user (Estnik) suggested:

I have come to realize that it has something to do with the overlay file and the build system. I use west build -b nrf52dk_nrf52832 -- -Dmcuboot_OVERLAY_CONFIG=<app_samples>/basic/blinky/usb_cdc_acm_log_recovery.conf to build my application. Even if I have a completely empty usb_cdc_acm_recovery.conf file, the issue occurs.

Which seems like a good lead.

Unfortunately, the solution there was to place the config options in mcuboot.conf, which solved Estnik's issue, but doesn't solve mine.

-------------

I found a second source of information on this error:

https://interrupt.memfault.com/blog/mcuboot-overview#resolving-flash-dependencies

Which suggests that the problem arises from a lack of flash dependencies.

I wasn't able to implement a lot what I read in this article. It seems one layer closer to the hardware than Nordic SDK, but I hope it might provide insight.

-------------

Circling back to the devzone post, Hakon includes an example of blinky with mcuboot enabled.

When I build that, I get what I assume are version difference errors. Those errors disappear when I replace the main with a stub that simply prints a message to console.

That application's structure is nearly identical to mine, but I can get that one to work.

The output of that code is:

*** Booting nRF Connect SDK v2.5.0 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slotÿ*** Booting nRF Connect SDK v2.5.0 ***
BLINKY MCUBOOT WITH NO CODE

This is the config for that sample (and mcuboot.conf), and I've highlighted the items that seem like potential candidates for a fix.

Do you think either of these options could contribute to the "too small?" sector error?

-------------

For my two builds, with the new configuration, I have identical memory reports except for the size that's left in external_flash, which is expected because the external flash hardware have different size.

So at least the structure of the partitioning is working well, now.

-------------

I was able to get the (mass_pm_dfu) application booting using only the dynamic partitioning once I closed and reopened vsCode. I don't know why, but at least I was able to get past the bootloader chainload output.

The output then became:

(And the warning is just how I'm version-stamping various DFUs)

When I attempt to disregard the sector error and move past it (because, hey, if it works...)

The DFU is actually blocked by a "Bad file number" on the terminal output, which happens just before a GATT Conn Timeout on the app that provides DFU (nrf Connect, Android app).

-------------

The previous version of this project had successful DFU updates on Dev Kit, but now I am unable to update on either device, though it will build for Xiao.

Got advice? I'm not sure what the next steps for debugging are.

And, before I post let me actually attach a zip file with my restructuring, notes, build commands, and cleanup! (Build commands are now located at scripts/dk_build.sh and scripts/xiao_build.sh)

Thank you so much.

Best,

- Finn

devzone.nordicsemi.com/.../mass_5F00_pm_5F00_dfu_5F00_finn_5F00_2024_2D00_08_2D00_14.zip

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Wed, 14 Aug 2024 09:12:12 GMT

Hi Finn,

You forgot to upload the new project I think.

I will upload a fixed project at end of this message still. But first let me answer your questions:

[quote user="FinnBiggs"]As part of trying to get things working, I restructured the project to match the structure from the nrf connect sdk intermediate course lesson on FOTA[/quote]

I like this. Maybe just because I am more familiar with this structure. But I like it.

[quote user="FinnBiggs"]The build system will not automatically find the child_image conf file [/quote]

It should. See my project.

[quote user="FinnBiggs"]When I set the CONFIG_CBPRINTF_NANO=n, I get the same amount of overflow as when it's 'y'.[/quote]

Right yes I see that I was mistaken in my previous reply.

[quote user="FinnBiggs"]

Seems like the Nano option isn't the right approach, which brings me to your second suggestion -- change the partitioning to increase mcuboot space.

Is it permitted to separate the MCUBoot partitions? Otherwise, it's not possible to make more space.

[/quote]

I think you are mixing up partitions here. Let me explain them:

mcuboot: The bootloader MCUboot lives here. It is 0xC000 by default
mcuboot_primary: The application lives here. It will be half of available space left after all other partitioning is done.
mcuboot_secondary: Your update lives here. It will be the same size as mcuboot_primary.

The flash overflow is in mcuboot. This means that moving or resizing mcuboot_primary/mcuboot_secondary will not matter too much. As long as there is space for the app inside them ofc.

[quote user="FinnBiggs"]Would it be feasible to try moving mcuboot_secondary into external_flash?[/quote]

It is very possible and maybe even recommended. But it won't fix this issue specifically.

Fixed project

Here is what I did:
I took this one:

[quote user="FinnBiggs"]mass_pm_dfu_2024-08-02.zip[/quote]

and reformatted it to use my preferred directory structure.

Then I added a child image folder to add a pair of configurations to MCUboot.

Then I removed most things from pm_static.yml. Why?
In my mind, pm_static has two use-cases:
1. To define custom partitions
2. To freeze partitioning for release. (This can be done by copying build/partitions.yml when done developing) ((Freezing partitioning for release is a hard requirement by DFU))

For none of these, you need to define it all for developing. Instead I recommend only defining partitions as you need them, and then use Kconfig options to change sizes. This way, the build system will automatically partition your project for you, and you are not as limited in what you can do. See that I added CONFIG_PM_PARTITION_SIZE_MCUBOOT to the project to upscale MCUboot. (This upscaling should fix the flash overflow)
And I use similar configurations for Settings.

And here is the project.

devzone.nordicsemi.com/.../6165.mass_5F00_pm_5F00_dfu_5F00_urd_5F00_2024_2D00_08_2D00_14.zip

Let me know how this works on your side.

[quote user="FinnBiggs"]Welcome back from vacation, I hope it was pleasant![/quote]

Thanks, it was very nice indeed!

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

FinnBiggs — Wed, 14 Aug 2024 00:15:32 GMT

Hi Sigurd,

Welcome back from vacation, I hope it was pleasant!

I've been pushing at this with no luck. As part of trying to get things working, I restructured the project to match the structure from the nrf connect sdk intermediate course lesson on FOTA: (https://github.com/NordicDeveloperAcademy/ncs-inter/tree/main/lesson8/inter_less8_exer3_solution)

My new file tree:

mass_pm_dfu/
┣ .vscode/
┃ ┗ settings.json
┣ boards/
┃ ┣ nrf52840dk_nrf52840.conf
┃ ┣ nrf52840dk_nrf52840.overlay
┃ ┣ xiao_ble_sense.conf
┃ ┗ xiao_ble_sense.overlay
┣ child_image/
┃ ┣ mcuboot.conf
┃ ┣ mcuboot_private.pem
┃ ┣ nrf52840dk_nrf52840.overlay
┃ ┗ xiao_ble_sense.overlay
┣ scripts/
┃ ┣ dk_build.sh
┃ ┗ xiao_build.sh
┣ src/
┃ ┗ main.c
┣ CMakeLists.txt
┣ Kconfig
┣ pm_static.yml
┗ prj.conf

The new build command is really annoying.

The build system will not automatically find the child_image conf file
- I include the following build command
- -Dmcuboot_EXTRA_CONF_FILE="$BASE_DIR/child_image/mcuboot.conf"
Much to my chagrin, the mcuboot_EXTRA_CONF_FILE seems to search at
- C:/ncs/v2.5.0/bootloader/mcuboot/boot/zephyr/
As a fix, I made bash scripts that passes the mcuboot_EXTRA_CONF_FILE with a $(pwd)
- -Dmcuboot_EXTRA_CONF_FILE="$(pwd)/child_image/mcuboot.conf"
My recommendation for building this project is to run:
- cd <PROJECT BASE DIRECTORY>
- ./scripts/dk_build.sh
- ./scripts/xiao_build.sh

Or, direct CLI Build

cd into the project directory and run one of the following depending on build target

# build nrf52840dk_nrf52840
west build \
    --build-dir build_dk \
    . --pristine \
    --board nrf52840dk_nrf52840 \
    --no-sysbuild \
-- \
    -DNCS_TOOLCHAIN_VERSION=NONE \
    -DEXTRA_CONF_FILE=boards/nrf52840dk_nrf52840.conf \
    -DDTC_OVERLAY_FILE=boards/nrf52840dk_nrf52840.overlay \
    -Dmcuboot_EXTRA_CONF_FILE="$(pwd)/child_image/mcuboot.conf"

# build xiao_ble_sense
west build \
    --build-dir build_xiao \
    . --pristine \
    --board xiao_ble_sense \
    --no-sysbuild \
-- \
    -DNCS_TOOLCHAIN_VERSION=NONE \
    -DEXTRA_CONF_FILE=boards/xiao_ble_sense.conf \
    -DDTC_OVERLAY_FILE=boards/xiao_ble_sense.overlay \
    -Dmcuboot_EXTRA_CONF_FILE="$(pwd)/child_image/mcuboot.conf"

I notice no difference in overflow amount when I include/exclude CONFIG_CBPRINTF_NANO=y. Intellisense seems to think that the option is already enabled.

(That seems to be an option already handled in /c/ncs/v2.5.0/bootloader/mcuboot/boot/zephyr/prj.conf)

When I set the CONFIG_CBPRINTF_NANO=n, I get the same amount of overflow as when it's 'y'.

I do however notice a difference in the overflow amount as a result of the restructuring. Now, instead of a 2408B overflow, it's 1560B.

----------------------

Seems like the Nano option isn't the right approach, which brings me to your second suggestion -- change the partitioning to increase mcuboot space.

Is it permitted to separate the MCUBoot partitions? Otherwise, it's not possible to make more space.

The flash_primary partition runs from 0x0000000 to 0x000fffff

Would it be feasible to try moving mcuboot_secondary into external_flash?

Thank you very much, I appreciate your advice.

Best,

- Finn

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Tue, 13 Aug 2024 12:08:57 GMT

Hi Finn,

[quote user=""]the Xiao build overflows by the same exact same amount of space no matter what changes I make.[/quote]

This is probably because MCUboot overflow.

One trick to reduce space in MCUboot is to do this in MCUboot config:

CONFIG_CBPRINTF_NANO=y

That seems to fix the overflow for me, but I get some other errors. I hope that those other erros will not be present on your side. So test this one first.

Alternativley you could change partitioning to increase MCUboot space

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Mon, 12 Aug 2024 13:21:45 GMT

Hi Finn,

I am back from vacation now, and am catching up today.
I will get back to you later this week. Hopefully tomorrow.

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Elfving — Wed, 07 Aug 2024 09:14:26 GMT

Hello Finn,

Just letting you know that Sigurd is currently out of office, but will be back sometime next week. If your problem is urgent and doesn't allow you to wait until then, let me know.

Regards,

Elfving

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

FinnBiggs — Sat, 03 Aug 2024 00:22:43 GMT

Argh!

Sorry to leave you hanging on such a trivial issue -- I had some travel and personal things to take care of.

Here's a follow up. Excluding those (mcuboot conf) files but adding the content I cared about (making sure xiao's external flash was enabled via devicetree) gives the exact same behavior.

Below is the filetree of the project (both builds)

mass_pm_dfu/
┣ configuration/
┃ ┣ common/
┃ ┃ ┗ prj_mcuboot_smp.conf
┃ ┣ nrf52840dk_nrf52840/
┃ ┃ ┣ child_image/
┃ ┃ ┃ ┗ mcuboot/
┃ ┃ ┃   ┣ mcuboot_private.pem
┃ ┃ ┃   ┗ prj_mcuboot_smp.conf
┃ ┃ ┗ nrf52840dk_nrf52840.overlay
┃ ┗ xiao_ble_sense/
┃   ┣ child_image/
┃ ┃ ┃ ┗ mcuboot/
┃ ┃ ┃   ┣ mcuboot_private.pem
┃ ┃ ┃   ┗ prj_mcuboot_smp.conf
┃   ┗ xiao_ble_sense.overlay
┣ notes/
┃ ┣ filetree.md
┃ ┣ Notes.md
┃ ┗ screenshot_pm.png
┣ src/
┃ ┗ main.c
┣ CMakeLists.txt
┣ Kconfig
┣ pm_static.yml
┗ sample.yaml

Both board configurations use /common/prj_mcuboot_smp.conf as their primary configurations
Both boards use pm_static.yml as their partition manager
The /<board>/ subfolder-structures are identical
- the /child_image/mcuboot/mrj_mcuboot_smp.conf are both blank
- the private keys are identical4
The error is exactly the same (ro_data overflows by 2408 bytes)

Are the mcuboot conf files strictly necessary as long as I have all the values that I want?

Anyways, here's a new zip with those changes, and I'll reattach the west build commands to reproduce as well.

NOTE: I've added the west commands (though same command as before) to this zip under /cmds/xiao.sh and cmds/dk.sh

If you have this folder open in your terminal, you can build either one with

./cmds/xiao.sh

./cmds/dk.sh

(Please check that the contents of the bash script match what you expect - I don't want to be your security risk. If you like, just grab the text from those and run it)

Thank you very much

- Finn

devzone.nordicsemi.com/.../mass_5F00_pm_5F00_dfu_5F00_2024_2D00_08_2D00_02.zip

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Thu, 25 Jul 2024 11:47:35 GMT

So let start with something a bit less complex, but which I think is wrong:

Your MCUboot configuration does not seem to be included.

You are missing ";" after "okay" in both of these, but you do not get an error?
That would mean that the file is not included.

To make sure that all your files are included, go through them one by one and add an obvious error + build them. This way, you should see that it crashes once per file, and thus you know that what you expect to be included really has been.

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

FinnBiggs — Tue, 23 Jul 2024 20:50:39 GMT

Hi again Sigurd,

I'm happy to provide a build command. The error you ran into was likely my fault -- I checked to see if I could build from the zip I sent, and it looks like having the build directories included there has some interaction with CMakeCache.txt that prevents a build.

That cache problem can be fixed either by removing all build* directories, or by using the new zip at the end of this file (which is the old zip, but with the builds removed).

For brevity, I'm going to say "dk" in place of "nrf52840dk_nrf52840", and "xiao" instead of "xiao_ble_sense".

My build configuration
- Configuration file (both xiao and dk)
  - ./configuration/common/prj_mcuboot_smp.conf
- Board
  - xiao
    - xiao_ble_sense
  - dk
    - nrf52840dk_nrf52840
- DeviceTree Overlay
  - xiao
    - ./configuration/xiao_ble_sense/xiao_ble_sense.overlay
  - dk
    - ./configuration/nrf52840dk_nrf52840/nrf52840dk_nrf52840.overlay
- Optimization
  - xiao and dk
    - Default is fine
West commands
- xiao
  - west build --build-dir ./build_xiao . --pristine --board xiao_ble_sense --no-sysbuild -- -DNCS_TOOLCHAIN_VERSION=NONE -DCONF_FILE=./configuration/common/prj_mcuboot_smp.conf -DEXTRA_DTC_OVERLAY_FILE=configuration/xiao_ble_sense/xiao_ble_sense.overlay
- dk
  - west build --build-dir ./build_dk . --pristine --board nrf52840dk_nrf52840 --no-sysbuild -- -DNCS_TOOLCHAIN_VERSION=NONE -DCONF_FILE=./configuration/common/prj_mcuboot_smp.conf -DEXTRA_DTC_OVERLAY_FILE=configuration/nrf52840dk_nrf52840/nrf52840dk_nrf52840.overlay

Thank you for all your time.

Best,

- Finn

ATTACHED: mass_pm_dfu.zip (same project as before, but with build directories absent and some unused files deleted)

devzone.nordicsemi.com/.../7587.mass_5F00_pm_5F00_dfu.zip

As an aside, I had to delete and remake this reply. Putting the zip file in the middle of the text block caused a number of bizarre formatting problems that rendered my reply unreadable.

RE: MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

Sigurd Hellesvik — Tue, 23 Jul 2024 12:19:23 GMT

Welcome back!

Great job on the formatting on the ticket! As you say this project is starting to become complicated, so good formatting on the ticket will enable us to help you a loot faster than if not.

I tried to build your project for the xiao baord and the nRF52840DK, but get a different error. So I think I am doing something wrong.
Could you include build instructions, so I know I am getting to the right issue?
I work from the CLI, so a single west command would be preffered, if not too much to ask.

Regards,
Sigurd Hellesvik