Flashing should still work.

Can you provide a list of board/adapter to test (stlink, nrf, kinetis, etc) ? This will simplify the tracking of what needs to be tested.

alternative to #13858

I also prefer this approach over #13858 as it's more generic and covers all openocd adapters.

Can you provide a list of board/adapter to test (stlink, nrf, kinetis, etc) ? This will simplify the tracking of what needs to be tested.

Sure! Well for most adapters, this basically just shuffles around the location of -c 'transport select swd' inside OPENOCD_ADAPTER_INIT so I don't think we need to test them all.

What should be tested is

• flashing a Kinetis board with OpenOCD
• flashing a nRF52 board with OpenOCD
• flashing a board that uses iotlab.inc.mk
• flashing a board that uses JLink with OpenOCD (all the nrf52xxxdk boards come with an on-board JLink)
• flashing a mulle board with OpenOCD

And ideally, the Waveshare nRF52840 Eval Kit should now be flashable with ST-Link.
I tried with a nRF52810 board and one of the common ST-Link v2 dongles and wasn't successful, but OpenOCD got called with the right parameters so (hla_swd), it might well be that OpenOCD does not support this device yet.

I tried with a nRF52810 board and one of the common ST-Link v2 dongles and wasn't successful, but OpenOCD got called with the right parameters so (hla_swd), it might well be that OpenOCD does not support this device yet.

It should work because all Nucleo boards are flashed with OpenOCD, ST-LINKV2 and hla_swd as transport protocol.
I have tested it with the Waveshare nRF52840 Eval Kit and it also works with the following flashing command 👍

PROGRAMMER=openocd DEBUG_ADAPTER=stlink make BOARD=waveshare-nrf52840-eval-kit -C tests/shell flash

@benpicco Since this PR also solves the problem addressed in PR #13858, I will close PR #13858. However, I would like at least the documentation to be expanded, as suggested in the PR #13858. This could be done piggybacked with this PR.

Looks good to me and makes sense. Unfortunately I can't support the test because I don't have the boards mentioned in the test list 😟

Flashing the openlabs-kw41z-mini with OpenOCD also still works.

Test results on IoT-LAB flashing still works, we can skip mulle IMO, not widely available, can't be bought, I think there is one in FU-BERLIN, but that is it AFAIK.

IOTLAB_NODE=m3-9.saclay.iot-lab.info BOARD=iotlab-m3 make -C examples/default/ flash term

iotlab-node --jmespath='keys(@)[0]' --format='int'  --list saclay,m3,9 --update /home/francisco/workspace/RIOT3/examples/default/bin/iotlab-m3/default.elf | grep 0
0
ssh -t [email protected] 'socat - tcp:m3-9.saclay.iot-lab.info:20000'
help
help
Command              Description
---------------------------------------
reboot               Reboot the node
version              Prints current RIOT_VERSION
pm                   interact with layered PM subsystem
ps                   Prints information about running threads.
random_init          initializes the PRNG
random_get           returns 32 bit of pseudo randomness
rtc                  control RTC peripheral interface
ifconfig             Configure network interfaces
txtsnd               Sends a custom string as is over the link layer
saul                 interact with sensors and actuators using SAUL
>

Test results on IoT-LAB flashing still works

I'm not sure testing like this is correct in this case. On current master I'm getting the following error when trying to flash the iotlab-m3:

Info : FTDI SWD mode enabled
swd
Warn : Interface already configured, ignoring
trst_and_srst separate srst_nogate trst_push_pull srst_open_drain connect_assert_srst

Error: SWD mode is active but SWD_EN signal is not defined

There seems to be no definition of SWD_EN in the configuration file.

I'm not sure testing like this is correct in this case. On current master I'm getting the following error when trying to flash the iotlab-m3:

You are absolutely right, iot-lab uses its own flashing scheme. Sorry for letting this slip.