)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"4cb36c8f51a8ba16ee84a44a86e1356b4d80e8ae","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"1750f903_59e9ec20","updated":"2025-08-04 06:35:10.000000000","message":"Hi, this is an awesome patch! I have an STM32F1 device. Could you tell me how to reproduce the USB host disconnects issue you discovered?","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"4ba151a8040d0ba6aec3100fec17bac12da27ab3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"104193f0_c226acbf","in_reply_to":"01b920aa_b7e13ea7","updated":"2025-08-20 09:12:39.000000000","message":"Thanks!","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"400c0f4d2ded01257f78db63c218921beabbb465","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"3a713b0a_5f6b6ee9","in_reply_to":"023e5569_e565d468","updated":"2025-08-06 03:40:44.000000000","message":"No Thanks, Thank you both for your dedication. your professional insights have contributed to the advancement of the open-source community and the better development of CH347.\nAfter my test, the specific effect of this code is as follows.\n```\nOn CH347T V5.44\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.830145s (192.737 KiB/s)\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.819459s (195.251 KiB/s)\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.841374s (190.165 KiB/s)\n\nOn CH347F V1.1\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.805169s (198.716 KiB/s)\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.808291s (197.949 KiB/s)\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.806774s (198.321 KiB/s)\n```","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"2919c39d7261ee22ebc2e4cb9879a0c24e8e7035","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"dc0e4624_5a620045","in_reply_to":"08bc2e13_aab069b6","updated":"2025-08-20 08:00:48.000000000","message":"ZhiYuanNJ, I set the exact limit and made some improvements in the last patchset. Please re-test.","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"e98139a40489bf376d3e94b4346a7828c5d70f91","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c7b841f2_2522e861","in_reply_to":"1750f903_59e9ec20","updated":"2025-08-04 07:06:11.000000000","message":"I\u0027ve been using a USB analyzer to look at the USB packets. I see that after an OUT packet is sent to the device and the host reads back, the device correctly replies with NAK. You mentioned that if the CH347 takes longer than 16ms to process **but still replies with NAK normally**, could that cause the USB host to disconnect?","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"0ecd3b74b92448956f5d8a8d4bcc9278ce2402d2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6968963a_b60eb7a8","in_reply_to":"3a713b0a_5f6b6ee9","updated":"2025-08-06 09:24:20.000000000","message":"I checked CH347T v 5.44 SWD timing @ clock speeds 1 MHz, 5 MHz and 100 kHz.\nSWCLK and SWDIO traces looks clean without glitches.\nTiming is good. Just @ 1 MHz the clock duty is not 1:1, some log 0 pulses are as short as 225 ns - not ideal, however I hope it will not cause problems.\n\n\u003e 1. Corrected the erroneous SWDIO level duration (392ns);\n\nI confirm this issue is solved in v 5.44\n\n\u003e 2. Increased maximum SWD speed to 5 MHz\n\nGood extension, although the speed selection is still somewhat limited.\n\n\u003e 3. Addressed the host disconnected issue in this patch. Note: Implementing your software modification would restrict SWD speeds in the new firmware.\n\nIt does not seem the USB disconnect issue is solved. Ver 5.44 is little bit better probably due to more time effective SWD processing (and therefore shorted delays in USB servicing). There is no problem @ recommended speeds 1M, 5M and 500k and these speeds are sufficient for most use cases. Unfortunately for some ultra low power targets even lower speeds are necessary. That\u0027s why OpenOCD selected the clock as low as 100 kHz as the default.\n\nIn my test without this patch and with RPi5 as OpenOCD host I haven\u0027t seen USB disconnect @ divisors up to 9. At clocks speed 100 kHz (div 10) disconnect sometimes happens. This behaviour depends on USB host, maybe host speed etc...\n\nWe have a choice here: either block low speeds entirely or use this patch and risk that on some USB hosts the 8 ms processing limit will not be sufficient and USB disconnects trigger at low SWD speeds.\nConsidering we already have this working patch, I vote for including it.\n\nAd to transfer speeds you showed:\nI\u0027m not sure if you mean that they are too low or high enough.\nTo assess the influence of this patch we need to compare transfer with and without the patch at same host, conditions etc... My RPi5 performs little bit better, and the influence of this patch seems negligible, lower than random fluctuation of measuring.\nWithout this patch:\n```\nadapter speed: 5000 kHz\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 0.085552s (233.776 KiB/s)\n\u003e load_image rand_20k.bin 0x20000000\n20480 bytes written at address 0x20000000\ndownloaded 20480 bytes in 0.086308s (231.728 KiB/s)\n```\nWith this patch:\n```\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 0.084510s (236.658 KiB/s)\n\u003e load_image rand_20k.bin 0x20000000\n20480 bytes written at address 0x20000000\ndownloaded 20480 bytes in 0.086381s (231.532 KiB/s)\n```\nAt low clock speed, where this patch enforces using shorter packets, the USB transfer and turnaround times are relatively short so the transfer rate drop is negligible again.\nWithout this patch:\n```\n\u003e adapter speed 112\nadapter speed: 111 kHz\n\u003e load_image /home/vanekt/a/rand_20k.bin 0x20000000\n20480 bytes written at address 0x20000000\ndownloaded 20480 bytes in 2.523036s (7.927 KiB/s)\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 2.523475s (7.926 KiB/s)\n```\nWith this patch:\n```\n\u003e load_image /home/vanekt/a/rand_20k.bin 0x20000000\n20480 bytes written at address 0x20000000\ndownloaded 20480 bytes in 2.527487s (7.913 KiB/s)\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 2.528326s (7.910 KiB/s)\n```","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"352a44b2b993dc1058b05c58bd9e72b8497a2e40","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8732811d_771ba1a0","in_reply_to":"6968963a_b60eb7a8","updated":"2025-08-07 03:51:47.000000000","message":"Based on my previous tests with this patch on CH347T and CH347F adapters working with my STM32F1, I have the following conclusions:\n\n\n1.The transfer rate is largely unaffected by the patch. When setting 5000K, transmission will be faster.\n\n```\nOpen On-Chip Debugger\n\u003e adapter speed 5000                    \nadapter speed: 5000 kHz\ndumped 163840 bytes in 0.961077s (166.480 KiB/s)\n\u003e adapter speed 112                     \nadapter speed: 125 kHz\n\u003e dump_image /dev/null 0x08000000 4096  \ndumped 4096 bytes in 0.484743s (8.252 KiB/s)\n\n// With this patch\n\u003e adapter speed 5000                    \n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.855524s (187.020 KiB/s)\n\u003e adapter speed 112                     \nadapter speed: 111 kHz\n\u003e dump_image /dev/null 0x08000000 4096  \ndumped 4096 bytes in 0.547003s (7.313 KiB/s)\n```\n\n​​2.With​​ the patch applied, my system (x64 Linux + STM32F1) maintains stable operation even at an adapter speed (adapter speed) setting of 30.\n\nIn summary, I suggest incorporating this patch and limit the ```CH347_SWD_CLOCK_MAX_DIVISOR``` value(e.g., 30).","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"ba995931e55e10c86786b6a1f39f63decf218f33","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c905c6a9_66009c12","in_reply_to":"84710343_bd92ca12","updated":"2025-08-05 06:23:16.000000000","message":"Hello, I work closely with CH347 FAE. Thank you for identifying issues in firmware versions 2.41 and 4.41 through [https://review.openocd.org/c/openocd/+/7937/comments/03e2b2d5_f5dbc6bc](https://review.openocd.org/c/openocd/+/7937/comments/03e2b2d5_f5dbc6bc).\n\nThe Newer firmware (v5.44 and above) has resolved multiple critical issues, specifically:\n\n1. Corrected the erroneous SWDIO level duration (392ns);\n2. Increased maximum SWD speed to 5 MHz;\n3. Addressed the host disconnected issue in this patch. **Note: Implementing your software modification would restrict SWD speeds in the new firmware.**\n​​Validation example:​​\n\nUsing native SWD code with CH347T v5.44:\n```\n\u003e dump_image /dev/null 0x08000000 163840\ndumped 163840 bytes in 0.963618s (166.041 KiB/s)\n```\nAdditionally, they plans to progressively optimize the clock rates for CH347_CMD_JTAG_BIT_OPand CH347_CMD_JTAG_BIT_OP_RDcommands, currently operating at ~1 MHz.","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"8263a0dd50f4cad4078094b70957a2482544950e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d7e4628c_31cc9ccd","in_reply_to":"8732811d_771ba1a0","updated":"2025-08-07 07:16:08.000000000","message":"\u003e ​​2.With​​ the patch applied, my system (x64 Linux + STM32F1) maintains stable operation even at an adapter speed (adapter speed) setting of 30.\n\nThanks for testing.\nSo you experienced disconnects at adapter speed 20 kHz, do I understand correctly?\nIn my tests @ RPi5 SWD at 20 kHz was perfectly stable with this patch.\n \n\u003e In summary, I suggest incorporating this patch and limit the ```CH347_SWD_CLOCK_MAX_DIVISOR``` value(e.g., 30).\n\nAlternatively we can warn if selected speed goes under 100 kHz what could happen and let the user find the minimum of his system.\nHowever any low limit under or equal 100 kHz is acceptable.","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"0d54422323b0f76836b71da97c98084ce0527cd3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"84710343_bd92ca12","in_reply_to":"c7b841f2_2522e861","updated":"2025-08-04 09:07:15.000000000","message":"ZhiYuanNJ,\nyou should first introduce yourself. Sorry, I can\u0027t believe you are not employed (or connected other way) with the CH347 chip vendor.\n\nI did not look to USB, I don\u0027t have an analyser capable of USB HS.\nAlso I tested on CH347 4.41, no idea about other versions.\n\nWhat means replies normally? Does it reply immediately after host read back or it first processes SWD payload and then sends a reply? The delay may not be visible on the first packet, it may need to fill some buffers etc...\n\nAnyway it fails similarly on 2 linux USB hosts. Today I tested is on RPi 5:\nWithout this patch, git checkout of this patch parent, 37814212d97c794532d320ce326c575f958e0782\n```\nopenocd -c \u0027adapter driver ch347;transport select swd\u0027 -f ~/o/tcl/target/stm32f1x.cfg\nOpen On-Chip Debugger 0.12.0+dev-00838-g37814212d (2025-08-04-09:39)\n...\nInfo : CH347 EasyDevKit from vendor EasyDevKits with serial number ACBACJGAAF found. (Chip version\u003d4.41, Firmware\u003d0x41)\n...\n\u003e adapter speed 250\nadapter speed: 250 kHz\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 1.148490s (17.414 KiB/s)\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 1.148678s (17.411 KiB/s)\n\u003e adapter speed 125\nadapter speed: 125 kHz\n\u003e dump_image /dev/null 0x20000000 0x5000\nlibusb_bulk_read error: LIBUSB_ERROR_IO\nCH347 read fail\nlibusb_bulk_write error: LIBUSB_ERROR_NO_DEVICE\nCH347 write fail\nlibusb_bulk_write error: LIBUSB_ERROR_NO_DEVICE\nCH347 write fail\n```\n\nUnfortunately to fix it on RPi 5 we now need to set the shorter time limit `CH347_MAX_PROCESSING_US 8000` to prevent the disconnects - this is what I feared of - the limit depends on host and changed probably after a linux kernel update.\n```\nOpen On-Chip Debugger 0.12.0+dev-00839-g5d0bd104b-dirty (2025-08-04-10:57)\n...\n\u003e adapter speed 125\nadapter speed: 125 kHz\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 2.282192s (8.764 KiB/s)\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 2.283063s (8.760 KiB/s)\n\u003e adapter speed 63\nadapter speed: 63 kHz\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 4.548574s (4.397 KiB/s)\n\u003e adapter speed 20\nadapter speed: 20 kHz\n\u003e dump_image /dev/null 0x20000000 0x5000\ndumped 20480 bytes in 14.218256s (1.407 KiB/s)\n```","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"0a383ca880572f552dbaff8b2428e8fbc46308a4","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f0988ea1_bdc429cb","in_reply_to":"c905c6a9_66009c12","updated":"2025-08-05 09:19:40.000000000","message":"Hello ZhiYuanNJ,\ndo you know if the firmware of CH347 can be updated on existing devices?","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"8b62a5ff8e6bddbf9a459c6673ed06a522b2ff12","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"023e5569_e565d468","in_reply_to":"d40a70ed_857ca5ef","updated":"2025-08-05 20:09:07.000000000","message":"Good question, Antonio.\nZhiYuanNJ, thanks for arranging contact with FAE. I received the email with a linux based updater. Update to ver 5.44 worked and I updated my SWD patches for the new version.\n\nI didn\u0027t have time to look at logic analyser traces - I\u0027ll do tomorrow.","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"076ad3e50cc85acace911456a96f204eba8d4159","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"08bc2e13_aab069b6","in_reply_to":"d7e4628c_31cc9ccd","updated":"2025-08-07 07:30:56.000000000","message":"Yes, once the adapter speed falls below 30, it will experience disconnections.","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"1db93bcb5cfa3d642c62055bf906ac4a421bd94c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"01b920aa_b7e13ea7","in_reply_to":"dc0e4624_5a620045","updated":"2025-08-20 08:45:11.000000000","message":"Hi Tomas, the new patchset is running normally in my environment.","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1002199,"name":"ZhiYuanNJ","display_name":" ZhiYuanNJ","email":"871238103@qq.com","username":"ZhiYuanNJ"},"change_message_id":"cc667dc337b53365d59931ed4ebbe81588216bd1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d40a70ed_857ca5ef","in_reply_to":"f0988ea1_bdc429cb","updated":"2025-08-05 10:34:43.000000000","message":"​​I have contacted the manufacturer\u0027s FAE, and they have sent the email(vanekt@fbl.cz) to you.​","commit_id":"5d0bd104ba2b9f4a0bb62a0d0be04d8a837145fa"},{"author":{"_account_id":1000160,"name":"Paul Fertser","email":"fercerpav@gmail.com","username":"pfertser"},"change_message_id":"b6c67d6a66f9f6ab38e161d61281edb41d0317bc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"11a30161_7e7ca11f","updated":"2025-08-19 23:37:03.000000000","message":"There was a problem with CI earlier today due to unattended upgrade of JDK: https://bugs.openjdk.org/browse/JDK-8352489 .\nI\u0027ve rerun the build and now it\u0027s showing a legit problem it seems.","commit_id":"79cedf34a00405e4b34e03fe23f5db5f6e067998"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"75e29360a6ad4425bedecb936c909c0d2fe6744f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"b353953d_ef0a7203","in_reply_to":"11a30161_7e7ca11f","updated":"2025-08-20 07:16:07.000000000","message":"Thanks Paul!","commit_id":"79cedf34a00405e4b34e03fe23f5db5f6e067998"}]}