New batch of Swan R5 boards cannot upload via ST-Link or USB DFU, older Swan (purchsed 2025) works in same setup

Hardware
1

Hello Blues team,

I’m seeing a systematic upload/programming issue with a new batch of Swan boards (purchsed around April in 2026). I previously had this project working well with another Swan/Notecarrier F set (purchsed back to 2025), but none of the newly purchased Swan boards can be programmed in the same setup.

Hardware

  • Blues Swan R5
  • Blues Notecarrier F
  • External ST-Link for SWD upload
  • Windows PC using VS Code + PlatformIO
  • Notecarrier F switches:
    • Feather_EN: ON
    • AUX: normal
    • GPS ATN: passive
[env:swan_r5]
platform = ststm32
board = blues_swan_r5
framework = arduino
monitor_speed = 115200

upload_protocol = stlink

build_flags = -D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC

PlatfrmIO reports:

VAILABLE: blackmagic, cmsis-dap, dfu, jlink, mbed, serial, stlink
CURRENT: upload_protocol = stlink
Uploading .pio\build\swan_r5\firmware.elf

ST-Link/OpenOCD error:

xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty (2023-01-30-15:04)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1

The ST-Link appears correctly in Windows Device Manager. I also briefly saw Error: open failed, but after reconnecting the ST-Link the consistent error is now the target init failure above. An older Swan/Notecarrier setup worked with this same project. After swapping hardware, the upload works with a different Swan (old) setup, but none of the newly purchased Swans work. This makes me think the issue is related to the new Swan batch/revision or a changed programming/boot behavior, rather than my firmware.

Since OpenOCD fails before programming, I assume my firmware code is probably not involved. It seems like the debugger cannot connect to the STM32 target over SWD.

It would be greately appreciated if anyone has the solutions. Thanks.

Best regards,

Jaden

2

Hi @Jaden,

How are you powering the Swans? When I see unable to connect to the target I tend to first think that it’s not getting enough power (needs to be connected to a LiPo or via USB).

If that’s not the issue, I would try uploading firmware in dfu mode and bypass the ST-Link. We have instructions here.

Lastly, I’d be surprised if this was the issue, but it’s worth consulting this guide re: recovering the STM32L4R5.

Obviously the fact that the “old” Swan is working fine and the “new” ones are not is a huge variable here, but I’d be curious if any of these suggestions resolves the issue (temporarily) before we look into next steps.

Thanks,
Rob

3

Hi Bob,

Attached is the back of the new Swan that has issue.

I powered the Notecarrier F through the V+ JST connector using a battery bank with a 5V output, with the Swan plugged in.

Based on my testing, the issue appears to be with the newly purchased Swan board. It also does not work in DFU mode.

I built a new assembly of our application unit using the same components and performed a quick A/B test:

  • The old Swan works on the new unit.
  • The new Swan does not work on the new unit.
  • The new Swan also does not work on the old application unit.
  • The old Swan continues to work properly.

Based on these results, it seems that the new Swan board has an issue. Thanks.

Best regards,

Jaden

(attachments)

101.jpeg
101.jpeg691×1167 206 KB

4

Hi @Jaden - Did you have a chance to look into the recovery guide as well?

5

Hi Bob,

Thank you. I haven’t had a chance to review the recovery guide yet. It appears that the guide is intended for an older version of the board.

Since I previously sent you an image of my Swan device, could you help identify which hardware version it is? Also, based on what you’ve seen, what do you think the root cause of the issue might be? I’d like to understand the problem clearly before proceeding with any recovery or repair steps.

Specifically, what information can you tell from the photo? Thanks.

Best regards,

Jaden

6

Hi @RobLauer ,

Under the OB tab, there is no [REG] group. And I couldn’t find the tabel to compare to the Invalid FLASH Registers.

Open the OB (Option Bytes) panel from the left navigation, then expand the [REG] group to view the FLASH option-byte registers.

image
image891×364 15.6 KB

7

Hey @Jaden ,

We’re following up with our operations team to see if we can recreate your problem with new hardware.

In the meantime, I spent some time messing with my Swans this afternoon. I did hit one scenario where I needed to do a DFU upload to “fix” an unresponsive Swan, after which I could use the STLINK again.

I know you already mentioned you tried DFU, but just to be very clear, when you tried DFU did you:

  1. Have upload_protocol set to dfu in your platformio.ini? Here’s what mine looks like
[env:blues_swan_r5]
platform = ststm32
board = blues_swan_r5
upload_protocol = dfu
framework = arduino
build_flags = -D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
monitor_speed = 115200
lib_deps =
  Wire
  blues/Blues Wireless Notecard
  1. Make sure to press the Swan’s buttons in the correct order before uploading? Per the docs: “Press and hold the BOOT button on the Swan, press and release RESET, then release BOOT to cause the Swan to jump into its bootloader.”

If you haven’t used DFU mode the buttons are easy to mess up, so I thought I’d check.

And I’ll follow up when I hear back.

TJ