ch347: drive target reset over SWD on the TRST pin - #4440

SWD leaves the TRST pin unused, so a generic CH347 can drive the target's reset line through it with the GPIO command. This matches the OpenOCD CH347 driver (review 9700).

• TRST is pin 9 on both chips, but a different GPIO: GPIO5 on the CH347T and GPIO3 on the CH347F. The line is pulled low to assert and released to an input, so it needs a pull-up.
• A board recognised by its USB identity (wch-probe) keeps its own wiring, including no reset at all. Over JTAG a generic CH347 still writes no GPIO.
• Entering SWD releases the line, because the chip keeps GPIO state and an earlier session may have been killed with reset held. Leaving SWD with reset held releases it first. Drop now releases whichever pin was asserted, even after a protocol switch.

This changes the earlier rule that a generic CH347 never writes a GPIO. That rule now holds only for JTAG.

Testing

On a CH347T (firmware 5.44) with an S32K118 whose RESET_b is wired to TRST:

• The GPIO readback shows output-low on assert and input-high on release, and SWD keeps working while reset is held.
• RCM_SRS reports a pin reset (0x40) after a pulse, against 0x400 after SYSRESETREQ.
• A line left low by hand is released when SWD is selected, and the session then reads flash.
• A JTAG session afterwards drives the pin as TRST again (output-high).

Unit tests cover the board override, protocol switching while reset is held, and the release on drop.

Note: connect-under-reset on Cortex-M

On the S32K118, --connect-under-reset drives the pin correctly but still times out waiting for the halt. This is unrelated to this driver. cortex_m_reset_catch_set sets DEMCR.VC_CORERESET while the chip is held in reset, but C_DEBUGEN is only set by enable_arm_debug after the release (#3485). The previous session's debug_core_stop cleared it, so the vector catch never fires. Setting C_DEBUGEN along with the catch makes it halt every time. I'll handle that in a separate PR.

🤖 Generated with Claude Code