)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"c9973e19577a78e07e2b08cb3c0d5be27fc03b82","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"79bc1872_5bdd370b","updated":"2024-07-17 16:35:40.000000000","message":"Antonio, thanks for fixing this.\n\nIn that light I\u0027m not sure if it wouldn\u0027t be better to revert my commit 4892e32294c6 (\"target/cortex_m: allow poll quickly get out\nof TARGET_RESET state\") and let the TARGET_RESET state to keep one poll longer\ninstead of multiple polling in one poll() call.","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"3150bf2db19571e201cdc13d8c59540ac7c5bc5c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a4fb2a8b_4caa8fde","updated":"2024-07-15 10:21:25.000000000","message":"In OpenOCD we do not discriminate in `target-\u003estatus` between the reset send by OpenOCD (either `reset` or `soft_reset_halt` commands) and the reset caused by the system under debug (watchdog, reset button, SW reset from another target in the same SoC, ...); all is handled by the value `TARGET_RESET`.\nAdding a new state would be quite complex, as all targets should be updated...","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"},{"author":{"_account_id":1000859,"name":"Karl Palsson","email":"karlp@tweak.au","username":"karlp"},"change_message_id":"555a737f403d4ced387c6929a64ee196c4b74b27","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6dd041ed_0935c5e2","updated":"2024-08-06 13:11:58.000000000","message":"This also fixes my regression reported on https://review.openocd.org/c/openocd/+/8285\n\nI have no opinion on the correct/best past forward however.","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"592a0cb4f3de8a953a75aa43c974e68ac4d83194","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9a10a4b8_29808dae","updated":"2024-10-05 15:40:13.000000000","message":"Tomas, can we proceed with this patch?","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"ffee0ee32c4f855ba51b420dd9f530ed3ce77c92","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"92fdc866_b2426930","in_reply_to":"6dd041ed_0935c5e2","updated":"2024-08-06 14:43:51.000000000","message":"Good!\nI will check the proposal from Tomas about using S_RETIRE_ST bit, which sounds interesting.","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"}],"src/target/cortex_m.c":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"c9973e19577a78e07e2b08cb3c0d5be27fc03b82","unresolved":true,"context_lines":[{"line_number":996,"context_line":""},{"line_number":997,"context_line":"\t\t/* If still under reset, quit and re-check at next poll */"},{"line_number":998,"context_line":"\t\tif (cortex_m-\u003edcb_dhcsr_cumulated_sticky \u0026 S_RESET_ST) {"},{"line_number":999,"context_line":"\t\t\tcortex_m-\u003edcb_dhcsr_cumulated_sticky \u0026\u003d ~S_RESET_ST;"},{"line_number":1000,"context_line":"\t\t\treturn ERROR_OK;"},{"line_number":1001,"context_line":"\t\t}"},{"line_number":1002,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":1,"id":"2f139a24_6df30365","line":999,"updated":"2024-07-17 16:35:40.000000000","message":"Actually we could check also S_RETIRE_ST bit to distinguish between frequent resets and keeping in reset. Unfortunately at least Kinetis Kx with a cleared flash is capable to generate resets faster than OpenOCD polls.","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"1005d8f36faac49c185eba5787015bb8881a722d","unresolved":false,"context_lines":[{"line_number":996,"context_line":""},{"line_number":997,"context_line":"\t\t/* If still under reset, quit and re-check at next poll */"},{"line_number":998,"context_line":"\t\tif (cortex_m-\u003edcb_dhcsr_cumulated_sticky \u0026 S_RESET_ST) {"},{"line_number":999,"context_line":"\t\t\tcortex_m-\u003edcb_dhcsr_cumulated_sticky \u0026\u003d ~S_RESET_ST;"},{"line_number":1000,"context_line":"\t\t\treturn ERROR_OK;"},{"line_number":1001,"context_line":"\t\t}"},{"line_number":1002,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":1,"id":"afe61b78_d54a8767","line":999,"in_reply_to":"2f139a24_6df30365","updated":"2024-09-08 16:29:36.000000000","message":"Both S_RESET_ST and S_RETIRE_ST are sticky bits and we don\u0027t have the current value of RESET and RETIRE.\nARM reports about S_RETIRE_ST:\n\u003e This bit is UNKNOWN after a powerup or Local reset, but then is set to 1 as soon as the processor executes and retires an instruction.\n\nAbove we have detected a reset through S_RESET_ST.\nIf we check S_RETIRE_ST and it\u0027s `0` we are sure CPU is not running.\nBut if S_RETIRE_ST is `1` we don\u0027t know if this is due to CPU running before reset, after reset, or it\u0027s due to `UNKNOWN` set by the reset itself.\n\nWe are forced to read again DHCSR to get S_RESET_ST and S_RETIRE_ST after the first read.\n\nIf S_RESET_ST is `1`, either we have received a new reset, or the reset is kept on hold. Again S_RETIRE_ST value is not trustable.\nOnly if S_RESET_ST is `0` then the value in S_RETIRE_ST is valid. But it\u0027s useless because either the CPU is running or halted, and this is checked below with C_HALT bit.\n\nIn conclusion, I would keep this patch as is","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"eee067a124360c1d972b69810a79a1e51c6dee60","unresolved":false,"context_lines":[{"line_number":996,"context_line":""},{"line_number":997,"context_line":"\t\t/* If still under reset, quit and re-check at next poll */"},{"line_number":998,"context_line":"\t\tif (cortex_m-\u003edcb_dhcsr_cumulated_sticky \u0026 S_RESET_ST) {"},{"line_number":999,"context_line":"\t\t\tcortex_m-\u003edcb_dhcsr_cumulated_sticky \u0026\u003d ~S_RESET_ST;"},{"line_number":1000,"context_line":"\t\t\treturn ERROR_OK;"},{"line_number":1001,"context_line":"\t\t}"},{"line_number":1002,"context_line":""}],"source_content_type":"text/x-csrc","patch_set":1,"id":"04111ea3_c26a302d","line":999,"in_reply_to":"afe61b78_d54a8767","updated":"2024-10-25 16:49:30.000000000","message":"Sorry for the delay, I was desperately busy.\n\n\u003e We are forced to read again DHCSR to get S_RESET_ST and S_RETIRE_ST after the first read.\n\u003e \n\u003e If S_RESET_ST is `1`, either we have received a new reset, or the reset is kept on hold. Again S_RETIRE_ST value is not trustable.\n\nI would see S_RETIRE_ST `1` (together with S_RESET_ST `1`) on the second read as a clear evidence that RESET was released for some time during the interval between DHCSR reads - as you wrote we don\u0027t know the actual RESET state in any defined moment but IMO it doesn\u0027t matter - we are sure that one RESET pulse has ended so we can reflect it returning TARGET_RUNNING state. And if the next poll detect S_RESET_ST again, we get another RESET pulse. In reality there could be more RESET pulses, but at least one RESET deassert.\n\nI tested with Kinetis K66. With a cleaned flash it keeps in reset/watchdog loop. The loop is so fast that OpenOCD is not able to finish the target examination so there is no relation to this change.\n\nI also tried to trigger SYSRESETREQ in MCU app after a configurable delay. Your patch detects resets just fine up to 10 ms period (not necessarily each one). Faster repeating resets cause `polling failed` and re-examinations. Of course it depends on the adapter speed.\nThe version with S_RETIRE_ST testing doesn\u0027t make any difference in that test.\n\nLet\u0027s merge this patch.","commit_id":"8e18f0874c1fced5870114163d092f2f872a1be5"}]}