What is the right/best boot loader port to use with STM32CubeIDE and STLINK V3Set?

[ENovk.1]

I have read the IDE users' manual, and it just seems to assume that the boot loader connection exists. The V3set has multiple methods to connect (just as the boot loader does, i.e. serial, i2c, SPI, USB.)

I'm designing my first STM32 application board (with the STM32G474 if that matters) and trying to decide whether I implement the serial bootloader/reset circuitry that exists on the demo boards, or just leave a few pins of an I2C or SPI interface available on the board which I'd connect to the STLINK with jumpers.

It does bring up the question which I might have missed in the documentation: is it possible to boatload through the SWD/JTAG interface?

What I'm guessing is that the IDE resets the MCU, sets the appropriate registers in the MCU to enable the boot loader to start scanning all the serial options, sets a breakpoint in the user code to be downloaded, and then waits for the download to complete and the user code to run. For this to happen do I need two connections to the board under development (SWD/JTAG *and* one of the STLINK's serial options?

Sorry to be noob on this, but it's a lot of documentation to digest and I always wonder if I'm missing something (like I just discovered the boot loader document yesterday!)

Thanks!

[Tesla DeLorean]

The JTAG/SWD operates via a different method, it uses internal scan-chains within the IC to access processor registers, indirectly accessing buses, peripherals and memory. It gets into the internal workings of the chip, and is a rather deep rabbit hole. The ARM docs might be the best to understand the mechanics there.

Typically factory programming is done via JTAG/SWD, as well as debugging. The boundary scan offered by JTAG would allow for pins and circuit nodes to be tested.

The System Loader in ROM also provides alternate means, using serial for example is a cheap and scalable method. Review AN2606 to get an overview of the pins involved on specific parts. Writing SW to interact with UART is something a developer should be able to do on their platform, ie Windows, Linux, MCU

Should consider exposing SWDIO, SWCLK, SWO, NRST, GND as test points, headers, or edge castellations so you can readily fixture and program. A serial port you can commit for debug telemetry and/or UART programming are also helpful. Pull BOOT0 down, but allow for the pin to be driven high by pin/test point.

If you already have a USB or UART/RS232 interface use those as means to program.

Avoid attaching GPS/GNSS devices to the UARTs that the loader checks, these will squawk at startup and confuse the loader. For STM32 that allow for RX/TX reversal, you could use that to avoid triggering the loader with such signaling.