)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"4134e793f0293a147838559f6f2600774db91368","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"97bd3336_303d1d11","updated":"2021-09-06 20:00:47.000000000","message":"Michael,\nyou wrote in the review of https://review.openocd.org/c/openocd/+/6527\n\n\u003e Mixing STM32 and GD32 part IDs looks messy\n\nBut the proposed gd32 driver handles just GD32E230 and other GigaDevice MCUs (GD32F1x0 and GD32F1x0) are handled by stm32f1x?! It looks as much bigger mess...\n\nThe idea of separate gd32 driver is good. We should consider support for most of GD32 family members, maybe even GD32VF103 with RISC-V - see https://review.openocd.org/q/gd32vf103\n\nOne drawback of the separate gd32 support came to my mind: some cheap chinese boards/gadgets may pretend they have STM32 MCU installed - but under sticker or EMC shield sits cheaper GD32 equivalent. Or some series have STM32, others GD32. In such case autodetection helps a lot as the user simply cannot know what vendor should be configured.","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"19a34550455ad2d42f47fdd59adc5f514890b457","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"fbb9f1ab_9d4158e2","updated":"2021-09-14 13:10:11.000000000","message":"You can add this lines to startup.tcl file:\n\n# gd32e23x uses the same flash driver as the stm32f1x\nproc gd32e23x args { eval stm32f1x $args }\n\nAll stm32 microcontrollers that use stm32f1x driver like e.g. stm3f0x can use aliases adequate to its names. Connecting via telnet to openocd you can type\ngd32e23x mass_erase 0\ninstead of\nstm32f1x mass_erase 0\n","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"7054fb084da2a8f1a1014cdf8cdab7beeb5ca61c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6489db96_ac3dafbc","in_reply_to":"611524ee_8e4c23ad","updated":"2021-09-07 11:19:38.000000000","message":"Your idea to separate is very good. I can test it on GD32F130 and GD32E230.\nBoth this series uses the same device_id so you must use revision_id to identify them:\n\ncase 0x410:\n\t\tpage_size \u003d 1024;\n\t\tstm32x_info-\u003eppage_size \u003d 4;\n\t\tmax_flash_size_in_kb \u003d 128;\n\t\tswitch (rev_id) {\n\t\tcase 0x1303: /* gd32f1x0 */\n\t\t\tstm32x_info-\u003euser_data_offset \u003d 16;\n\t\t\tstm32x_info-\u003eoption_offset \u003d 6;\n\t\t\tmax_flash_size_in_kb \u003d 64;\n\t\t\tbreak;\n\t\tcase 0x1704: /* gd32f3x0 */\n\t\t\tstm32x_info-\u003euser_data_offset \u003d 16;\n\t\t\tstm32x_info-\u003eoption_offset \u003d 6;\n\t\t\tbreak;\n\t\tcase 0x1909: /* gd32e23x */\n\t\t\tstm32x_info-\u003euser_data_offset \u003d 16;\n\t\t\tstm32x_info-\u003eoption_offset \u003d 6;\n\t\t\tmax_flash_size_in_kb \u003d 64;\n\t\t\tbreak;\n\t\t}\n\t\tbreak;\n\nRemember to set user_data_offset and option_offset (other then typical for STM32). Everything works fine, but after microcontroller lock and then unlock some bits are are not good configured. When you try to upload firmware, active hardware watchog (normally set to software) will break programming without any warning.. The same problem is when you debugging such \"broken\" microcontroller.\nIn the futere you can also add very popular GD32F103 microcontroller (clone of STM32F103), tahat now works fine without any patch.","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"294063daf4eb2e3ce7e580a38b4859e90e5e9ca7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"03a109f3_41082aa8","in_reply_to":"6489db96_ac3dafbc","updated":"2021-09-07 18:57:43.000000000","message":"Thanks,\nI just pushed a new version of the patch series which moves the gd32f1x0 and gd32f3x0 over to the gd32 driver. I have tested on GD32E230, tests on other devices are appreciated!","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"cc668ff0d13709e12e2f6f9f89fefa789bd551a3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"aba6d1ae_f0b67b82","in_reply_to":"8786c709_e15f75d3","updated":"2021-09-15 10:22:33.000000000","message":"\u003e I think you should use \"gd32\" not \"stm32f1x\" in tcl file because driver name is changed :)\n\nAfter compilation and checks it must be stm32f1x driver (not gd32)!","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"add2598810c6300b6ab331a8d5e2d464dcb9fa7d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"611524ee_8e4c23ad","in_reply_to":"97bd3336_303d1d11","updated":"2021-09-07 08:11:44.000000000","message":"Yes, that definitely needs to be cleaned up. The GD32F1* stuff was added into master while I was already working on my patch - I was planning to clean this up in a separate patch, since I don\u0027t have hardware to test. I\u0027ll do that and add it to this patch as a separate commit.\nI am not convinced auto-detection is workable as more parts are added.","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"cadfc4150650a65ea9739808553f42e1583bffbf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"80e3f582_3b3c588d","in_reply_to":"aba6d1ae_f0b67b82","updated":"2021-09-16 05:49:48.000000000","message":"Done","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"c9249a14f82936d562c645400e4610dd10c72751","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8786c709_e15f75d3","in_reply_to":"fbb9f1ab_9d4158e2","updated":"2021-09-14 13:18:30.000000000","message":"I think you should use \"gd32\" not \"stm32f1x\" in tcl file because driver name is changed :)","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"c8e2ed5fdfe9870518a770672536906032faaf3f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"36a86c9b_cfb32985","updated":"2021-09-15 19:44:08.000000000","message":"You forget about enabling RCU debug clock in target config file. Probably only GD32E230 in the GD32 family has this feature. When you use watchdog in your code, during step debug microcontroller restarts due to watchdog even if it is blocked in config file! FWDGT_HOLD bit (and others bits in DBG_CTL0) works only if debug clock is enabled.","commit_id":"60f95c1fda108a4882bef1cb60ba239c74992c1d"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"cadfc4150650a65ea9739808553f42e1583bffbf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1ca0b0be_9e6651d0","in_reply_to":"36a86c9b_cfb32985","updated":"2021-09-16 05:49:48.000000000","message":"Done","commit_id":"60f95c1fda108a4882bef1cb60ba239c74992c1d"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"2bd906b0af1a61152afae536d5d322940d489d3a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"820747a2_07297bbb","in_reply_to":"36a86c9b_cfb32985","updated":"2021-09-18 08:10:45.000000000","message":"Thanks. I was *sure* I saved that change, but apparently it got lost. Will push #4.","commit_id":"60f95c1fda108a4882bef1cb60ba239c74992c1d"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"c29a9e32a1c3ab1a273dcb085400b68ebe54593a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"6a7ec70b_f1205920","updated":"2021-11-08 06:27:58.000000000","message":"Michael, Andrzej, I\u0027m afraid this change and #6552 is not ready to be merged before 0.12 rc is tagged.\n\nI see the main problem of this approach that it forces users to distinguish between ST32-fully compatible GD32 devices (which are handled by st32f1x driver) and GD32 specific devices, handled by gd32 driver.\n\nIf we want GD32E230 support in 0.12, please let\u0027s consider returning to Andrzej\u0027s #6527. Then we can eventually continue on gd32 specific driver.","commit_id":"bcf2e838893106b76c7238ec86d7f29377bbfee5"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"cc9b09ce924c6ed7700e9f3ec52cae71a7b6dfd7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"e3499440_26f7b258","in_reply_to":"67749eab_4bdeb8e6","updated":"2021-12-01 09:41:59.000000000","message":"\u003e In the meantime I added support for RISC-V GD32VF103. The flash is perfectly compatible to STM32F103, automatic detection easy.\n\u003e I\u0027ve seen your 6733: quick hack: add MindMotion MM32L062 support | https://review.openocd.org/c/openocd/+/6733\n\u003e I also raised an old change 5269: flash/stm32f1x: support for AT32F403 microcontroller. | https://review.openocd.org/c/openocd/+/5269\n\u003e \n\u003e So if I count correctly we currently have 3 candidates for a new driver (GD, MM, AT). In such count even the \"thin wrapper\" is not as thin as we would need.\n\nAgreed. With the MindMotion parts using different addresses, we would need multiple wrappers - this gets ugly.\n\n\u003e What about adding a parameter to describe the clone? I know, the 8th positional parameter is real headache - the rework of positional parameters to -option based syntax is on my TODO list (and has been there for long time).\n\u003e \n\u003e Let\u0027s imagine in the future syntax we would use\n\u003e  flash bank .... -clone any\n\nThis sound good. I would call it \"variant\" instead of \"clone\".\n\n\u003e to enable all clone hacks\n\u003e or explicitly set the vendor of the clone\n\u003e  flash bank .... -clone gd\n\u003e \n\u003e The code would use the new parameter as a hint.\n\u003e What do you think?\n\nI don\u0027t like the \"hint\" concept. I think when a clone type is specified, the code should only detect that specified variant. That way, for STM parts nothing changes, and for MM32 the code can directly read the correct registers without relying on undefined behaviour.\n\nI am not sure how to handle parts that can be auto-detected currently (like GD32E230) - the quick way would be to keep them in the STM code path (without specifying a clone/variant). The clean way would be to specify a GD32 variant in the config file, and pull them out of the ST code path, so that the part id namespaces are separate. I would prefer the second approach, because it makes it easier to understand what code parts are relevant for each device, but the first (like the current GD32E230 support in master) is OK, too.","commit_id":"bcf2e838893106b76c7238ec86d7f29377bbfee5"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"7832194b7bbf669c98b96bb2c2d939cd34419b24","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"f378db41_d5b8f225","in_reply_to":"6a7ec70b_f1205920","updated":"2021-11-08 10:53:06.000000000","message":"First, I am fine with both solutions.\nHowever: what would be the purpose of a separate GD32 driver if we choose #6527? Any future GD32 driver will have the same downside (separate drivers, users need to know which one to use) as the current patch, so i don\u0027t see why this would be better in the future?","commit_id":"bcf2e838893106b76c7238ec86d7f29377bbfee5"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"eb8c02014b6296e737b3874710e6658988149ab1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"d3ddae23_4fded228","in_reply_to":"e3499440_26f7b258","updated":"2021-12-01 10:06:41.000000000","message":"\u003e I am not sure how to handle parts that can be auto-detected currently (like GD32E230) - the quick way would be to keep them in the STM code path (without specifying a clone/variant). The clean way would be to specify a GD32 variant in the config file, and pull them out of the ST code path, so that the part id namespaces are separate. I would prefer the second approach, because it makes it easier to understand what code parts are relevant for each device, but the first (like the current GD32E230 support in master) is OK, too.\n\nFor me second approach is more clear. Now basic functionality works and some users like me are happy, but GigaDevice microcontrollers has some more flash configuration options that can be included in quite new dedicated file.","commit_id":"bcf2e838893106b76c7238ec86d7f29377bbfee5"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"305224f92eca3211b7d7341b3e12693a5594c68c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"67749eab_4bdeb8e6","in_reply_to":"f378db41_d5b8f225","updated":"2021-11-30 20:54:14.000000000","message":"Michael, let\u0027s continue out discussion.\n\nIn the meantime I added support for RISC-V GD32VF103. The flash is perfectly compatible to STM32F103, automatic detection easy.\nI\u0027ve seen your 6733: quick hack: add MindMotion MM32L062 support | https://review.openocd.org/c/openocd/+/6733\nI also raised an old change 5269: flash/stm32f1x: support for AT32F403 microcontroller. | https://review.openocd.org/c/openocd/+/5269\n\nSo if I count correctly we currently have 3 candidates for a new driver (GD, MM, AT). In such count even the \"thin wrapper\" is not as thin as we would need.\nWhat about adding a parameter to describe the clone? I know, the 8th positional parameter is real headache - the rework of positional parameters to -option based syntax is on my TODO list (and has been there for long time).\n\nLet\u0027s imagine in the future syntax we would use\n flash bank .... -clone any\n\nto enable all clone hacks\nor explicitly set the vendor of the clone\n flash bank .... -clone gd\n\nThe code would use the new parameter as a hint.\nWhat do you think?","commit_id":"bcf2e838893106b76c7238ec86d7f29377bbfee5"}],"tcl/board/gd32e230-start.cfg":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"e178bed51f066181ec1d444b5b30c38955cbc759","unresolved":true,"context_lines":[{"line_number":1,"context_line":"source [find interface/cmsis-dap.cfg]"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"transport select swd"},{"line_number":4,"context_line":""}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"c0ae9d96_350c6bf3","line":1,"updated":"2021-09-17 14:13:54.000000000","message":"Use SPDX","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"c043f93c3b76beea23660b9b5e421cc4ae6234ba","unresolved":false,"context_lines":[{"line_number":1,"context_line":"source [find interface/cmsis-dap.cfg]"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"transport select swd"},{"line_number":4,"context_line":""}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"51e34a7a_d97ce831","line":1,"in_reply_to":"2650f78e_a07912d4","updated":"2021-10-03 15:18:17.000000000","message":"Ack","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"2bd906b0af1a61152afae536d5d322940d489d3a","unresolved":true,"context_lines":[{"line_number":1,"context_line":"source [find interface/cmsis-dap.cfg]"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"transport select swd"},{"line_number":4,"context_line":""}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"2650f78e_a07912d4","line":1,"in_reply_to":"c0ae9d96_350c6bf3","updated":"2021-09-18 08:10:45.000000000","message":"This is getting ridiculous. The points you address are literal copies from other files (stm32f0x.cfg) in master.\n\nThis is the reason I stopped submitting patches for u-boot: when newly submitted code is is subjected to a different standard than existing in-tree code, while no-one bothers to clean up the existing stuff. When I can\u0027t use existing code as a guide, the effort to get a patch accepted grows exponentially. At some point, it is less effort to maintain local patches.","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"}],"tcl/target/gd32e23x.cfg":[{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"cc668ff0d13709e12e2f6f9f89fefa789bd551a3","unresolved":true,"context_lines":[{"line_number":34,"context_line":"if { [info exists CPUTAPID] } {"},{"line_number":35,"context_line":"   set _CPUTAPID $CPUTAPID"},{"line_number":36,"context_line":"} else {"},{"line_number":37,"context_line":"   set _CPUTAPID 0x0bb11477"},{"line_number":38,"context_line":"}"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID"}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"6d8b088a_cb9eeac7","line":37,"range":{"start_line":37,"start_character":17,"end_line":37,"end_character":27},"updated":"2021-09-15 10:22:33.000000000","message":"Are you sure it is 0x0bb11477?\nMy production GD32E230C8T6 microcontrollers has CPU ID 0x0bf11477 and only with this ID all works.\nMaybe your ID on devkit is from old pre-production time.","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"cadfc4150650a65ea9739808553f42e1583bffbf","unresolved":false,"context_lines":[{"line_number":34,"context_line":"if { [info exists CPUTAPID] } {"},{"line_number":35,"context_line":"   set _CPUTAPID $CPUTAPID"},{"line_number":36,"context_line":"} else {"},{"line_number":37,"context_line":"   set _CPUTAPID 0x0bb11477"},{"line_number":38,"context_line":"}"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID"}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"50a52f16_a86c06b7","line":37,"range":{"start_line":37,"start_character":17,"end_line":37,"end_character":27},"in_reply_to":"6d8b088a_cb9eeac7","updated":"2021-09-16 05:49:48.000000000","message":"Done","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"19a34550455ad2d42f47fdd59adc5f514890b457","unresolved":true,"context_lines":[{"line_number":68,"context_line":"}"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"proc gd32e23x_default_examine_end {} {"},{"line_number":71,"context_line":"\t# Enable debug during low power modes (uses more power), stop watchdog counters during halt"},{"line_number":72,"context_line":"\tmmw 0x40015804 0x00000037 0 ;# DBG_CTL0 |\u003d WWDGT_HOLD | FWDGT_HOLD | STB_HOLD | DSLP_HOLD | SLP_HOLD"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"\t#mmw 0x40015808 0x00000000 0 ;# DBG_CTL1 |\u003d ..."}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"eafa1e02_e80dd4b6","line":71,"updated":"2021-09-14 13:10:11.000000000","message":"Insert here this command that enables Debug clock (only in this microntroller). Without this watchdog disabling doesn\u0027t work.\n\n\t# Debug clock enable\n\t# RCU_APB2EN |\u003d DBGMCUEN\n\tmmw 0x40021018 0x00400000 0","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"cadfc4150650a65ea9739808553f42e1583bffbf","unresolved":false,"context_lines":[{"line_number":68,"context_line":"}"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"proc gd32e23x_default_examine_end {} {"},{"line_number":71,"context_line":"\t# Enable debug during low power modes (uses more power), stop watchdog counters during halt"},{"line_number":72,"context_line":"\tmmw 0x40015804 0x00000037 0 ;# DBG_CTL0 |\u003d WWDGT_HOLD | FWDGT_HOLD | STB_HOLD | DSLP_HOLD | SLP_HOLD"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"\t#mmw 0x40015808 0x00000000 0 ;# DBG_CTL1 |\u003d ..."}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"1f6df077_75c677b7","line":71,"in_reply_to":"eafa1e02_e80dd4b6","updated":"2021-09-16 05:49:48.000000000","message":"Done","commit_id":"a3d066ab94637caed5cbff908890c0b81b36ec45"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"e178bed51f066181ec1d444b5b30c38955cbc759","unresolved":true,"context_lines":[{"line_number":1,"context_line":"# script for GD32E23x family"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"#"},{"line_number":4,"context_line":"# gd32 devices support SWD transports only."}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"03f67c62_3f01b949","line":1,"range":{"start_line":1,"start_character":0,"end_line":1,"end_character":28},"updated":"2021-09-17 14:13:54.000000000","message":"Please read my comments https://review.openocd.org/c/openocd/+/6527/4/tcl/target/gd32e23x.cfg\nThey are relevant here as well","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"c043f93c3b76beea23660b9b5e421cc4ae6234ba","unresolved":false,"context_lines":[{"line_number":1,"context_line":"# script for GD32E23x family"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"#"},{"line_number":4,"context_line":"# gd32 devices support SWD transports only."}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"bf9c68dc_650b5f93","line":1,"range":{"start_line":1,"start_character":0,"end_line":1,"end_character":28},"in_reply_to":"03f67c62_3f01b949","updated":"2021-10-03 15:18:17.000000000","message":"Ack","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"e178bed51f066181ec1d444b5b30c38955cbc759","unresolved":true,"context_lines":[{"line_number":12,"context_line":"   set _CHIPNAME gd32e23x"},{"line_number":13,"context_line":"}"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"set _ENDIAN little"},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"# Work-area is a space in RAM used for flash programming"},{"line_number":18,"context_line":"# By default use 4kB"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"fb1d9056_75458175","line":15,"range":{"start_line":15,"start_character":0,"end_line":15,"end_character":18},"updated":"2021-09-17 14:13:54.000000000","message":"Remove, Cortex-M has no configurable endianess","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"c043f93c3b76beea23660b9b5e421cc4ae6234ba","unresolved":false,"context_lines":[{"line_number":12,"context_line":"   set _CHIPNAME gd32e23x"},{"line_number":13,"context_line":"}"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"set _ENDIAN little"},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"# Work-area is a space in RAM used for flash programming"},{"line_number":18,"context_line":"# By default use 4kB"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"e80450e7_3e153ffe","line":15,"range":{"start_line":15,"start_character":0,"end_line":15,"end_character":18},"in_reply_to":"fb1d9056_75458175","updated":"2021-10-03 15:18:17.000000000","message":"Ack","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"e178bed51f066181ec1d444b5b30c38955cbc759","unresolved":true,"context_lines":[{"line_number":41,"context_line":"dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"set _TARGETNAME $_CHIPNAME.cpu"},{"line_number":44,"context_line":"target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"5b1cbf4a_0fba665a","line":44,"range":{"start_line":44,"start_character":36,"end_line":44,"end_character":52},"updated":"2021-09-17 14:13:54.000000000","message":"Remove","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"c043f93c3b76beea23660b9b5e421cc4ae6234ba","unresolved":false,"context_lines":[{"line_number":41,"context_line":"dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"set _TARGETNAME $_CHIPNAME.cpu"},{"line_number":44,"context_line":"target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"6c5a94df_52dd2631","line":44,"range":{"start_line":44,"start_character":36,"end_line":44,"end_character":52},"in_reply_to":"5b1cbf4a_0fba665a","updated":"2021-10-03 15:18:17.000000000","message":"Ack","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"e178bed51f066181ec1d444b5b30c38955cbc759","unresolved":true,"context_lines":[{"line_number":49,"context_line":"set _FLASHNAME $_CHIPNAME.flash"},{"line_number":50,"context_line":"flash bank $_FLASHNAME gd32 0x08000000 $_FLASH_SIZE 0 0 $_TARGETNAME"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"# adapter speed should be \u003c\u003d F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG \u003d 1MHz"},{"line_number":53,"context_line":"adapter speed 1000"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"adapter srst delay 100"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"dbc6bc06_786eece4","line":52,"range":{"start_line":52,"start_character":2,"end_line":52,"end_character":85},"updated":"2021-09-17 14:13:54.000000000","message":"No, this rule is valid for JTAG only.\nSWD is not internally synchronised to CPU clock, so it can work as high as F_CPU*10\n(of course other hw limits may apply)\n\nConsider not to set adapter speed here nor in reset hooks. This method is necessary for JTAG and/or really slow clock after reset (100 kHz or so). CPU at 8 MHz and SWD only is quite a different performer.\nLet board/user config to set adapter speed instead.","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"e0dcec9960d5f15e0636cf7f71fe1563bb731b2b","unresolved":true,"context_lines":[{"line_number":49,"context_line":"set _FLASHNAME $_CHIPNAME.flash"},{"line_number":50,"context_line":"flash bank $_FLASHNAME gd32 0x08000000 $_FLASH_SIZE 0 0 $_TARGETNAME"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"# adapter speed should be \u003c\u003d F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG \u003d 1MHz"},{"line_number":53,"context_line":"adapter speed 1000"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"adapter srst delay 100"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"c5e8f16b_45eace95","line":52,"range":{"start_line":52,"start_character":2,"end_line":52,"end_character":85},"in_reply_to":"c0837f6f_40a05329","updated":"2021-11-05 23:31:06.000000000","message":"\u003e That does not work. If I do not set adapter speed at all...\n\nOne may prefer to set adapter speed in a board config (if a debug adapter\nresides on-board) or in user config/on command line.\nOnly if the clock frequency should be low due to a chip specific limit,\nthen it should go to target config.\n\n\u003e openocd fails to startup (cmsis_dap_cmd_dap_swj_clock(): CMSIS-DAP command CMD_DAP_SWJ_CLOCK failed).\n\nYes, this is annoying: the default adapter speed 0 means adaptive clocking (RTCK) which is AFAIK never used with SWD. It would be easier if OpenOCD sets some reasonable adapter speed if RTCK is not available.\n\n\u003e I\u0027ll use 72MHz as a safe default now.\n\nAre you joking? It\u0027s not safe, it\u0027s quite insane!\nAs I wrote before: other hw limits may apply. Unfortunately ST keep SWD timing in secret until STM32H7 series. And guess what, incomparably faster STM32H745 has max SWCLK freq 71 MHz 😊 (and only 52.5 MHz over Vdd range).\nBTW how did you test it? Does your adapter really output such frequency? I bet it does not, ordinary CMSIS-DAP stays below 10 MHz even if you request adapter speed 1000000.\nIf you want a safe default, let\u0027s use 4000 kHz - it is safe for good cabling and a good adapter can provide this speed. And if somebody complains it\u0027s too slow? He may speed up on his own risk.","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"70be425bd6048ba476d3f5a13f732961c1865647","unresolved":false,"context_lines":[{"line_number":49,"context_line":"set _FLASHNAME $_CHIPNAME.flash"},{"line_number":50,"context_line":"flash bank $_FLASHNAME gd32 0x08000000 $_FLASH_SIZE 0 0 $_TARGETNAME"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"# adapter speed should be \u003c\u003d F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG \u003d 1MHz"},{"line_number":53,"context_line":"adapter speed 1000"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"adapter srst delay 100"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"f83bef2e_29e86925","line":52,"range":{"start_line":52,"start_character":2,"end_line":52,"end_character":85},"in_reply_to":"c5e8f16b_45eace95","updated":"2021-11-07 12:28:22.000000000","message":"Please make up your mind what you want. You wanted no default speed set in the target config, and 72MHz does just that - it sets no practical limit, but makes the default config work (since 72MHz is the maximum core clock speed, it should be a safe guess for an upper bound that does not limit chip operation).\n\nIf a lower chip-specific limit turns up later (the datasheet does not specify anything), we can modify the value. Until then, your 4MHz is just as arbitrarily guessed as the 1MHz default I originally used, and which you complained about.\n\nI do not really care what value we use - 1MHz or 4MHz work fine for normal use, but I want the default config to work, without telling the user \"sorry, we have not provided a default, so to use the provided config files, you have to modify them or pass an additional commandline argument\".","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"c043f93c3b76beea23660b9b5e421cc4ae6234ba","unresolved":false,"context_lines":[{"line_number":49,"context_line":"set _FLASHNAME $_CHIPNAME.flash"},{"line_number":50,"context_line":"flash bank $_FLASHNAME gd32 0x08000000 $_FLASH_SIZE 0 0 $_TARGETNAME"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"# adapter speed should be \u003c\u003d F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG \u003d 1MHz"},{"line_number":53,"context_line":"adapter speed 1000"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"adapter srst delay 100"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"c0837f6f_40a05329","line":52,"range":{"start_line":52,"start_character":2,"end_line":52,"end_character":85},"in_reply_to":"dbc6bc06_786eece4","updated":"2021-10-03 15:18:17.000000000","message":"That does not work. If I do not set adapter speed at all, openocd fails to startup (cmsis_dap_cmd_dap_swj_clock(): CMSIS-DAP command CMD_DAP_SWJ_CLOCK failed). I\u0027ll use 72MHz as a safe default now.","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000843,"name":"Michael Schwingen","email":"michael@schwingen.org","username":"mschwingen2"},"change_message_id":"7832194b7bbf669c98b96bb2c2d939cd34419b24","unresolved":false,"context_lines":[{"line_number":49,"context_line":"set _FLASHNAME $_CHIPNAME.flash"},{"line_number":50,"context_line":"flash bank $_FLASHNAME gd32 0x08000000 $_FLASH_SIZE 0 0 $_TARGETNAME"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"# adapter speed should be \u003c\u003d F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG \u003d 1MHz"},{"line_number":53,"context_line":"adapter speed 1000"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"adapter srst delay 100"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"d21e44a1_0878174c","line":52,"range":{"start_line":52,"start_character":2,"end_line":52,"end_character":85},"in_reply_to":"f80d55cb_2fefce11","updated":"2021-11-08 10:53:06.000000000","message":"\u003e \u003e Please make up your mind what you want.\n\u003e \n\u003e Sorry Michael, I\u0027m sure I\u0027m consistent in refusing unnecessary parts of config and nonsenses.\n\u003e \n\u003e \u003e You wanted no default speed set in the target config, and 72MHz does just that - it sets no practical limit\n\u003e \n\u003e Absolutely not.\n\u003e 1) Some adapter or its driver may refuse such speed as insane high.\n\nI would consider that a bug in the adapter driver - the documentation states that \"The speed actually used won’t be faster than the speed specified\", so this means the adapter should choose the next lower supported speed setting.\n\n\u003e \u003e the 1MHz default I originally used, and which you complained about.\n\u003e \n\u003e Never did. I complained about the JTAG rule to get this speed from F_CPU.\n\nOK, it seems I misunderstood you there.\n\n\u003e And remember the adapter speed was boosted to 8000 in reset_init handler.\n\u003e That\u0027s why I proposed 4000 as a compromise.\n\nSo we could keep 1000 as a safe value, and change the comment to state where it came from?\n\ncu\nMichael","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"tomas.vanek.oocd@gmail.com","username":"vanekt"},"change_message_id":"c29a9e32a1c3ab1a273dcb085400b68ebe54593a","unresolved":true,"context_lines":[{"line_number":49,"context_line":"set _FLASHNAME $_CHIPNAME.flash"},{"line_number":50,"context_line":"flash bank $_FLASHNAME gd32 0x08000000 $_FLASH_SIZE 0 0 $_TARGETNAME"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"# adapter speed should be \u003c\u003d F_CPU/6. F_CPU after reset is 8MHz, so use F_JTAG \u003d 1MHz"},{"line_number":53,"context_line":"adapter speed 1000"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"adapter srst delay 100"}],"source_content_type":"text/x-ttcn-cfg","patch_set":4,"id":"f80d55cb_2fefce11","line":52,"range":{"start_line":52,"start_character":2,"end_line":52,"end_character":85},"in_reply_to":"f83bef2e_29e86925","updated":"2021-11-08 06:27:58.000000000","message":"\u003e Please make up your mind what you want.\n\nSorry Michael, I\u0027m sure I\u0027m consistent in refusing unnecessary parts of config and nonsenses.\n\n\u003e You wanted no default speed set in the target config, and 72MHz does just that - it sets no practical limit\n\nAbsolutely not.\n1) Some adapter or its driver may refuse such speed as insane high.\n2) If an experienced user notice it in cfg we can expect a bug report.\n\n\u003e the 1MHz default I originally used, and which you complained about.\n\nNever did. I complained about the JTAG rule to get this speed from F_CPU.\nAnd remember the adapter speed was boosted to 8000 in reset_init handler.\nThat\u0027s why I proposed 4000 as a compromise.","commit_id":"135e0850ee7242fd546dea4156e5ebcb1624a02b"},{"author":{"_account_id":1001874,"name":"Andrzej Sierżęga","email":"asier70@gmail.com","username":"asier70"},"change_message_id":"52ba3abbebc48582df0a95a78ca501be0c82e850","unresolved":true,"context_lines":[{"line_number":47,"context_line":"# we need to set a speed to avoid startup errors, although there is no chip"},{"line_number":48,"context_line":"# limit on SWD speed"},{"line_number":49,"context_line":"adapter speed 72000"},{"line_number":50,"context_line":"reset_config srst_nogate"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"if {![using_hla]} {"},{"line_number":53,"context_line":"\t# if srst is not fitted use SYSRESETREQ to"}],"source_content_type":"text/x-ttcn-cfg","patch_set":5,"id":"ce9cc7c3_92ee571b","line":50,"range":{"start_line":50,"start_character":0,"end_line":50,"end_character":24},"updated":"2021-10-04 07:36:35.000000000","message":"I think it should be empty line before to separate it.","commit_id":"bcf2e838893106b76c7238ec86d7f29377bbfee5"}]}