Can you tell me more about the debugger and if that’s something I can run myself? Do I need extra hardware? I appreciate the offer, but it’s not enough for me to fix just the current issue and move on, I need to be able to debug future instances of this issue myself.
You can buy or “create” a simple JTAG/SWD debug tool for some of the ARM based XIAO products, eg SAMD21, NRF52840, MG24, even the RP2040.
Since you already have a SAMD21 you could essentially create a CMSIS-DAP programmer/debugger using that. We discussed it in this post. You can also use an RPi Pico.
Debugging can be done from VSCode or if you have an official programmer from them, Segger’s Ozone (I use this option).
Alternatively purchase an “official” device from your local supplier… More expensive though. There are low cost JTAG/SWD “third party” devices but I don’t use those.
Regarding firmware debugging here. I agree you should be able to find the solution yourself. The offer was to give you another alternative.
This is a tool I created when I ran into trouble after losing the SAMD21 bootloader. I’m not sure if it matches your current problem exactly, but I think it might be helpful.
I’ve been asking a lot of questions across various forums. It’s possible that the answers are full of selection bias (those who continue using the chips like them), but it seems like there are two groups.
- Chips whose bootloaders are corruptable with user code. The users are accustomed to repairing them or accept that as part of the process. My understanding is that SAMD21 and nRF52840 fall into this category.
- Chips whose bootloaders are very difficult to corrupt with user code. Seems like RP2040, ESP32, and ATmega are in this group.
Am I getting this correctly? If so, it’s hard for me to imagine why anyone would tolerate the first kind if the second kind exists. I’ve seen chips across both groups that offer comparable specs at similar price points. I’m not trying to squeeze every last op out of these boards, I just want to flash lights and use sensors, but I certainly I don’t want to get distracted by repair bootloaders.
Respect to anyone who feels differently than me about this, that’s fine, I just don’t want to be full-time debugging microprocessors. My microprocessor usage is in service of woodworking and other maker-type projects, I don’t want to get that deep into this and am trying to figure out what hardware I need to walk that line.
Finally, regarding the SAMD21: If you use the tool linked above to configure BOOTPROT, I don’t think the bootloader will be overwritten anymore. I believe the problem arose because it wasn’t protected by default when the device left the factory. (Adafruit’s SAMD21 is protected by default.)
Not all bootloaders are the same…
For example, with the Silicon Labs Gecko bootloader there are a few different types. Each has a different “application”. For example.
- Standalone (XModem flash over serial),
- Application - Internal (in system programming + OTA),
- Application - External (SPI external flash + OTA),
- OTA-DFU for BLE using a mobile phone etc…
Different devices have different memory size and structure. I use an OTA Internal on the XIAO MG24. Since MG24 doesn’t support native USB, XIAO added a SAMD11 as an OpenOCD SWD programming/debugging + Serial port (virtual com port)…
Hi there Chet,
Stick with it! the boys got you the right anaswers here… 
There’s definitely a small learning curve upfront, but the payoff in hardware capability, low-power performance, and flexibility down the road is huge once you get past this initial hump.
If you just want to focus on your woodworking and maker projects without the headache of constantly recovering bricked boards, a few quick tips to make life much easier starting out:
-
Start with the standard Arduino / Adafruit BSPs: They are much more beginner-friendly, come with built-in bootloader protection (like
BOOTPROTon SAMD21), and are generally far less prone to getting corrupted by user code glitches. -
Use dedicated flashing tools when needed: Having a cheap DAPLink or CMSIS-DAP debugger on hand takes 90% of the anxiety out of working with these chips—if anything ever locks up, a single click restores it without needing to debug memory registers.
-
Keep an RP2040 or ESP32 around for fast prototyping: If a project doesn’t strictly require ultra-low power BLE or specific SAMD features, starting on an RP2040 or ESP32-C3 lets you focus purely on the code and mechanics, then you can migrate to nRF/SAMD hardware once the logic is solid.
Don’t let the bootloader rabbit hole discourage you—once you find the BSP/workflow setup that works reliably for you, these boards are absolute workhorses!
HTH
GL 
PJ 