)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"013327570011037793ffebc380ed90f395645207","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"026275ee_acf1fe8a","updated":"2025-10-23 13:55:47.000000000","message":"The series was tested on:\nSTM32MP157C\nKinetis K26, focus on RESET/WDOG loop halting - no problems\nnRF5340 - network cpu in defer examine mode","commit_id":"9c021e898697725cd6ad583ecfee2a90307cace0"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"d279b9787b58df2f15a05ab52be06f35b67f1ac0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f5b381a9_ed96bdbc","updated":"2026-01-04 07:10:07.000000000","message":"Antonio, could you please take a look?","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"2281a4044c1f87be592c1fcb63429337726f5233","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"15bf4f98_388da1ce","updated":"2026-01-31 16:47:07.000000000","message":"Looks ok. Tested with STM32MP157","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"},{"author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"change_message_id":"efd2f444672a12a4dfd23772f3440bbed0ba4e52","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"029b442b_54ed6e4b","updated":"2025-11-25 07:56:46.000000000","message":"Looks reasonable to me.\n\n@Tomas: any instructions on how to test the patch? I tested it with a multi-target device that use  `-defer-examine` and experienced no regression.","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"f9fb0e42f064fa9e8f1fb9d7d161feb5f15bea94","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"d5b8681f_38e98891","updated":"2026-02-24 13:19:12.000000000","message":"TL;DR: This seems like an improvement, but I would like to suggest an alternative approach long-term.\n\nTBH, I don\u0027t quite get why we need to reexamine the target on failure to poll.\nAFAIU, there are 3 target-state-management methods:\n1. `init` -- setup the target based on the user-provided data, no communication with the target.\n2. `examine` -- fill-in the missing pieces communicating with the target. After a target is examined we know about it most of the **static** information that is not anticipated to change for the duration of the debug session.\n3. `poll` -- update the dynamic information about the target.\n\nWhen it comes to a `poll` failure, I don\u0027t get the reason why we should drop the static information about the target by re-running the `examine`.\nIMHO there are two probable sources of failure here:\n1. User error when configuring the target.\n2. Unstable connection.\n\nRe-running the `examine` won\u0027t fix (1).\nAs for the (2), I think there are two notable cases.\n\nCase A:\n* During examine the corrupted data ended up in the target info, examine did not fail.\n* The corrupted data resulted in the poll failing.\n\nCase B:\n* The was no issue with the examine.\n* The poll result got corrupted by a communication failure.\n\nRe-examining the target may fix Case A, but it will make Case B even worse (we have discarded the valid result of examine).\n\nPerhaps there is an alternative solution?\nWhat if the user has an option to reset the `examined` flag via a Tcl command?\nOnce a poll failure is observed the user can issue it, effectively disabling the target and excluding it from the set of polled target.\nIf the user want\u0027s to retry communicating with the target, an `arp_examine` can be issued.\n\nThis will be a breaking change. E.g. in RISC-V tests on Spike [1] the access to the Debug Module needs to be authenticated. This is done as follows:\n1. An examine is attempted. It fails because the target is not yet authenticated.\n2. While the `examined` flag get\u0027s reset on examination failure, but the associated\u0027s Debug Module version is examined and is not reset on examination failure. This makes authenticating the access to DM possible.\n3. Once the access is authenticated, the examine is reattempted and it passes.\n\nIMHO this behavior is very weird and fragile, so I\u0027ll be happy to redesign this authentication procedure.\n\n1: https://github.com/riscv-software-src/riscv-tests/tree/988c2ce4563e7122f1abc39298676336031d7209/debug","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"9d725b48b67bd660376ba0691f277394cb28dd8c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"9442aaf9_d44f6d9c","in_reply_to":"029b442b_54ed6e4b","updated":"2025-11-25 08:09:24.000000000","message":"I have no special instructions. Yes, a multi-target device is good choice for testing. Please keep the patch for some time of normal OpenOCD usage. Thanks","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"fa893a88665e55561edd5c73d01197bf4043af08","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"e442d81c_bfb05824","in_reply_to":"d5b8681f_38e98891","updated":"2026-02-24 15:20:52.000000000","message":"\u003e TBH, I don\u0027t quite get why we need to reexamine the target on failure to poll.\n\nYour analysis missed the second role of examine - on some targets very important role: examine sets the target to the state suitable for debugging.\n\nIf the failing poll indicates that something went wrong, OpenOCD must retry examination as we don\u0027t know if the case C happened: the target was externally reset or power cycled and therefore potentially needs re-examination.\n\nOf course the current code is not ideal: re-examination should not take place immediately after the first poll failure, we should instead count consecutive failures to some threshold to filter out random communication errors.\n\nI plan to continue with the better `unresponsive` target detection after 1.0 release.\nThis patch is quite conservative to be as regression-proof as possible.\nRemember there is lot of (old) targets which nobody actively maintains and we are unable even to test them.","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"},{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"ab73063dcb17c97f421f02ddc0ebb82995f7ce2e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b86cb806_d6c2974f","in_reply_to":"e442d81c_bfb05824","updated":"2026-02-25 10:52:19.000000000","message":"\u003e OpenOCD must retry examination as we don\u0027t know if the case C happened: the target was externally reset or power cycled and therefore potentially needs re-examination.\n\nI don\u0027t get the motivation to make this decision internal to the common code.\nIMHO, in this case there is a clear lack of information. The user certainly has more context (provided good-enough error reporting) on a poll failure then target-type-independent code. Therefore, the user is better equipped to make a decision whether the re-examination is necessary or not.\n\n\u003e re-examination should not take place immediately after the first poll failure, we should instead count consecutive failures to some threshold to filter out random communication errors.\n\nWouldn\u0027t it be better to introduce a callback on poll failure that would allow to customize this heuristic (when to re-examine) on the board level?","commit_id":"d6951671ef3ff59647fee1c3f9df6eaa5d863d6d"}]}