MCUBoot, ExFat USB Filesystem, and Flash Region Overflows.

[FinnBiggs]

Hello again folks,

Recently, I closed a ticket regarding MCUBoot, DFU, and the USB Mass Filesystem. Unfortunately, I'm still having problems. That ticket, for the curious, is here:  MCUBoot DFU Interference with ExFat Filesystem In that ticket, the problem ended up being to do with the method of adding an affiliation tag to my external storage partition.

When that was resolved, I closed the ticket. However, I'm still stuck in trying to get DFU Enabled alongside a USB Filesystem. Not on the DevKit, where it's working, but in the transfer from devKit to my production board.

As always, here are the details of my environment.

Nordic SDK v2.5.0

Hardware: (working) nRF52840dk

Hardware: (faulting) Xiao BLE Sense

Now, I'll describe the problem.

I have developed an application based on a few different nordic samples. In particular, I am using the usb/mass sample for my filesystem (configured as an ExFat, not littlefs system). I am also using pieces of the LBS sample, and nRF Desktop to enable OTA DFU that preserves my filesystem.

This application compiles, runs, and performs DFU OTA on my nRF52840dk. My current application (if anyone wants it as a sample) is built on top of this one, which was the resolution of my last ticket. https://github.com/FinnWBiggs/mass_pm

From there, I've added child_image subdirectories, and changed my partition manager tool from CONFIG_PM_SINGLE_IMAGE to CONFIG_BOOTLOADER_MCUBOOT, which does add a layer of complexity.

Additionally, I've enabled the options used in nRF Desktop for DFU by following the options implied by those options and including them in my prj.conf

All together, this makes for a complicated app. Regardless, it runs well on the dev kit, and updates the firmware while preserving our filesystem.

The complication arises when building for Xiao BLE sense. Despite sharing a common prj.conf (actually a prj_mcuboot_smp.conf), and having identical structures for the creation of the child image, the Xiao build overflows by the same exact same amount of space no matter what changes I make.

Rather than attaching a git repository, I will attach a zip file of this project so that it can't disappear in the future. (As an aside, what is the preferred method of attaching a lot of information to these help forum posts? Git / Zip / In-text code blocks?)

In this attached zip is a Notes.md, which details a large portion of the changes I've made and the effects those changes have had.

The ones I will call out here to keep folks from having to dig in:

• Adding a chosen nordic,pm-ext-flash to the xiao build (using the &p2516h), the occupied flash size of a compiled test application with no DFU.
• The pm_static.yml that is shared by both xiao_ble_sense and nrf52840dk_nrf52840 provides:
  • a primary and secondary mcuboot partition of 488kB (size = 0x7a000)
  • which yields (allotting for the mcuboot pad) an app and mcuboot_primary_app partition size of 0x79e00
• The changes made to the pm_static.yml that differ from the default partitioning are as follows:
  • Before: 1MB 52840 flash divided as:
    • 
    • (And please ignore arbitrary_partition, I was using it for other tests and it got left in while I was taking notes)
  • After: 1MB 52840 flash divided as:
    
    • 
    • Notable changes:
      • settings storage moved from primary->external flash
      • mcuboot primary and secondary expanded by half of the size of settings_storage
      • app increased by half size of settings_storage
      • address of mcuboot_secondary shifted to match new endpoint of app and mcuboot_primary
• The size of my compiled application is significantly smaller than my app partition (which is fine, but important to note regarding the overflow on the other board)
  • The compiled application size for nrf52840 is 378216B (378.2 kB), which is placed in a partition of size 487.5 kB.
• I can't validate the compiled size of the application for the xiao_ble_sense, since the application will not compile and always fails in the same way.

  • c:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr_pre0.elf section `rodata' will not fit in region `FLASH'
    c:/ncs/toolchains/c57af46cb7/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `FLASH' overflowed by 2408 bytes

• Changing the compiler optimizations does not change the amount by which the flash overflows.
  • All of Debug, Speed, and Size optimizations overflow by 2408B (2.4 kB), which is significantly less than the ~100kB I had spare in my build for nrf52840dk

I would be very grateful for advice on how to proceed. Thank you very much in advance for your time.

All the best,

   -  Finn

ATTACHED FILE: mass_pm_dfu.zip (zip of relevant project directory, including my builds).

mass_pm_dfu_TOSHARE.zip

[Sigurd Hellesvik]

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

[FinnBiggs]

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)

7587.mass_pm_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.

[Sigurd Hellesvik]

Hi Finn,

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

[Sigurd Hellesvik]

Hi Finn,

the Xiao build overflows by the same exact same amount of space no matter what changes I make.

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

[FinnBiggs]

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

[Sigurd Hellesvik]

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:

FinnBiggs said:

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

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

FinnBiggs said:

The build system will not automatically find the child_image conf file

It should. See my project.

FinnBiggs said:

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

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

FinnBiggs said:

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.

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.

FinnBiggs said:

Would it be feasible to try moving mcuboot_secondary into external_flash?

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:

FinnBiggs said:

mass_pm_dfu_2024-08-02.zip

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.

6165.mass_pm_dfu_urd_2024-08-14.zip

Let me know how this works on your  side.

FinnBiggs said:

Welcome back from vacation, I hope it was pleasant!

Thanks, it was very nice indeed!

[FinnBiggs]

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)!

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

Sigurd Hellesvik said:

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.

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

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

Sigurd Hellesvik said:

Then I removed most things from pm_static.yml.

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

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

Sigurd Hellesvik said:

Let me know how this works on your  side.

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

mass_pm_dfu_finn_2024-08-14.zip

[Sigurd Hellesvik]

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

[Sigurd Hellesvik]

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.

mass_pm_dfu_urd_2024-08-19.zip

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

[FinnBiggs]

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.

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

Sigurd Hellesvik said:

So if I missed any questions about theory, please let me know and I will explain.

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

[Sigurd Hellesvik]

FinnBiggs said:

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

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.

FinnBiggs said:

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

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:

1. Verify that MCUboot is the error
   1. Build without and with MCUboot. Does it work without?
2. 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.
3. 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.
4. 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:

FinnBiggs said:

a JLink probe to recover back into its bootloader mode.

What is the "bootloader mode" here?

FinnBiggs said:

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?

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!