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