)]}'
{"tcl/target/gd32vf103.cfg":[{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"aceda98f3f295838264cfdac6a02587d06213032","unresolved":true,"context_lines":[{"line_number":133,"context_line":"\t# and \u0027timed out while waiting for target halted\u0027 errors"},{"line_number":134,"context_line":"\t# caused probably by writing to dmcontrol in riscv_deassert_reset()"},{"line_number":135,"context_line":"\t# too early after soft reset"},{"line_number":136,"context_line":"\tsleep 10"},{"line_number":137,"context_line":"}"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"# On GD32VF103 the specification\u0027s requirement that each hart is in \"exactly"}],"source_content_type":"text/x-ttcn-cfg","patch_set":1,"id":"5b5c9354_840a2ce1","line":136,"updated":"2025-12-12 22:39:05.000000000","message":"This sleep is long enough to eat the entire reset. With it, everything works fine even if I delete the entire reset-deassert-post handler. Since things break without the sleep, I believe that the reset-deassert-post workaround is not effective at all since the handler runs too late. I don\u0027t know exactly what breaks things, but \"Hart unexpectedly reset\" and \"timed out while waiting for target halted\" are exactly what I see currently on master.\n\nI believe version 3 of https://review.openocd.org/c/openocd/+/9313 is a cleaner solution in the core that won\u0027t break other chips.","commit_id":"9cbdb4fb33d53f9c014d80b679abc551ade9f3c8"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"a17d703b6c0e045e20c7717858324b61821245cb","unresolved":true,"context_lines":[{"line_number":133,"context_line":"\t# and \u0027timed out while waiting for target halted\u0027 errors"},{"line_number":134,"context_line":"\t# caused probably by writing to dmcontrol in riscv_deassert_reset()"},{"line_number":135,"context_line":"\t# too early after soft reset"},{"line_number":136,"context_line":"\tsleep 10"},{"line_number":137,"context_line":"}"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"# On GD32VF103 the specification\u0027s requirement that each hart is in \"exactly"}],"source_content_type":"text/x-ttcn-cfg","patch_set":1,"id":"e31b9a30_eeea65d5","line":136,"in_reply_to":"1463975a_f5315c98","updated":"2025-12-14 10:12:57.000000000","message":"Please test the updated version.\n\nThere is no `sleep`.\nUsing DM `resethaltreq` bit instead of `haltreq` eliminates the need to double reset for `reset halt`.\n\nTested @ adapter speeds 100 and 30000 with both `reset_config none` and `reset_config srst_only`","commit_id":"9cbdb4fb33d53f9c014d80b679abc551ade9f3c8"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"9ab6019de15755b0019ef31afe57578aae786c4c","unresolved":true,"context_lines":[{"line_number":133,"context_line":"\t# and \u0027timed out while waiting for target halted\u0027 errors"},{"line_number":134,"context_line":"\t# caused probably by writing to dmcontrol in riscv_deassert_reset()"},{"line_number":135,"context_line":"\t# too early after soft reset"},{"line_number":136,"context_line":"\tsleep 10"},{"line_number":137,"context_line":"}"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"# On GD32VF103 the specification\u0027s requirement that each hart is in \"exactly"}],"source_content_type":"text/x-ttcn-cfg","patch_set":1,"id":"1463975a_f5315c98","line":136,"in_reply_to":"5b5c9354_840a2ce1","updated":"2025-12-13 08:21:31.000000000","message":"When I wrote \"strange errors\" I was somewhat lazy to give full detail.\nBut the behaviour is really strange and exhibits some internal state.\nI run openocd with ft232h adapter at adapter speed 20000 (intentionally high) and in debug_level 2.\nWithout this `sleep 10` and with added echo to `reset-deassert-post` loop\nI didn\u0027t observed any error in `reset halt` with `reset_config none` and also no waits in `reset-deassert-post`. Tried at least 50 times.\nAfter switch to `reset_config srst_only` there is usually 1-20 good `reset halt` until I get 2 or 3 loops in unavailable state and\n```\nInfo : [gd32vf103.cpu] Hart unexpectedly reset!\nError: timed out while waiting for target halted\n```\nAfter this error all following `reset halt` commands fail similarly and usually\nalso after switching back to `reset_config none`\n\nThe problem is detailed debugging: `debug_level 3` is overly verbose on RISC-V and slows down the process so that no error happens.\n\nI don\u0027t want to waste more time studying the exact behaviour of GD32VF103 buggy DM. I you want to do so please go ahead. I think there is still a very small chance that you catch some bug in OpenOCD riscv target.","commit_id":"9cbdb4fb33d53f9c014d80b679abc551ade9f3c8"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"a67d3cc259c86aefb50fd982eda5347df72935e9","unresolved":false,"context_lines":[{"line_number":133,"context_line":"\t# and \u0027timed out while waiting for target halted\u0027 errors"},{"line_number":134,"context_line":"\t# caused probably by writing to dmcontrol in riscv_deassert_reset()"},{"line_number":135,"context_line":"\t# too early after soft reset"},{"line_number":136,"context_line":"\tsleep 10"},{"line_number":137,"context_line":"}"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"# On GD32VF103 the specification\u0027s requirement that each hart is in \"exactly"}],"source_content_type":"text/x-ttcn-cfg","patch_set":1,"id":"c97c7836_d4c41179","line":136,"in_reply_to":"6ccaa9ed_a236f8a4","updated":"2025-12-16 19:29:46.000000000","message":"Meant to say that I see `timed out while waiting for target halted` for `reset halt`. Copy/paste error.","commit_id":"9cbdb4fb33d53f9c014d80b679abc551ade9f3c8"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"b593bbf19e65bce39a2956e252cf917f544df91e","unresolved":false,"context_lines":[{"line_number":133,"context_line":"\t# and \u0027timed out while waiting for target halted\u0027 errors"},{"line_number":134,"context_line":"\t# caused probably by writing to dmcontrol in riscv_deassert_reset()"},{"line_number":135,"context_line":"\t# too early after soft reset"},{"line_number":136,"context_line":"\tsleep 10"},{"line_number":137,"context_line":"}"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"# On GD32VF103 the specification\u0027s requirement that each hart is in \"exactly"}],"source_content_type":"text/x-ttcn-cfg","patch_set":1,"id":"6ccaa9ed_a236f8a4","line":136,"in_reply_to":"e31b9a30_eeea65d5","updated":"2025-12-16 19:25:27.000000000","message":"Updated version works great (both with and without SRST) and makes sense. Good code cleanups too. Thank you for all your work on this!\n\n\u003e Without this `sleep 10` and with added echo to `reset-deassert-post` loop\nI didn\u0027t observed any error in `reset halt` with `reset_config none` and also no waits in `reset-deassert-post`. Tried at least 50 times.\n\nI can\u0027t reproduce this behavior. I went back to patchset 1, added an echo both before and during the loop in `reset-deassert-post`, and commented out the `sleep 10`. I consistently see the loop print 6 times followed by `Info : [gd32vf103.cpu] Hart unexpectedly reset!` and, for `reset halt`, `Info : [gd32vf103.cpu] Hart unexpectedly reset!`. I\u0027m using an FT2232H (Tigard board) with speed 20000 and debug level 2, just like you. Are you sure you weren\u0027t accidentally running a stale binary with the workaround from https://review.openocd.org/c/openocd/+/9313 when you did that test?\n\nRegardless, this new approach seems to avoid any nondeterminism that may exist. Hopefully it\u0027s the last time either of us will have to think about reset on this chip :)","commit_id":"9cbdb4fb33d53f9c014d80b679abc551ade9f3c8"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"b593bbf19e65bce39a2956e252cf917f544df91e","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"$_TARGETNAME configure -event reset-start {"},{"line_number":69,"context_line":"\tif {$halt} {"},{"line_number":70,"context_line":"\t\tset ctrl [expr {$::dmcontrol_dmactive | $::dmcontrol_setresethaltreq}]"},{"line_number":71,"context_line":"\t} else {"},{"line_number":72,"context_line":"\t\tset ctrl [expr {$::dmcontrol_dmactive | $::dmcontrol_clrresethaltreq}]"},{"line_number":73,"context_line":"\t}"}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"2500cba8_8a551069","line":70,"updated":"2025-12-16 19:25:27.000000000","message":"Great workaround! I missed your comment about the dmcontrol write in `deassert_reset()` clearing haltreq and causing `timed out while waiting for target halted` until just now, but clearly that\u0027s what was happening and this avoids it.","commit_id":"476ccc9f2a2cf61f34eb0f4f7d0c369f01274c5d"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"b593bbf19e65bce39a2956e252cf917f544df91e","unresolved":true,"context_lines":[{"line_number":84,"context_line":"$_TARGETNAME configure -event reset-assert {"},{"line_number":85,"context_line":"\tset reset_config_options [reset_config]"},{"line_number":86,"context_line":"\t# If hardware NRST signal is connected and configured, reset has been"},{"line_number":87,"context_line":"\t# trigered. Avoid second reset and return early"},{"line_number":88,"context_line":"\tif {[string match {srst_only *} $reset_config_options]"},{"line_number":89,"context_line":"\t\t\t|| [string match {srst_and_trst *} $reset_config_options]} {"},{"line_number":90,"context_line":"\t\treturn"}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"15ce1847_2f0ac0ab","line":87,"updated":"2025-12-16 19:25:27.000000000","message":"s/trigered/triggered/","commit_id":"476ccc9f2a2cf61f34eb0f4f7d0c369f01274c5d"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"ff7081bf80642414b08a99ade39deca3c52b057f","unresolved":false,"context_lines":[{"line_number":84,"context_line":"$_TARGETNAME configure -event reset-assert {"},{"line_number":85,"context_line":"\tset reset_config_options [reset_config]"},{"line_number":86,"context_line":"\t# If hardware NRST signal is connected and configured, reset has been"},{"line_number":87,"context_line":"\t# trigered. Avoid second reset and return early"},{"line_number":88,"context_line":"\tif {[string match {srst_only *} $reset_config_options]"},{"line_number":89,"context_line":"\t\t\t|| [string match {srst_and_trst *} $reset_config_options]} {"},{"line_number":90,"context_line":"\t\treturn"}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"5bf3bf86_1b510170","line":87,"in_reply_to":"15ce1847_2f0ac0ab","updated":"2025-12-16 19:34:09.000000000","message":"Done","commit_id":"476ccc9f2a2cf61f34eb0f4f7d0c369f01274c5d"},{"author":{"_account_id":1001983,"name":"Tom Hebb","email":"tommyhebb@gmail.com","username":"tchebb"},"change_message_id":"b593bbf19e65bce39a2956e252cf917f544df91e","unresolved":false,"context_lines":[{"line_number":133,"context_line":"\tif {$status \u0026 $::dmstatus_allhavereset} {"},{"line_number":134,"context_line":"\t\tset ctrl [expr {$ctrl | $::dmcontrol_ackhavereset}]"},{"line_number":135,"context_line":"\t}"},{"line_number":136,"context_line":"\triscv dmi_write $::dmcontrol $ctrl"},{"line_number":137,"context_line":"}"}],"source_content_type":"text/x-ttcn-cfg","patch_set":2,"id":"208972a7_2216c235","line":136,"updated":"2025-12-16 19:25:27.000000000","message":"...and this is why we were getting `Hart unexpectedly reset!`. Makes perfect sense, since we\u0027re past the core code that would typically ack the reset.","commit_id":"476ccc9f2a2cf61f34eb0f4f7d0c369f01274c5d"}]}