)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"dbb4c0dee9adeaadb78b57d07bdf900a17a1d692","unresolved":false,"context_lines":[{"line_number":20,"context_line":"Honour the drive mode that \u0027reset_config\u0027 keeps in the GPIO configuration."},{"line_number":21,"context_line":"SRST defaults to open drain, which the chip cannot do by itself, so"},{"line_number":22,"context_line":"emulate it by switching the pin to an input instead of driving it to the"},{"line_number":23,"context_line":"inactive level. The reset line then needs a pull-up; \u0027reset_config"},{"line_number":24,"context_line":"srst_push_pull\u0027 selects the previous behaviour of driving both levels."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"Don\u0027t verify the readback of the GPIO command for SRST. Bit 6 of the"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"41d9cb6b_e6922db4","line":23,"range":{"start_line":23,"start_character":16,"end_line":23,"end_character":51},"updated":"2026-09-01 20:09:51.000000000","message":"Just a remark: I used CH437T_EVT and CH437F_EVT for testing and measured internal weak pull-up (0.1mA) on any GPIO set to input mode. It\u0027s just perfect for SRST open drain. However it\u0027s not documented anywhere so may depend on the chip version, firmware etc.","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":1002195,"name":"Matthias Jentsch","display_name":"EasyDevKits","email":"info@easydevkits.com","username":"EasyDevKits"},"change_message_id":"bd49d0e3ace14e0e56d2de26fc5e9cf6ade2db7a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f8688e24_f95dc82b","updated":"2026-08-24 19:49:14.000000000","message":"I think this could be combined with Lynch\u0027s approach in https://review.openocd.org/c/openocd/+/9703, which uses the CH347F\u0027s dedicated SRST output.\n\nThe two approaches could complement each other: use the dedicated SRST output on the CH347F and retain the GPIO-based approach for the CH347T. Also, the GPIO-based SRST handling could potentially work in both JTAG and SWD mode when a non-conflicting GPIO is explicitly selected with adapter gpio srst.\n\nThis could provide SRST support on both CH347 variants in both transport modes. Perhaps a combined solution would make sense.","commit_id":"5cc7c72e9ac7dff8e34b890fc0f8a44ecd5c2ada"},{"author":{"_account_id":1002195,"name":"Matthias Jentsch","display_name":"EasyDevKits","email":"info@easydevkits.com","username":"EasyDevKits"},"change_message_id":"d63df5150aa577362e85ec05a435ad8bb30c6a57","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f0144488_3e90f508","updated":"2026-08-24 19:24:12.000000000","message":"Thanks for the patch! I reviewed the SRST handling, the CH347T/CH347F GPIO differences, and the 0xCC command semantics. The approach of reusing the otherwise unused TRST pin as SRST in SWD mode makes sense, and the handling of the GPIO readback is well justified by the CH347 documentation. I found only two small things, which I\u0027ve commented on inline.","commit_id":"5cc7c72e9ac7dff8e34b890fc0f8a44ecd5c2ada"},{"author":{"_account_id":1002195,"name":"Matthias Jentsch","display_name":"EasyDevKits","email":"info@easydevkits.com","username":"EasyDevKits"},"change_message_id":"2768b8bb469869694ef3f0bafb308527301bf4e4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"daf943fa_b131c4bf","updated":"2026-08-31 19:57:58.000000000","message":"Looks good to me. The other change 9703 can be applied later.","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"4ce7dd7d4eb19e699e223c5bed16e8483acd38d7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6c9eedce_5e878b56","updated":"2026-09-01 09:54:35.000000000","message":"Paulius,\n\nit would be great if the driver respects more GPIO configuration options.\n\nThe most important is `adapter_config.gpios[ADAPTER_GPIO_IDX_SRST].drive`.\nSRST signal is ADAPTER_GPIO_DRIVE_MODE_OPEN_DRAIN by default (however could be\nset to push-pull in reset_config).\nCH347F seems to set GPIO to OD if bit(6) of value is 0, but we can easily simulate open drain by setting GPIO to input instead of GPIO_SET_H.\nSee e.g. am335xgpio.c driver for advanced work with `adapter_config.gpios`.\n\nAlso `adapter_config.gpios[ADAPTER_GPIO_IDX_SRST].init_state` should be honoured to ensure proper `reset_config connect_assert_srst` operation.\nSee 9926: jtag/adapter: honour connect_assert_srst in gpio init | https://review.openocd.org/c/openocd/+/9926\n\n`adapter_config.gpios[ADAPTER_GPIO_IDX_LED].exit_state` seems me more handy than hardwired LED_ON in ch347_quit().\n\nPlease implement at least ADAPTER_GPIO_DRIVE_MODE_OPEN_DRAIN for SRST, other is optional and could be left for future follow up patches.\n\n\nAnother concern is compatibility of CH347F/T versions and JTAG/SWD modes.\nIf I understand correctly this patch sets TRST GPIO pin as default SRST for SWD modes on both F/T. But with #9703 we get SRST on dedicated SRST GPIO pin in JTAG mode probably for T version only. Not sure if such mismatch makes wiring easy.\nWouldn\u0027t be better not to enable SRST on TRST in SWD mode by default or use SRST dedicated pin if exists? Just recommend using TRST GPIO for SRST in documentation and let users to configure themself?","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"93f1b29ddaacc73c20360db641f7a72f31296c28","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6fd8acf3_156478b1","in_reply_to":"6c9eedce_5e878b56","updated":"2026-09-01 11:28:18.000000000","message":"\u003e Another concern is compatibility of CH347F/T versions and JTAG/SWD modes.\n...\nAfter testing this and #9703 I understand better. The chip design is so horrible that my wish cannot be fulfilled. The dedicated SRST pin on F version is not accessible as a GPIO. Correct me if I\u0027m wrong.","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1002563,"name":"lynch","display_name":"lynch","email":"lynch.wy@gmail.com","username":"lynchwy"},"change_message_id":"04c1f9d87f2cda05b034cfc6e25580bcc4aceea6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cdd9e092_26342570","in_reply_to":"e93a770c_767eeeec","updated":"2026-08-31 11:11:55.000000000","message":"I think these issues are best discussed specifically on change 9703.\nFor the patch series, I suggest keeping the current change as a separate commit, then rebasing the follow-up change on top of it for the next iteration. That way the shared GPIO and SWD support code remains in one place, while 9703 can be reduced to the CH347F dedicated SRST functionality. I prefer to add the GPIO-based SRST feature as a separate follow-up change later.","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1002556,"name":"Paulius Zaleckas","display_name":"Paulius Zaleckas","email":"paulius.zaleckas@gmail.com","username":"pauliusz"},"change_message_id":"fe90228e1c1a4bf48375aa7a4d6488f4f7cfcfa2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e93a770c_767eeeec","in_reply_to":"f8688e24_f95dc82b","updated":"2026-08-30 11:32:35.000000000","message":"Thanks for the pointer, I had not seen 9703.\n\nComparing the two, 9703 already contains most of this change: the per\nvariant masks, CH347T/CH347F_TRST_GPIO, ch347_usable_gpios(),\nch347_gpio_cmd(), the ch347_gpio_set() refactor,\nch347_configure_srst_gpio(), the SWD branch of ch347_reset() and the\nfile header update. What it adds on top is the dedicated SRST output of\nthe CH347F: CH347_CMD_PIN_SET, SRST_H/SRST_L in the JTAG pin byte,\nch347_srst_enable() and the pin cleanup in ch347_quit().\n\nSo the two are not independent and cannot both be merged as they are.\nRather than squashing them I would prefer to chain them: keep this\nchange as the base and let 9703 rebase on top, reduced to the dedicated\nSRST output. That keeps one issue per change and preserves the review\nthat already happened here. I am equally happy the other way round if\nlynch prefers; the important part is that the shared code appears only\nonce.\n\nTwo things I noticed in 9703 while comparing, better discussed there:\n\n- ch347.srst_pin is added to the JTAG pin byte unconditionally, but\n  ch347_srst_enable() is only called for non CH347T chips. On the CH347T\n  bit 6 of that byte is not an SRST output, so this may disturb JTAG on\n  the CH347T. I have a CH347T here and can test it.\n\n- ch347_srst_enable() is called from ch347_speed_set(), so it runs on\n  every speed change, and also for OTHER_PRODUCT_ID where the 0xE2\n  command may not exist.\n\nOn GPIO based SRST in JTAG mode: I agree it can work with an explicitly\nselected non conflicting GPIO, but on both chips the default pin is\nTRST, which is a real JTAG signal, so it would have to stay opt-in. I\nwould rather add that as a follow up change.","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"1df7f499aae79a91e1792001a2e2d5577142f912","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ef3667a3_139f90be","updated":"2026-09-07 13:35:29.000000000","message":"Matthias, could you check the latest patchset?","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"dbb4c0dee9adeaadb78b57d07bdf900a17a1d692","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"636b47e9_84787351","updated":"2026-09-01 20:09:51.000000000","message":"Shortly tested on CH347T.\nOpen drain on SRST works, unfortunately not before the first reset.\nIf we use the default SRST routing on TRST pin, TRST drives hard H from CH347 power-on until the first reset (correct for TRST but not for SRST). In that light I may personally prefer TDO pin for open drain SWD reset - unlike TRST pin it\u0027s initialised to input mode with weak pull-up (GPIO1 which is currently locked)\nLooking forward for the GPIO initialisation to `adapter_gpio_config[ADAPTER_GPIO_IDX_SRST].init_state`\n\nThanks a lot, Paulius!","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"},{"author":{"_account_id":1002556,"name":"Paulius Zaleckas","display_name":"Paulius Zaleckas","email":"paulius.zaleckas@gmail.com","username":"pauliusz"},"change_message_id":"401747b922812b329677d25620ef9dd12f87d6eb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ba421391_d585cafa","in_reply_to":"6c9eedce_5e878b56","updated":"2026-09-01 17:52:22.000000000","message":"Thanks for the detailed review.\n\nPatch set 3 implements the open drain drive mode you asked for.\n\nch347_reset() now maps the output level to the GPIO command byte through\na new helper:\n\n  ADAPTER_GPIO_DRIVE_MODE_OPEN_DRAIN   level ? GPIO_SET_INPUT : GPIO_SET_L\n  ADAPTER_GPIO_DRIVE_MODE_OPEN_SOURCE  level ? GPIO_SET_H : GPIO_SET_INPUT\n  ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL    level ? GPIO_SET_H : GPIO_SET_L\n\nwhich is exactly your suggestion: switch the pin to an input instead of\ndriving the inactive level. The drive mode is read in ch347_reset()\nrather than cached at configuration time, because \u0027reset_config\u0027 is\nCOMMAND_ANY and sync_adapter_reset_with_gpios() can still change it after\ninit.\n\nTested on a CH347T with an S32K118 whose RESET_b is wired to the TRST\npin. I temporarily logged the command byte and the byte the chip reports\nback, where BIT(7) is \"pin is an output\" and BIT(6) is the measured pin\nlevel:\n\n  open drain  assert    cmd 0xf0 (SET_L)      is_output 1  level 0\n              deassert  cmd 0xc0 (SET_INPUT)  is_output 0  level 1\n  push-pull   assert    cmd 0xf0 (SET_L)      is_output 1  level 0\n              deassert  cmd 0xf8 (SET_H)      is_output 1  level 1\n\nSo in open drain mode the chip really does stop driving the pin, by its\nown report, and the target pull-up brings the line high. MDM-AP STAT\nagrees: SYSRES is 0 while asserted and 1 after deassert in both modes,\nand \u0027reset halt\u0027 works 5/5 in both.\n\nOne thing worth knowing for anyone reproducing this: target/s32k.cfg only\nsets \u0027srst_nogate\u0027 and never declares the SRST signal, so a plain\n\u0027reset halt\u0027 there goes through SYSRESETREQ and never touches the GPIO.\nThe numbers above use an explicit \u0027reset_config srst_only srst_nogate\u0027.\n\nI left init_state and exit_state for follow up changes, as you allowed.\nThe SRST init_state also depends on 9926, which has not landed yet, so it\nlooks better to do that once it has.","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"},{"author":{"_account_id":1002556,"name":"Paulius Zaleckas","display_name":"Paulius Zaleckas","email":"paulius.zaleckas@gmail.com","username":"pauliusz"},"change_message_id":"401747b922812b329677d25620ef9dd12f87d6eb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"05f88d61_691d4d6a","in_reply_to":"6fd8acf3_156478b1","updated":"2026-09-01 17:52:22.000000000","message":"\u003e The dedicated SRST pin on F version is not accessible as a GPIO.\n\u003e Correct me if I\u0027m wrong.\n\nThat matches my understanding, but I have not measured it, so please take\nit as unconfirmed rather than as a correction from me.\n\nWhat points that way: the CH347F GPIO mask in this change is GPIO0 to\nGPIO3, because GPIO4 to GPIO7 are TCK, TDO, TDI and TMS. The dedicated\nSRST output in 9703 is driven by the separate 0xE2 command and the SRST\nbits of the JTAG pin byte, not by the 0xCC GPIO command, which is\nconsistent with it not being one of the eight GPIO\u0027s.\n\nWhat I have actually measured is only the CH347T, where I swept all eight\nGPIO\u0027s against the MDM-AP SYSRES bit: only GPIO5, the TRST pin, reaches\nthe reset line. On my CH347F board RESET_b is wired to TRST as well, so\nthe same sweep there says nothing about the dedicated SRST pin. Settling\nit properly means rewiring the target reset to the dedicated SRST pin and\nrepeating the sweep. I am happy to do that if it matters for the\ndecision.","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"555af0dec35dea9d4d1c8b9e4d5f5ef2a4421adc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"796aafc4_b1d9a75c","in_reply_to":"af61554f_bbf62fb3","updated":"2026-09-07 19:57:53.000000000","message":"Thanks!","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"},{"author":{"_account_id":1002195,"name":"Matthias Jentsch","display_name":"EasyDevKits","email":"info@easydevkits.com","username":"EasyDevKits"},"change_message_id":"b18af969acb1c01d596523c889c4d705979ea95b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"af61554f_bbf62fb3","in_reply_to":"ef3667a3_139f90be","updated":"2026-09-07 19:42:00.000000000","message":"Look good to me.","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"}],"src/jtag/drivers/ch347.c":[{"author":{"_account_id":1002195,"name":"Matthias Jentsch","display_name":"EasyDevKits","email":"info@easydevkits.com","username":"EasyDevKits"},"change_message_id":"d63df5150aa577362e85ec05a435ad8bb30c6a57","unresolved":true,"context_lines":[{"line_number":1286,"context_line":" * @param state returns the byte the device reports for this pin; BIT(6) is the pin level"},{"line_number":1287,"context_line":" * @return ERROR_OK at success"},{"line_number":1288,"context_line":" */"},{"line_number":1289,"context_line":"static int ch347_gpio_cmd(int gpio, uint8_t value, uint8_t *state)"},{"line_number":1290,"context_line":"{"},{"line_number":1291,"context_line":"\tint retval \u003d ch347_cmd_start_next(CH347_CMD_GPIO);"},{"line_number":1292,"context_line":"\tif (retval !\u003d ERROR_OK)"}],"source_content_type":"text/x-csrc","patch_set":1,"id":"63b7ac64_2e882244","line":1289,"updated":"2026-08-24 19:24:12.000000000","message":"ch347_gpio_cmd() assumes gpio is always in the range 0..7. Since this helper is now shared by multiple callers, would it be worth checking the range here to avoid an out-of-bounds access?","commit_id":"5cc7c72e9ac7dff8e34b890fc0f8a44ecd5c2ada"},{"author":{"_account_id":1002195,"name":"Matthias Jentsch","display_name":"EasyDevKits","email":"info@easydevkits.com","username":"EasyDevKits"},"change_message_id":"d63df5150aa577362e85ec05a435ad8bb30c6a57","unresolved":true,"context_lines":[{"line_number":1878,"context_line":" *"},{"line_number":1879,"context_line":" * @param srst_config Pointer to the GPIO configuration structure for the SRST pin"},{"line_number":1880,"context_line":" */"},{"line_number":1881,"context_line":"static void ch347_configure_srst_gpio(const struct adapter_gpio_config *srst_config)"},{"line_number":1882,"context_line":"{"},{"line_number":1883,"context_line":"\tch347_srst_active_high \u003d !srst_config-\u003eactive_low;"},{"line_number":1884,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":1,"id":"dcfc8660_9b8f84e9","line":1881,"updated":"2026-08-24 19:24:12.000000000","message":"Could we reject an SRST GPIO that is already configured as the activity LED GPIO? Otherwise adapter gpio led \u003cn\u003e and adapter gpio srst \u003cn\u003e can assign two functions to the same physical GPIO, potentially causing LED activity to toggle the reset line.","commit_id":"5cc7c72e9ac7dff8e34b890fc0f8a44ecd5c2ada"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"973b7ed8757ff9ed55a5c02971914bf6e0e69b7d","unresolved":true,"context_lines":[{"line_number":74,"context_line":"#define GPIO_CNT\t8 // the CH347 has 8 GPIO\u0027s"},{"line_number":75,"context_line":"/* mask which GPIO\u0027s are available in mode 3 of the CH347T: only GPIO3 (Pin11 / SCL),"},{"line_number":76,"context_line":"\tGPIO4 (Pin15 / ACT), GPIO5 (Pin9 / TRST) and GPIO6 (Pin2 / CTS1) are possible */"},{"line_number":77,"context_line":"#define CH347T_USABLE_GPIOS\t0x78"},{"line_number":78,"context_line":"/* On the CH347F the GPIO\u0027s share the pins with the interface signals: GPIO0 (Pin17),"},{"line_number":79,"context_line":"\tGPIO1 (Pin18), GPIO2 (Pin10), GPIO3 (Pin9 / TRST), GPIO4 (Pin23 / TCK + SWDCLK),"},{"line_number":80,"context_line":"\tGPIO5 (Pin24 / TDO), GPIO6 (Pin25 / TDI), GPIO7 (Pin26 / TMS + SWDIO). GPIO4 to GPIO7"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"75b8de2d_85ca5004","line":77,"updated":"2026-09-01 14:36:02.000000000","message":"What is source for choosing usable pins?\nOn CH347T I tested also GPIO7 (RTS1) and GPIO1 (TDO, not used for SWD) and haven\u0027t seen any problem. Of course if UART1 is active then RTS is not a good choice. Seems me that only GPIO0 (TCK) and GPIO2 (TMS/SWD) cannot be used as they break SWD and I agree with exclusion of GPIO7 (RTS1). Did I miss something?","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1002556,"name":"Paulius Zaleckas","display_name":"Paulius Zaleckas","email":"paulius.zaleckas@gmail.com","username":"pauliusz"},"change_message_id":"fe90228e1c1a4bf48375aa7a4d6488f4f7cfcfa2","unresolved":false,"context_lines":[{"line_number":1286,"context_line":" * @param state returns the byte the device reports for this pin; BIT(6) is the pin level"},{"line_number":1287,"context_line":" * @return ERROR_OK at success"},{"line_number":1288,"context_line":" */"},{"line_number":1289,"context_line":"static int ch347_gpio_cmd(unsigned int gpio, uint8_t value, uint8_t *state)"},{"line_number":1290,"context_line":"{"},{"line_number":1291,"context_line":"\tif (gpio \u003e\u003d GPIO_CNT) {"},{"line_number":1292,"context_line":"\t\tLOG_ERROR(\"GPIO %u out of range\", gpio);"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"56f4bab6_2f2d49d8","line":1289,"in_reply_to":"63b7ac64_2e882244","updated":"2026-08-30 11:32:35.000000000","message":"Good point, fixed in patch set 2. ch347_gpio_cmd() now takes an\nunsigned int and rejects anything \u003e\u003d GPIO_CNT. Making the parameter\nunsigned also covers a negative value from a caller: it wraps and fails\nthe same check, so there is only one test to maintain.","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1002556,"name":"Paulius Zaleckas","display_name":"Paulius Zaleckas","email":"paulius.zaleckas@gmail.com","username":"pauliusz"},"change_message_id":"fe90228e1c1a4bf48375aa7a4d6488f4f7cfcfa2","unresolved":false,"context_lines":[{"line_number":1885,"context_line":" *"},{"line_number":1886,"context_line":" * @param srst_config Pointer to the GPIO configuration structure for the SRST pin"},{"line_number":1887,"context_line":" */"},{"line_number":1888,"context_line":"static void ch347_configure_srst_gpio(const struct adapter_gpio_config *srst_config)"},{"line_number":1889,"context_line":"{"},{"line_number":1890,"context_line":"\tch347_srst_active_high \u003d !srst_config-\u003eactive_low;"},{"line_number":1891,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":2,"id":"d32cee4c_45d3a93d","line":1888,"in_reply_to":"dcfc8660_9b8f84e9","updated":"2026-08-30 11:32:35.000000000","message":"Agreed, fixed in patch set 2. ch347_configure_srst_gpio() now refuses a\nGPIO that is already used as the activity LED and disables SRST.\n\nI placed the check after the default/explicit branches on purpose, so it\nalso covers the default TRST pin. \u0027adapter gpio led 5\u0027 on a CH347T\ncollides with the default SRST GPIO without the user configuring SRST at\nall, which I think is the more likely accident.\n\nch347_init() configures the LED before SRST, so the LED pin is known at\nthat point. I noted that dependency in the doc comment of the function.\n\nTested on a CH347T with \u0027adapter gpio led 5\u0027:\n  Error: GPIO 5 is already used as the activity LED, disabling SRST","commit_id":"ec7c06bf5f6d9378ca467977ab2c2f10b7dcd484"},{"author":{"_account_id":1002556,"name":"Paulius Zaleckas","display_name":"Paulius Zaleckas","email":"paulius.zaleckas@gmail.com","username":"pauliusz"},"change_message_id":"401747b922812b329677d25620ef9dd12f87d6eb","unresolved":false,"context_lines":[{"line_number":74,"context_line":"#define GPIO_CNT\t8 // the CH347 has 8 GPIO\u0027s"},{"line_number":75,"context_line":"/* mask which GPIO\u0027s are available in mode 3 of the CH347T: only GPIO3 (Pin11 / SCL),"},{"line_number":76,"context_line":"\tGPIO4 (Pin15 / ACT), GPIO5 (Pin9 / TRST) and GPIO6 (Pin2 / CTS1) are possible */"},{"line_number":77,"context_line":"#define CH347T_USABLE_GPIOS\t0x78"},{"line_number":78,"context_line":"/* On the CH347F the GPIO\u0027s share the pins with the interface signals: GPIO0 (Pin17),"},{"line_number":79,"context_line":"\tGPIO1 (Pin18), GPIO2 (Pin10), GPIO3 (Pin9 / TRST), GPIO4 (Pin23 / TCK + SWDCLK),"},{"line_number":80,"context_line":"\tGPIO5 (Pin24 / TDO), GPIO6 (Pin25 / TDI), GPIO7 (Pin26 / TMS + SWDIO). GPIO4 to GPIO7"}],"source_content_type":"text/x-csrc","patch_set":3,"id":"7d3d673c_b9a193b0","line":77,"in_reply_to":"75b8de2d_85ca5004","updated":"2026-09-01 17:52:22.000000000","message":"Fair question, and the honest answer is that the mask is not mine. It\ncomes from the original driver, commit 7d0e12589 (\"jtag/drivers: Add\nsupport for CH347-based JTAG adapters\"), where it was USEABLE_GPIOS 0x78\nwith the comment \"mask which GPIO\u0027s are available in mode 3 of CH347T\nonly GPIO3 (Pin11 / SCL), GPIO4 (Pin15 / ACT), GPIO5 (Pin9 / TRST) and\nGPIO6 (Pin2 / CTS1) are possible. Tested only with CH347T not CH347F\nchip.\" This change only renames it to CH347T_USABLE_GPIOS and puts the\nCH347F mask beside it; it does not revisit which CH347T pins are in it.\nEasyDevKits would know where the original list came from.\n\nI did measure it, though, on a CH347T in mode 3, chip version 5.44, using\n\u0027ch347 gpio\u0027 from the follow up change. For every GPIO I checked the\ntransport before driving, while holding it low, while holding it high and\nafter releasing it with \u0027z\u0027, five reads in each phase:\n\n  SWD, DP IDR reads:\n    gpio 0     before 5/5   low 5/5   high 5/5   released 0/5\n    gpio 1     before 5/5   low 5/5   high 5/5   released 5/5\n    gpio 2     before 5/5   low 5/5   high 5/5   released 5/5\n    gpio 3..7  5/5 in every phase\n\n  JTAG, scan chain interrogation:\n    gpio 0..7  5/5 in every phase\n\nTwo things surprised me:\n\n- GPIO0 survives being driven, but kills SWD as soon as it is released\n  with \u0027z\u0027. Driving leaves the pin an output and the next SWD packet\n  re-drives it, so nothing shows. GPIO_SET_INPUT leaves it an input and\n  SWCLK cannot be driven any more.\n- In JTAG mode nothing breaks at all, because the JTAG path sends a pin\n  byte with every transfer, which re-establishes the interface pins right\n  after a GPIO write to a shared pin.\n\nThat second effect is probably also why GPIO2 looks harmless above even\nthough it should be SWDIO: the SWD engine sets the SWDIO direction per\nphase anyway, so a stale GPIO setting gets overridden. I would not read\nmy GPIO2 row as evidence that the pin is free.\n\nSo on my board only GPIO0 is provably harmful, and only in SWD. Still, I\ndo not think this is enough to widen the mask here:\n\n- The test only shows the transport survives a handful of toggles. It\n  says nothing about signal integrity on a physically shared pin, and the\n  activity LED toggles far more often than my test does.\n- GPIO1 reads back low whatever I drive, so something on my board holds\n  it, presumably the target through TDO. That makes my board a poor\n  witness for GPIO1 in particular.\n- The mask also guards \u0027adapter gpio led\u0027, and the LED is configured in\n  both transports while SRST is configured only for SWD. So anything\n  added to the mask has to be safe in JTAG mode too, where GPIO1 really\n  is TDO.\n- Your own RTS1 point shows the mask depends on what else is enabled,\n  which the driver cannot see.\n\nWould you mind settling the mask in a separate change? This one is about\nSRST and leaves the CH347T mask exactly as it was. I am happy to write\nthat follow up and to repeat the sweep under whatever extra conditions\nyou want, UART1 active for instance.","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"65d7a08878534ba03c6813c0126c571304c9ef2f","unresolved":true,"context_lines":[{"line_number":1325,"context_line":"\tswitch (drive) {"},{"line_number":1326,"context_line":"\tcase ADAPTER_GPIO_DRIVE_MODE_OPEN_DRAIN:"},{"line_number":1327,"context_line":"\t\treturn level ? GPIO_SET_INPUT : GPIO_SET_L;"},{"line_number":1328,"context_line":"\tcase ADAPTER_GPIO_DRIVE_MODE_OPEN_SOURCE:"},{"line_number":1329,"context_line":"\t\treturn level ? GPIO_SET_H : GPIO_SET_INPUT;"},{"line_number":1330,"context_line":"\tcase ADAPTER_GPIO_DRIVE_MODE_PUSH_PULL:"},{"line_number":1331,"context_line":"\t\tbreak;"}],"source_content_type":"text/x-csrc","patch_set":3,"id":"2dbd48f6_73b7ffcc","line":1328,"updated":"2026-09-01 20:23:54.000000000","message":"The open source mode is probably hardly usable due to the undocumented weak pull-up on GPIO. Could you measure it on your board as well?\nDo not fix now. You might warn during GPIO init in the follow up patch.","commit_id":"864445c384142663fa12d45d9195d69cfbd9d1a9"}]}