runners: stm32cubeprogrammer: add support for --dev-id

[mathieuchopstm]

Add support for the standard --dev-id argument used to select target ST-Link debug probe based on serial number. Note that this could already be achieved using custom argument --conn-modifiers. (--dev-id <XXX> is equivalent to --conn-modifiers sn=<XXX>)

[erwango]

Let's migrate Twister hardware adapter script to make use of this new option instead of current tool-opt.

[mathieuchopstm]

+

zephyr/scripts/pylib/twister/twisterlib/handlers.py

Lines 640 to 641 in 1a49b41

	elif runner == "stm32cubeprogrammer" and product != "BOOT-SERIAL":
	command.append(f"--tool-opt=sn={board_id}")

[erwango]

Making #100220 (review) blocking.

[mathieuchopstm]

Updated (hopefully) all places making use of --tool-opt=sn=<XXX> to use --dev-id instead

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mathieuchopstm]

About CI failures:

E0611:No name 'ZEPHYR_BASE' in module 'twister' (no-name-in-module)
File:scripts/tests/twister/test_handlers.py
Line:35
Column:0
Error: Check python files with ruff.

is entirely out of my control. How can I override CI to ignore this false positive? Or is it a legitimate error?

Python lint error (SIM114) see https://docs.astral.sh/ruff/rules/if-with-same-arms:Combine `if` branches using logical `or` operator
File:/home/runner/work/zephyr/zephyr/scripts/pylib/pytest-twister-harness/src/twister_harness/device/hardware_adapter.py
Line:106
Column:13
EndLine:111
EndColumn:43

I understand CI wants

-          elif runner == 'jlink':
+          elif runner == 'jlink' or (runner == 'stm32cubeprogrammer' and self.device_config.product != "BOOT-SERIAL"):
                base_args.append('--dev-id')
                base_args.append(board_id)
-            elif runner == 'stm32cubeprogrammer' and self.device_config.product != "BOOT-SERIAL":
-                base_args.append('--dev-id')
-                base_args.append(board_id)

I have no problem with this but it would create an inconsistency. Should I do it anyways? Or should another solution be adopted? One idea that comes to mind is unifying all "conforming" runners under a single else using --dev-id:

        if board_id := self.device_config.id:
            if runner == 'pyocd':
                extra_args.append('--board-id')
                extra_args.append(board_id)
            elif runner == "esp32":
                extra_args.append("--esp-device")
                extra_args.append(board_id)
-           elif runner in ('nrfjprog', 'nrfutil', 'nrfutil_next'):
-              extra_args.append('--dev-id')
-               extra_args.append(board_id)
            elif runner == 'openocd' and self.device_config.product in ['STM32 STLink', 'STLINK-V3']:
                extra_args.append('--cmd-pre-init')
                extra_args.append(f'hla_serial {board_id}')
            elif runner == 'openocd' and self.device_config.product == 'EDBG CMSIS-DAP':
                extra_args.append('--cmd-pre-init')
                extra_args.append(f'cmsis_dap_serial {board_id}')
            elif runner == "openocd" and self.device_config.product == "LPC-LINK2 CMSIS-DAP":
                extra_args.append("--cmd-pre-init")
                extra_args.append(f'adapter serial {board_id}')
-           elif runner == 'jlink':
-               base_args.append('--dev-id')
-               base_args.append(board_id)
            elif runner == 'stm32cubeprogrammer' and self.device_config.product != "BOOT-SERIAL":
                base_args.append('--dev-id')
                base_args.append(board_id)
            elif runner == 'linkserver':
                base_args.append(f'--probe={board_id}')
+           else:
+               # 'nrfjprog', 'nrfutil', 'nrfutil_next', 'jlink'
+               base_args.append('--dev-id')
+               base_args.append(board_id)

(We could also hardcode BOOT-SERIAL as a special case in the stm32cubeprogrammer runner to avoid needing a separate branch)

I'll let maintainers decide 🙂