Hi there,
No real harsh impact, Better to build with SYSbuild anyway, less to deal with Especially if you plan on using the BLE OTA. and it’s only in the Preview, 2.8.0 and 2.9.0 you can build what you want.
things like the MCU Boot being a child of the APP now it’s all the same. no a big deal. You used to have to build them separately , then together now , all prebuilt ,pre-linked-and added in the bootloader then all partitioned in place. Allows way more options on DFU. 
HTH
GL 
PJ 
DO those DEV academy lessons to get a good handle on it, Also if you’re Switching to a better BOOTLOADER (MCUBoot) this is the ONLY way to GO! IMO. YMMV
The key is the BootLoader (so many options)
Yes a double press of the Reset button Still works… to trigger BL Mode! 
1 Like
Hi folks! I’m in a similar situation.
For background, I’m doing some experimentation Matter over thread thread. I’ve experimented with the following XIAO boards:
- MG24
- nrf52840
- ESP32-C6
I would have made a new thread to discuss this, but I’m new.
I started with Arduino, but it had some significant limitations with Matter/Thread development, so I switched to the manufacturer development toolchains. After doing some experimentation, the Nordic chips seem like a better fit because of lower power consumption and an easier to use toolchain (I think).
Back to this topic… I’ve been struggling with updating the code on the nrf52840. I’m running VS code and NRF connect (latest production releases available as of now).
I was running the stock boot loader, but compiled code wouldn’t run. I upgraded the boot loader to the latest available (0.9.2). The code compiled will run (tried the blinky example) if manually uploaded. Prior to updating it, flashing it with west or manually with a file copy, failed.
Now, when running “west flash -r uf2”, I get the following warning/error:
WARNING: runners.uf2: Discovered UF2 partitions don't match Board-ID 'Seeed_XIAO_nRF52840_Sense'
FATAL ERROR: No matching UF2 partitions found
If I downgrade it, it doesn’t revert it back to the previous state. Also, the volume name before was “XIAO-SENSE” and now it’s “XIAO-BOOT”. Also, when uploading a new UF2 image, the drive unmounts automatically. It did this before and after the bootloader update. I only mention this because it makes the OS that has the volume mounted throw errors.
- Any ideas how I can overcome this issue I’m encountering with west for uploading new images?
- I’m trying to get the tools set up to allow for easier iteration. If there any documentation you can recommendation to get this set up easier with the XIAO BLE?. It seems that it’s much simpler with SOC development kits, but things get more complicated when you venture outside of their hardware.
- Is an investment in something like a Jlink EDU Mini going to make this less painful?
- Is there any training documentation/videos you recommend? While I’ve done some basic hardware development before and software development, I’m new to this world and the learning curve is steep.
Hi there,
And welcome Here…
So not unusual at all… The Xiao has different partition requirements, due to external flash and the mapping. You made or arrived at the RIGHT choice However congrats to that first step. The Nordic hardware is Solid and the Software even more so, Industry leader in Low Power and BLE connectivity. With all that being said it still requires a dedicated effort (3hrs) to learn the process required to get the best results. Watch all of the dev academy FREE webinars, throw some coin at the DEV kit Nrf52849DK it includes the built in J-LINK as a bonus that can be used as external Probe for Xiao.
Read the threads on here about Creating a Drag & Drop testing file (uF2) , making a production bin file and more. The Nrf Dongle is also a $9 BLE (programable) dongle that works with all of the NRF_desktops software suite. Can also be used as a BLE sniffer with Wire_shark. Just install the last toolChain and if you have a issue roll it back to the previous one and that should get you over the hump. Once you setup the Build environment and get a few builds under your belt then the Bootloader is less problematic. Understanding the Partition manager and how the Kconfig work is essential for bootloader extra.
Sounds like you are close, but hit those Webinars, no.7 or 8 talks about the Bootloader MCUBoot.
HTH
GL PJ
Hi and welcome
There are “experts” on the Nordic parts that can certainly help.
If you need any assistance with Matter (over Thread) on the XIAO MG24 (Arduino or non-Arduino, Simplicity Studio or VSCode) let me know.
No need for flash programmers like JLink etc. Programming/Debugging is built in to the XIAO MG24! Takes a few minutes to build, flash and debug a Matter Light (for example) on the XIAO MG24.
Just out of interest. What “limitations” are you facing with the Arduino/Matter development?
Thanks for the follow-up!
I would have preferred to keep it simple and just use Arduino. As you mentioned, Matter with Arduino on the MG24 is actually quite simple. There’s a chance I may be incorrect in my findings, so let me know if you find any issues.
My hope is to make a long idle time sleepy end device. I also want to have multiple matter device types combined into a single endpoint. I also want to be able to track battery power level because this device will have a LiPoly battery and a solar charger. Specifically, it looks like you have to use ZAP to build a custom matter file in order to do some of this. I have a few devices I want to make that have similar requirements.
I assumed that the MG24 would be the ideal option considering Silicon Labs seems very active in Matter development and I noticed a number of Matter products in the market use their SOCs. That being said, I really dislike Simplicity Studio. In an attempt to simplify development with GUIs, they create tons of complexity in the actual source code.
1 Like
Thanks, PJ. I’ll check out the webinars.
Would you recommend going with the dev kit over a separate J-Link device. I eventually want to upgrade to the Nrf54-series when it becomes available in a smaller form factor device.
HI there,
Yes, the J-link is built in in the dev kit board, check out the post I have on this topic with some pictures and connections. Yes the DK board allows ALL of the examples to work and provides a better experience than Raw dogging it 
with the discrete probe. Plus the added benefits of the NRF_desktop apps too.
HTH
GL PJ
Thanks for the reply and additional information. Sounds like an interesting project! Happy coding
Grobasoz,
Again, sorry for commingling topics. I can’t post a new one yet. Considering you offered, I figured I’d ask another question.
I might go back and give the MG24 another chance at some point. One of the things I struggled with is that I could never get it to work with Simplicity Studio. After figuring out there was a GitLFS bug in SS, I was able to get a project compiled, but couldn’t load anything on the XIAO MG24. Do you have any tips or documentation? The device worked fine with the Arduino IDE, so I know that it’s functional.
No worries.
What OS you using Win, Mac, or Linux? I’ve been concentrating on Win to save me time, but apparently all can be achieved on other OS’s.
I think the gitlfs issue was resolved at some stage earlier in the year (or version).
Also I suggest using the latest SDK SiSDK 2024.12.2 - makes life easier when helping with code.
Anyway some steps…
- Create and build your project in Simplicity Studio first.
- Then set 'Studio project up for use with VSCode.
- Open VSCode and set up the appropriate VSCode stuff.
- Then build and flash/debug accordingly.
Obviously there’s a little more “detail” involved but that’s the gist of it.
I’m busy with trying to get Simplicity Studio working with the XIAO MG24 to debug in Studio but have other work to get done first.
I’m using an ARM-based Mac. I was using the latest SDK available. I got around the GitLFS issue after a lot of digging and frustrating ambiguous compile failures. My biggest issue was getting code on the XIAO MG24. All the documentation I could find was focused on the dev kits.
Ok - Not sure if I can really help you with Arm based Mac. My Mac is x86 based.
I could try changing my Win batch files to shell scripts and test on my Mac anyway.
If you can run and debug Arduino code on the XIAO MG24 then you should be able to do the same for Simplicity Studio projects.
@pshanesmith - I have confirmed that an app created with Simplicity Studio can be used within VS Code on my x86 Mac.
As mentioned if you can get the Arduino code working on the Arm based Mac then you should be able to use the VS Code based approach as well.
I’ll send some information and my shell scripts to my XIAO_MG24 github repository when I get some spare time. (Since you’re using the NRF for now I suspect there’s no rush).
Hi, where can we find this 0.9.2 bootloader for BLE Sense?
Hi PJ. Any whay to move from the Adafruit bootloader to MCUBOOT without the need of external programmer?
Well, it doesn’t look like I can post links like a big kid yet on this forum. Fortunately, @cobra posted the URL back in Dec, 14 2024 in this thread. It’s in an Adafruit GitHub repo. Let me know if you can’t find it.
Hi there,
Why Yes, Yes indeed… However it’s “Hotel California” situation without one.
If you are a YOLO type then by all means…
All messing aside You can do a one time Drag and drop of a properly built UF2 file Yes, but only if the board allows direct firmware flashing via USB (UF2 or serial), and if you’re okay with losing the Adafruit bootloader — because once you overwrite it, it’s gone unless you reflash it using a debug probe (SWD).
If You Don’t Have an External Programmer:
You can still move to MCUboot if:
- You have a .hex or .bin build of MCUboot (Zephyr-based or nRF Connect SDK-based)
- Your board is in Adafruit bootloader mode (shows up as a USB mass storage)
- You’re willing to overwrite the Adafruit bootloader
Then you can:
Option 1: Flash via bossac or nrfutil dfu
(If the bootloader supports DFU updates)
Option 2: Convert to UF2 Format
Use uf2conv.py to convert your MCUboot image into a .uf2 file:
python uf2conv.py build/zephyr/zephyr.hex -c -o mcuboot.uf2
Then just drag and drop the UF2 onto the board’s drive in bootloader mode.
This replaces the Adafruit bootloader, and without SWD you cannot restore it unless MCUboot provides DFU update support afterward.
Important Caveats:
- Adafruit’s UF2 bootloader supports drag-and-drop because it’s there. MCUboot doesn’t (unless you implement USB DFU).
- Once replaced, you’ll need to flash future firmware updates using MCUboot-compatible update methods, like:
- Serial DFU
- USB DFU (if implemented)
- OTA (if implemented)
Recommended Migration Path:
If you want to use MCUboot and still keep the drag-and-drop experience:
- Keep the Adafruit bootloader
2. Chainload MCUboot as a secondary bootloader
- Adafruit bootloader loads an app which then jumps into MCUboot
- But this is complex and not widely documented
If You Do Have a Debugger (J-Link, ST-Link, or CMSIS-DAP):
You can safely:
- Back up the Adafruit bootloader (
nrfjprog --readcode)
- Flash MCUboot
- Restore the bootloader later if needed
HTH
GL PJ
Can I update the bootloader through UF2?
Like uf2conv xiao_nrf52840_ble_sense_bootloader-0.9.2_s140_7.3.0.hex ?
I’m trying to run sysbuild with sysbuild enabled for the Xiao BLE Sense without the need of a SWD.
Hi there,
Short answer: Yes, but only if the current bootloader supports UF2 flashing of bootloader regions — and many don’t.
1. Current UF2 Bootloader Limitations
The Adafruit-style UF2 bootloader typically protects the bootloader region, meaning it does not allow flashing a new bootloader .hex or .bin over UF2 unless it’s specifically modified to allow it (dangerous by default).
So: In your case no
- If your Xiao nRF52840 already has a UF2 bootloader, it can update the application firmware via UF2, but not the bootloader itself — unless it was built with write access to that region (not common).
- You’d still need SWD access (J-Link or CMSIS-DAP) to initially flash MCUboot or any new bootloader safely.
FYI, If you’re looking to transition to MCUboot and want OTA or serial DFU afterward:
- Use Adafruit UF2 to flash a combined MCUboot + App image if you already have MCUboot present — but again, only app updates, not bootloader.
- If MCUboot is not already installed, then you’ll need SWD at least once to get it onto the device.
Important Notes for Xiao BLE Sense:
-
Seeed’s UF2 bootloader (if present) may differ from Adafruit’s. Some versions allow flashing a new SoftDevice + App, but not bootloader itself.
-
uf2conv will convert a .hex into a .uf2 file, but flashing it doesn’t mean it will overwrite protected areas. 
-
If you’re using the nRF Connect SDK (Zephyr) and sysbuild, you must install MCUboot via SWD the first time.
-
After that, you can use:
-
Serial DFU (mcumgr)
-
BLE DFU
-
Or package .bin updates as .uf2 if supported.
No, you cannot safely update the bootloader on the Xiao BLE Sense via UF2 unless the current bootloader was built to allow bootloader flashing — which is very rare and risky. Use SWD once to install MCUboot, then you can forget about SWD forever.
HTH
GL PJ
Hi, I was able to do adafruit bootloader + mcuboot and perform BLE FOTA on the Xiao BLE Sense.
I had to add pm_static.yml fixing all the partitions. I keep the adafruit bootloader and softdevices regions untouched for compatbility and had to trim mcuboot to fit in 48kB.
beacon_dfu.zip (29.3 KB)
I used SWD to flash, but I’ll test using uf2 also.
I’m preparing some Zephyr Lessons where students will use the Xiao BLE Sense, so that´s why i’m looking for a way to add BLE DFU over the original bootloader without the need of extra hardware for SWD.
Somewhere in the process I screwed my reset button. Nothing happens when I click or double click it. I wonder if it was heat damage when soldering pins for the SWD or some config I messed up. Even reflashing the dump I did in the beginning won´t fix it, so I’m considering hardware issue.
I just ordered a new Xiao and will test sending the mcuboot + app using uf2 when possible.
Oh, I had to use non-sysbuild. Still wondering how to sysbuild whithout the need of SWD at all…
