Unable to flash Breezedude boards – tried multiple setups (J-Link EDU Mini, Raspberry Pi)

[mhofner21]

Hi Florian,

thanks for making the Breezedude project available to the community.

We’ve been trying to flash the microcontroller, but unfortunately without success so far. Here's a quick summary of what we've tried:

• We had several Breezedude boards produced by JLCPCB.
• I generated the Gerber files myself from the provided KiCad project, using a KiCad fabrication plugin (with default settings).
• We're using a J-Link EDU Mini for flashing, as described in the documentation.
• Unfortunately, none of the boards could be flashed – the process fails every time, and the tool doesn't seem to recognize the chip.
• As an alternative, we also tried flashing via SWD using a Raspberry Pi – same result.

We've double-checked connections, pin assignments, and voltages – everything seems to match what's documented. Could there be an issue with the current board version or with the way the KiCad files were exported? Or are we possibly missing something obvious?

If it helps, I'm happy to send you one or two of the boards by mail (via Deutsche Post) so you can take a look yourself.

I've also attached the Gerber files we used for fabrication, in case you'd like to take a quick look.
Order-JLCPCB.zip

I understand that you can’t provide support for everything you’ve generously made available as open source – but I’d really appreciate any hints or guidance you might be able to share.

Best regards
Matthias

[thezenox]

Hi Matthias
I quickly checked the images of the gerber file, seems ok, some orientations are wrong in the picture but JLC fixes that normally. All Designs in this repo should work and your Gerber generation process seems fine.

For SWD flashing only SWD and power should matter. Could you double check:

• actual orientration of the SAMD21 on the board
• conductivity of the SWD pads to the IC pins
• 3.3V on all power pins of the SAMD21

Can you test the programmer (maybe even with the same wiring harness) on a different device?
Also check for ground loops or too long wires, I once had problems with that (I use 10cm wire on the programmer)
How do you power the board during programming?

[mhofner21]

Hi Florian,

thanks so much for your quick response and the helpful checklist!

Here’s where I’m at – this is what I’ve checked or tried so far:

---

Orientation of the SAMD21

Looks correct to me. I’ve attached a photo of the assembled boards just to be sure – maybe something stands out to you that I’ve missed.

SWD pad conductivity

I checked with a multimeter – both SWDIO and SWCLK are cleanly connected to the corresponding chip pins.

3.3 V on all VDD pins

Measured several times with a multimeter – everything looks good.

Programmer test on a known-good board

Unfortunately, I haven’t yet tested the J-Link on a known working SAMD21 board.
To be honest, I’m still quite new to this whole area.
That said, we’ve used the Raspberry Pi flasher to successfully flash other boards before, so that part seems to work.

Cable length / ground loops

I’m using a pre-assembled ribbon cable. Shortening it would mean destroying it, so I’d prefer to try that only as a last resort.
But your tip is definitely noted!

Power during flashing

I’ve tried both a lab power supply and a battery – both provide stable 3.3 V, but there was no change in behavior.

---

Additional observations

• We set up a Raspberry Pi to flash the Breezedude bootloader → this throws an error during flashing.
• Then we tried the original Adafruit bootloader on the same board → no errors during flashing.
• However: The board shows no response via USB after either attempt → no LED blinking, no device recognition.

So in summary:

• Breezedude bootloader → Flashing error
• Adafruit bootloader → Flashing OK, but board remains unresponsive

---

Current theories

• The fuses might not be correctly set – Maybe we’ll try explicitly setting them to internal clock.
• Two capacitors in the Breezedude design have different values compared to the Adafruit reference layout.

---

JLCPCB production note

When placing the PCBA order, I did not select the option for manual review of part placement and polarity.
So if there was a misalignment or rotation issue in the position files, it may have gone into production uncorrected.

---

This whole project has been a big learning curve for me – especially microcontroller programming and hardware debugging.
I’m still new to a lot of this, but thankfully I’m getting help from experienced folks in our local paragliding club.

If you spot anything in the photo or have any other ideas, I’d be super thankful for any tips or suggestions!

Thanks again for your time and support – I really appreciate it! 🙏

Best regards
Matthias

[thezenox]

I did not change any fuse values. As a reference the values of a working one.

Can you attach a picture of the programming setup/wires? I once had the same issue with some bootloader flashing and some giving errors, I think it was a connection issue of some wire.

Here is a full flash dump of a programmed one, you can try flashing this (bootloader + firmware + config)
working_06_12.zip

JLC will check parts orientation anyway, at least when there are errors of parts not matching the pads. But your boards look fine.

I tested open-ocd flashing and added it to the wiki. You can maybe get (or build) a cheap CMSIS-DAP programmer and try with this.

If this does not help, you can send me some boards, but I am 90% sure I can program them.

[mhofner21]

Hey Florian,

Following your additional explanation in the wiki, I was able to get it working: I could flash the boards via OpenOCD and the DAPLink Mini Debugger. The boards respond as described, the blue LED pulses, and via USB they are initially recognized on my Mac as BreezeBOOT.

I then copied the release version to the board. Once the copy process finished, the board rebooted and now shows up on my Mac as a Breezedude USB drive in FAT12.

Here, however, I run into the next challenge: In your guide, you mention that the initial settings.txt file must be copied to the root of the Breezedude. I cannot copy anything to this drive because it is readonly – the drive is completely empty.

I can open the configuration page in Chrome and connect to the Breezedude via the Web Serial Viewer. When I press Reset, I get the following output:

--------------- RESET -------------------
Version: 0.5
FW Build Time: Jun 12 2025 07:04:06
File not exists
Coordinates invalid
Found LoRa LLCC68
Detected HW2.x

########
Wakeup: 14808
Wakeup_source: NONE
V_Bat: 4.11

Failed to obtain settings from file. Trying again
File not exists
Coordinates invalid

It seems the settings.txt file is missing, and I’m not sure how to get it initially onto the Breezedude.

I also tried going one step back: I flashed the update-bootloader-breezedude-v3.16.0-19-g4365018.uf2 in boot mode, then copied the settings via BreezeBOOT (here the drive was not readonly), and then copied the release version again. The result was the same – the settings file is still missing.

I also attempted to flash the HEX file, but I couldn’t get it installed. It seems too large for the flash, but it’s possible I made a mistake here as well.

How should I proceed to ensure the initial settings.txt is correctly created? I also cannot load it as a configuration because the root directory is empty.

Thanks a lot for your help!

Best regards,
Matthias

[mhofner21]

Hi @thezenox
I hope you’re doing well 😊
Just wanted to follow up on my question regarding the Breezedude (issue with the readonly drive and missing settings.txt). Do you have any suggestion on how I could solve this?

If you’re short on time, even a quick hint about the right direction to look into would already help me a lot.

Thanks so much in advance!
Best,
Matthias

[thezenox]

Hi Matthias,
sorry, I totally missed your reply a few weeks ago.
Copying on Breezedude (not BreezeBoot) is the right way to do.
I do not have a Mac to test, I only tested on Ubuntu, Windows and Android.
You can try formatting the "flash drive" or verifying/repairing it with diskutil.
Did you try it on a different computer?
If none of this helps, I need to investigate on that. Android also complains on the FAT12 formated by the Breezedude itself, but I couldn't find the reason yet.

[mhofner21]

Hi @thezenox,
turns out it was actually quite simple in the end... 🙂

When flashing the firmware on macOS, the Breezedude seems to get formatted in a way that makes it unreadable – even when for Windows afterwards.
But if you start it in bootloader mode and flash the firmware again from there (under Windows), the Breezedude comes up writable afterwards. At that point it’s possible to copy the settings.txt onto it just as you described.

After that, configuration via the Configurator worked without issues.
Let’s see what I stumble across next! 😉

Thanks again for your help!

Best,
Matthias

[thezenox]

Good to hear that its working now, but the behavior sounds wierd. As FAT12 has no "dirty bit" or similar, the file system should always be the same. Only beeing different when formated. The breezedude itselfs formats the disk, if no valid filesystem if found, but you can also format it externally using the OS (windows, android, mac). With this the filesystem is different, but the breezedude is still lable to read it (required for android devices). I still didn't find the reason for this and i am currently not able to write files from breezedude (data is written, FAT entry not...) Maybe i will dig into this during the winter.

[mhofner21]

Just a quick clarification: after flashing on macOS the drive is readable, but not writable (not “unreadable”) – and it’s also not writable on Windows afterwards.
If I start the Breezedude in bootloader mode and re-flash the firmware (under Windows), it becomes writable again and I can copy the settings.txt as described.

Sorry for the confusion in my previous message!

[thezenox]

can you reproduce it? If so, can you try it again and upload the current.uf2 here of the working one and not working one for comparison? If you don't have a factory new boards left, you can erase the flash with the programmer before programming by adding chip-erase;.

openocd -f interface/cmsis-dap.cfg -f target/at91samdXX.cfg -c "init; at91samd chip-erase; program bootloader-breezedude-v3.16.0-19-atmel.bin verify reset exit 0x00000000"

When a uf2 update is flashed in bootloader mode, it only writes pages that are used by the uf2 file. So with a normal update file the file system part in the very end of the flash stays untouched (thats why the settings file will survive an update. Only if the start address of the file system changes in the new firmware, it does not find a valid filesystem and will automatically format the disk)