Hi, guys!
I’ve started to play around nrf52840 and nrf Connect SDK on MacOS. When I try to copy the uf2 file (blinky example) after I built it in VS Code (and hit Reset 2 times) I receive the following error:
The Finder can’t complete the operation because some data in “zephyr.uf2” can’t be read or written.
(Error code -36)
Similarly, when I do it via the terminal
west flash -r uf2
I receive it like this: OSError: [Errno 5] Input/output error: …
Has anyone faced similar issue before?
Hi there,
So in your build, what did you do for the Softdevice/Bootloader
What offsets did you use?
HTH
GL 
PJ 
FWIW I have a thread on creating the UF2 file so check that too.
Hi, PJ!
Sorry for stupid questions, what do you mean by “what did you do for the Softdevice/Bootloader”?
Let me tell you what I have:
UF2 Bootloader 0.6.1 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-293-gaf8e5a90) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: Seeed XIAO nRF52840
Board-ID: Seeed_XIAO_nRF52840_Sense
SoftDevice: S140 version 7.3.0
Date: Nov 12 2021
Then I’ve installed the nrfConnect SDK following the “extension path from the VS code” given by Nordic. Toolchain, sdk, etc.
When I’ve created an app I’ve added the build configuration and selected the xiao_ble/nrf52840 as my board. Built the blinky example and was trying to upload the generated uf2 to the board.
BTW, the upload also fails with similar error in Windows, so, though there were some upload issues with MacOs (judging on internet), I think this one specifically is not related to the OS.
I’ve also looked into the following file in nrf Connect SDK folder:
/opt/nordic/ncs/v2.9.0/zephyr/boards/seeed/xiao_ble/xiao_ble_defconfig and see the following lines:
# Build UF2 by default, supported by the Adafruit nRF52 Bootloader
CONFIG_BUILD_OUTPUT_UF2=y
CONFIG_USE_DT_CODE_PARTITION=y
these lines are also the part of my prj.conf under the Kconfig section.
Also, when the app is built here is the output:
[6/158] Generating include/generated/zephyr/version.h
-- Zephyr version: 3.7.99 (/opt/nordic/ncs/v2.9.0/zephyr), build: v3.7.99-ncs2
[158/158] Linking C executable zephyr/zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 39312 B 1 MB 3.75%
RAM: 16704 B 256 KB 6.37%
IDT_LIST: 0 GB 32 KB 0.00%
Generating files from /Users/user/nRf/apps/blinky_new/build/blinky_new/zephyr/zephyr.elf for board: xiao_ble
Converted to uf2, output size: 78848, start address: 0x27000
Wrote 78848 bytes to zephyr.uf2
looks like a correct offset?
Important: I’ve found your blinky PWM example in another thread. When I try to upload it via drag and drop or via the west command I have the same error, BUT, the board reboots and the application works! While with the one I’ve built I have both the error and not working program.
So, now I have questions like:
P.S. The Arduino flow works good for me: with the PlatformIO extension of VS Code I can upload arduino code to the board. However, after a non successful upload of UF2 file, the next time I upload Arduino things I need to do by manually put the board into the bootloader. Then any subsequent upload works without the need of the manual bootloader mode. But this is only the “arduino” flow.
P.P.S. As I understood, in order to fully utilize best of the class BLE power consumption and, what is more important, OTA update, the only way is to used the nrf Connect SDK. So, no Arduino libraries are capable of providing me with these capabilites without culprits, correct? That’s why I’ve decided to invest into learning the SDK, and porting my code from Arduino to the SDK. I am planning to stick to C++ still, especially, that the Nordic officials posted on the forum that it is totally legal and is not hard to add the CPP support into the project. I will be missing SPI library on Arduino, but I believe there’s the one in nrf Connect SDK which will do as good. Is my understanding correct, PJ, or am I missing something?
Ok. I’ve found the issue. It is the same as in this thread:
My build configuration contained the Sysbuild option. As soon as I removed it I am able to upload the uf2 file to the board: it still give mes error, but then the application works. Not sure where is the problem with the fact the uploading gives errors, but at least the program runs correctly.
My other P.S. and P.P.S questions are still relevant. It looks like I have to move to MCUBoot bootloader if I want to achieve BLE low energy and DFU BLE with nrf Connect SDK.
If so, is it possible to flash the MCUBoot to Xiao just over the USB?
Hi there,
So there is NO such thing as a Stupid Question when it comes to this Tech, Lot’s to unpack here, But let’s start with an Understanding of the two key questions.
What is a Bootloader and Soft Device present on The Xiao Nrf52840 , What they are and what they do.
The bootloader and SoftDevice are two key components in the firmware architecture of the Xiao nRF52840, and they each serve distinct purposes:
The SoftDevice runs in a designated area of flash memory, and your application (the “user firmware”) interacts with it through a well-defined API. This separation means that while you develop your application, you leverage Nordic’s robust, tested wireless stack without having to build your own from scratch.
These are the BASIC principles, having a good understanding will help navigate the SDK build environment.
Given that understanding, then next is a Pretty standard set of offsets.
When you see an application start address of 0x27000 on a Nordic device like the Xiao nRF52840, it’s telling you that the application firmware is built to reside above the SoftDevice. In a typical Nordic memory layout, the flash is partitioned roughly like this:
Location: The bootloader is typically placed at the very end of the flash memory.
Example Calculation:
The application must fit in the region between the end of the SoftDevice (0x27000) and the beginning of the bootloader (0xE0000 in this example).
Key Points
SoftDevice Region:
From 0x0000 to 0x26FFF (since 0x27000 is the app start).
Its size is determined by the particular SoftDevice version you’re using.
Application Region:
From 0x27000 up to the start of the bootloader.
The linker script for your application must be configured with this start address so that it doesn’t overlap the SoftDevice.
Bootloader Region:
Typically located at the end of flash.
For example, on a 1 MB device with a 128 KB bootloader, the bootloader might be from 0xE0000 to 0xFFFFF.
The actual numbers depend on:
When you build your firmware using the nRF SDK (or another Nordic toolchain), you must supply the correct memory layout via your linker scripts and configuration files. This way, the build “knows” that the SoftDevice is at the bottom of flash, the application starts at 0x27000, and the bootloader occupies a reserved area (typically at the top).
How you built it, and easy to see if you have the programmer , jlink device you can get a visual on the memory Map like this in NRF_connect for Desktops.
disregard some arrows(pic from another thread)
You built this…no softdevice or no bootloader included. = app crash
Both components are integral to the reliability, security, and functionality of the Xiao nRF52840, enabling easy firmware updates and robust wireless connectivity while abstracting the complexity of low-level hardware operations.
HTH
GL PJ
your very close…Keep going and DO ask what ever your not sure about, we can get you squared away.
Once you get the hang of it and a few good builds under your belt it will all make perfect sense.
ALso the West error You get may be a MAC thing, I can’t say 100%
Try the other UF2’s from the “drag and Drop UF2 files” thread on here. Look at both , Nrf and ESP stuff just to know and see the difference and similarities. Are you using DEV board? or jlink device?
GO!
Hi there,
So Next , you made progress
The issue you’re describing with the UF2 file and the “Sysbuild” option in SDK 2.6 is a known quirk. Here’s what’s going on:
In summary:
The problem stems from a configuration detail in SDK 2.6 where the Sysbuild option alters the UF2 image format in a way that conflicts with the bootloader’s expectations on the Xiao. Disabling that option produces an image that, despite minor warnings, loads and runs correctly.
If you’re building with SDK 2.6 for the Xiao, it’s recommended to remove the Sysbuild option when you intend to use UF2 uploads. This workaround has been proven to let the application run correctly even if the upload process reports some errors.
HTH
GL PJ
it’s pain having One foot in NRF_sdk and the other in Arduino IDE LOL. But with All of the changes currently and new developments
the Nrf_SDK is the way to go. IMO. Debugging is a dream, even in PLIO it works, but NOT in Arduino go figure.
FWIW;
Nordic Backs there stuff 100% and updates and improvements are constant, NONE of the others even come close in my experience.
Hey, PJ. Thanks for the answer.
I am already closer to do some real programming: was able to run a CPP on nrf52840 with nrf Connect SDK. Will study the nrf SDK Academy course for sure.
I do not have a J-Link and it looks like a real bummer. To be honest, I’ve expected everything to magically work via the USB, similar to ESP32C3 (at least the serial communication). But then I understand that was an Arduino layer and programming with idf framework, most probably, the J-link is required as well.
I saw you were suggesting getting the nrf DK as a J-link. I don’t want to go for nrf52 DK, to be honest, since the nrf54 is out there already. Hence, a question: if I go nrf54 DK way, will I be efficiently able to still develop with Xiao nrf52840? So, the DK in this set up is just considered as a J-Link, correct? And then, the other advantage is that I am able to use nrf54DK as my next platform, testing my program for, let’s say, future migration to nrf54 chip. Does it sound legitimate? Alternatively there should be some cheap clones or analogs of Segger j-link, for example. Not sure how good are they.
Speaking of SoftDevice: do I understand correctly, that the ncs (nrf Connect SDK) is based on Zephyr and doesn’t use Soft Device? Like it is the latest and greatest thing? And they recommend the MCUboot. As I understand you need to have a J-link in order to flash the firmware with MCUBoot, so no drag&drop anymore. But is it the way to go? To be honest, I got confused on where the DFU BLE supported and where not. But as of today, it is the following in my brain: if you develop with NCS and need DFU BLE - you should go for MCUBoot.
Hi there,
Yes that’s a good observation on the Dev boards I have both just got the Nrf54L15_DK, both For the Jlink on board they work GREAT! with the SWD of Xiao.
Seeed is working on one as well so Hold off on the trigger pull until we see what they are going to release.
I started with the Nrf52840DK and it was the worth it for the Jlink alone, I have a REAL JLink and it was a gift (too expensive IMO) you need a couple adapters as well kinda Clunky but comes with Great software suite for other stuff to, so there’s that. I had a clone a while back , it worked but same situ with connectivity and for Updates I had to use a shoe-horn. 
Ah’ yes MCU boot for the Zephyr world , now your getting into a more pure Nordic dev environment in that direction.
That’s essentially correct. Here’s a breakdown of what that means:
In summary:
That is correct—nRF Connect SDK is indeed based on Zephyr, which means it doesn’t use the legacy SoftDevice but rather a Zephyr-based Bluetooth stack and related middleware. It’s considered a more modern, flexible, and open alternative. Additionally, MCUboot is recommended as the secure bootloader in this new ecosystem.
My order of devices,:
)HTH
GL PJ
MCUboot…
That should be the next Level (SEEED) Leapfrog all the other Suppliers considered the GOLD standard in Bootloaders. (i hope they are listening & reading)
Let’s see anyone else do that…This makes it a key component in ensuring devices remain secure and up‑to‑date.On a Xiao device (like the nRF52840 Xiao), MCUboot serves as the small, secure first stage of code that:
This makes MCUboot an excellent choice for developers aiming to build secure, modern applications on resource‑constrained hardware like the Xiao.
This is the future, OPEN-SOURCE, No gimmicks, No tricks, NO AI… YET!! but seeed engineers & product managers should push HARD the suppliers to meet these basic req’s and VERIFY they do. I feel like speed to get something out gets you burned in the long run when the support just isn’t there for something that requires MUCH of it!
YOU feel me?
but I digress…Espressif, Now SIL (which mind you was a Graphics card Co.) and a couple more less known all try you to get in there camp by claims of openness and compatibility then do a RUG pull. Nordic doesn’t.
as you were…
GL PJ
Hey, PJ! Thanks a lot for the summary.
Still some more questions which are not obvious and you may help me navigate:
Do you mean they are working on a Dev Kit, which should include a J-Link feature?
I saw it in the Internet, but wasn’t able to understand a use case for it. It is an NRF board in a format of a USB stick, correct? Basically, similar to XIAO if it was in the same form-factor, correct?
On the MCUBoot: can it be flashed via XIAO USB? And when it is MCUBoot on the Xiao - can the updates be flashed via USB or once switched the J-Link is my only way to flash the device?
On the SoftDevice vs Zephyr. Is BLE API or Nordic has an API/Facade, which hides either SoftDevice or Zephyr actual implementation? What I mean is, if I start my development with Xiao’s current bootloader with SoftDevice, is it the same code I have when switching to Zephyr BLE stack or will I need to migrate? I really hope that the implementation is behind the same API, but you are never sure. Just to understand, will I be wasting time doing the BLE functionality on SoftDevice now, while eventually targeting the Zephyr.
Hi there,
So Yes, to the first Q’ They are working on one, No other info though at this time 
The second Q, Nrf_dongle. ($9) It is a USB dongle that is programmable. It is used as a BLE endpoint for the computer It can be configured to Scan BLE advertisements and connect to the Xiao running Central or Peripheral code, connected with wire shark it can be a BLE sniffer for Radio testing (transmit power, etc)
here is a thread talking about it also.
Seeed XIAO BLE Sense nRF52840 deep-sleep mode - #21 by Vint1k
The Xiao comes preloaded with the Adafruit UF2 bootloader, which is designed primarily for drag‐and‐drop updates of the application firmware over USB. In this mode, when you double‐press the reset button, the board enters DFU/UF2 mode and appears as a USB drive, allowing you to copy a UF2 file to update your app.
When it comes to updating or replacing the bootloader itself (for example, switching it out for MCUboot), things get a bit more complicated:
The Adafruit bootloader on the Xiao is designed for application updates over USB and does not natively support updating (or replacing) itself with MCUboot over the USB DFU mode that presents a drive in Windows File Explorer. It would be the right thing to allow but Adafruit doesn’t want that! so much for openness, To flash MCUboot onto the Xiao, you need to use an external programmer or a specialized DFU procedure that’s not part of the standard user experience.
HTH
GL PJ
And the Nordic DK can work as such a tool, right? So, I can flash anything I want with it: MCUBoot, then revert to Adafruit bootlader if I want to, and if I brick the board I can always reflash it with such a device, right? And everything via the J-link interface?
Hi there,
Yes,
Using the nRF52840DK makes this process straightforward since you can reliably program and recover your device via SWD. Just be cautious with the memory layout and always have a recovery method in case the new bootloader doesn’t work as expected.
GL PJ
Hi, PJ!
Thanks a lot for the instructions. As you have both nrf52DK and nrf54DK, if I go the DK way, would you recommend the nrf54DK? As far as I understand with nrf54DK I still can program nrf52 on XIAO, and in the same time use nrf54DK standalone as an nrf54 board, right? Or are there any restrictions with NCS and the DK board itself which limits the capability to that specific chip they have on board of DK only?
Hi there,
So you can use it to program the Nrf52840 of course or any
JLink ↔ SWD device compatible MCU. The nRF54 can emulate the other 54 series, but not the nrf52 series and While the onboard J-Link (or SEGGER debugger) might technically be capable of programming different Nordic chips, it’s not officially supported to develop nRF52 series code using an nRF54 DK. You’d likely run into issues with the board’s specific memory layout, clock configurations, and peripheral differences.
So, although the underlying Nordic SDK can target multiple chips, the DK you use should match the SoC family you intend to develop for.
HTH
GL PJ
Thanks for explanation, makes perfect sense.
But is it possible in this situation to use nrf54 DK only as a J-Link to program for Xiao nrf52840? Or when DK is connected to the PC it takes over and “fools” the VSCode being the “main” board to program? Because for a non-DK board, as I understand, NCS provides all the dev/debug feauters via J-link. Sorry, I feel like you have answered this question already, but I just didn’t get it
Hi there,
Yes, no worries I’m sure other’s would like to know. Yes you can use it just as J-Link device. Look at the Threads with the screen shots, I’ve posted Use the search and you can see it shows up in Nrf_connect for Desktop as the programmer also. It uses J-Link Commander Version V7.94E, also notice it pops up a Drive in the explorer representing the devices Flash.
HTH
GL PJ
Hi, PJ!
A side thought. I was thinking, like, if nrf52 is good enough for the development and the final product, do you need to go for an nrf54 even, since the latter has a second core which may be an overkill for the project. And while the power consumption became better for ~20%, even nrf52 power consumption is excellently good for lots of the projects.
However, a totally economical factor: NRF54 DK is 20% cheaper, than the nfr52 DK, and the “raw” nrf54 chip is 3$ vs 4$ of nrf52840 chip. Which means, that it is cheaper to run the project on the latest chip. Like no brainer, right? Am I missing anything?
Hi there,
Yes, so I went to the drawer and found I have all three, Nrf52DK, Nrf53DK and the just opened Nrf54DK. I use the Nrf52DK mainly, At one time I thought Seeed would do a Nrf5340 but they didn’t SO, The Nrf54DK is for future dev work. 
There is so much info on the Nrf52DK i think it’s very worth the investment and You still get the J-Link as a bonus.
HTH
GL PJ
So, I read it as a recommendation to play safe and work with a 4 year old but very documented DK / chip.
